Merge pull request #7362 from VanDng/patch-1

Give more information on thread-abort safe

Author: eerhardt

xml/System.Threading/ReaderWriterLockSlim.xml

@@ -50,7 +50,7 @@
 > [!NOTE]
 >
 > - <xref:System.Threading.ReaderWriterLockSlim> is similar to <xref:System.Threading.ReaderWriterLock>, but it has simplified rules for recursion and for upgrading and downgrading lock state. <xref:System.Threading.ReaderWriterLockSlim> avoids many cases of potential deadlock. In addition, the performance of <xref:System.Threading.ReaderWriterLockSlim> is significantly better than <xref:System.Threading.ReaderWriterLock>. <xref:System.Threading.ReaderWriterLockSlim> is recommended for all new development.  
-> - <xref:System.Threading.ReaderWriterLockSlim> is not thread-abort safe. You should not use it in an environment where threads accessing it can be aborted (for example, ASP.NET).
+> - <xref:System.Threading.ReaderWriterLockSlim> is not thread-abort safe. You should not use it in an environment where threads accessing it can be aborted such as .NET Framework. If you are using .NET Core or .NET 5, it should be fine. <xref:System.Threading.Thread.Abort%2A> is not supported in .NET Core and [is obsolete](https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/thread-abort-obsolete) in .NET 5 and later.
 
  By default, new instances of <xref:System.Threading.ReaderWriterLockSlim> are created with the <xref:System.Threading.LockRecursionPolicy.NoRecursion?displayProperty=nameWithType> flag and do not allow recursion. This default policy is recommended for all new development, because recursion introduces unnecessary complications and makes your code more prone to deadlocks. To simplify migration from existing projects that use <xref:System.Threading.Monitor> or <xref:System.Threading.ReaderWriterLock>, you can use the <xref:System.Threading.LockRecursionPolicy.SupportsRecursion?displayProperty=nameWithType> flag to create instances of <xref:System.Threading.ReaderWriterLockSlim> that allow recursion.