Update ReaderWriterLockSlim.xml

dgtvan · web-flow · commit 477bc8cbf0c1 · 2021-11-08T16:53:01.000+07:00
diff --git a/xml/System.Threading/ReaderWriterLockSlim.xml b/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 such as .NET Framework. If you are using .NET Core or .NET, it should be fine. [Thread.Abort is obsolete](https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/thread-abort-obsolete) on all .NET implementations except .NET Framework.
+> - <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. [Thread.Abort is obsolete](https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/thread-abort-obsolete) on all .NET implementations except .NET Framework.
 
  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.  
   

Original file line number	Diff line number	Diff line change
`@@ -50,7 +50,7 @@`
`50`	`50`	`> [!NOTE]`
`51`	`51`	`>`
`52`	`52`	> - <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.
`53`		`-> - <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, it should be fine. [Thread.Abort is obsolete](https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/thread-abort-obsolete) on all .NET implementations except .NET Framework.`
	`53`	`+> - <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. [Thread.Abort is obsolete](https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/thread-abort-obsolete) on all .NET implementations except .NET Framework.`
`54`	`54`
`55`	`55`	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.
`56`	`56`