Update rspec 2

analyzers/rspec/cs/S2445_c#.html

@@ -1,12 +1,15 @@
-<p>Locking on a class field synchronizes not on the field itself, but on the object assigned to it. So locking on a non-<code>readonly</code> field
-makes it possible for the field’s value to change while a thread is in a block locked on the old value. That would allow a second thread, locked on
-the new value, to enter the block at the same time.</p>
-<p>Locking on a <code>readonly</code> field of a class which is not <code>private</code> allows external code to lock the field, potentially
-interfering with synchronization of methods in that class.</p>
-<p>Locking on a local variable or on a new instance undermines the synchronization: two different threads running the same method in parallel would
-lock on two different object instances. That would allow a second thread, locked on that new value, to enter the same block concurrently.</p>
-<p>Locking on a string literal is even more dangerous: depending on whether the string is interned or not, different threads may or may not
-synchronize on the same object instance.</p>
+<p>Locking on a class field synchronizes not on the field itself, but on the object assigned to it. Thus, there are some good practices to follow to
+avoid bugs related to thread synchronization.</p>
+<ol>
+  <li> Locking on a non-<code>readonly</code> field makes it possible for the field’s value to change while a thread is in the code block locked on
+  the old value. This allows another thread to lock on the new value and access the same block concurrently. </li>
+  <li> Locking on a <code>readonly</code> non-<code>private</code> field allows, for example, a method from another class to lock on the same field,
+  potentially interfering with the synchronization. </li>
+  <li> Locking on a local variable or a new instance of an object undermines the synchronization because two different threads running the same method
+  in parallel will lock on two different instances of the same object, allowing them to access the synchronized block at the same time. </li>
+  <li> Locking on a string literal is also dangerous since, depending on whether the string is interned or not, different threads may or may not
+  synchronize on the same object instance. </li>
+</ol>
 <h2>Noncompliant Code Example</h2>
 <pre>
 private Color colorObject = new Color("red");
@@ -48,6 +51,9 @@ <h2>Compliant Solution</h2>
 </pre>
 <h2>See</h2>
 <ul>
+  <li> <a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/lock">Lock Statement</a> - lock statement - ensure
+  exclusive access to a shared resource </li>
+  <li> <a href="https://learn.microsoft.com/en-us/dotnet/api/system.string.intern">String.Intern</a> - <code>String.Intern(String)</code> Method </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/412">MITRE, CWE-412</a> - Unrestricted Externally Accessible Lock </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/413">MITRE, CWE-413</a> - Improper Resource Locking </li>
 </ul>