Modify rule S5524: Small language tweaks following docs team review (#…

…3432)

rules/S5524/cfamily/rule.adoc

@@ -1,12 +1,12 @@
 == Why is this an issue?
 
-_Mutexes_ are synchronization primitives that allow to manage concurrency. It is a common situation to have to lock multiple _mutexes_ simultaneously to get access to several resources at the same time.
+_Mutexes_ are synchronization primitives that allow you to manage concurrency. It is a common situation to have to lock more than one _mutex_ simultaneously to get access to several resources at the same time.
 
 
-If this is not done properly, it can lead to deadlocks or crashes. If one thread acquires A then tries to acquire B, while another thread acquires B then tries to acquire A, both threads will wait for each other forever.
+If this is not done properly, it can lead to deadlocks or crashes. If one thread acquires A and then tries to acquire B, while another thread acquires B and then tries to acquire A, both threads will wait for each other forever.
 
 
-In such a case, a commonly accepted good practice is to define an order on the _mutexes_ and to lock them in that order and unlock them in the reverse order. However, such an order is not always clearly defined or easy to ensure across a whole program.
+In such a case, a commonly accepted good practice is to define an order on the _mutexes_ then lock them in that order, and then unlock them in the reverse order. However, such an order is not always clearly defined or easy to ensure across a whole program.
 
 
 {cpp} provides facilities to lock multiple _mutexes_ in one go, with a dedicated deadlock prevention algorithm. They should be used instead. Before {cpp}17, you should use ``++std::lock++``, and since {cpp}17 you can use a variadic constructor of ``++std::scoped_lock++``. See the examples for more details.