MultithreadingHowto.md

@@ -67,7 +67,7 @@ This is a simple (and not really good) example for the Worker Thread Pattern. Th
 
 #### WConditionOneShot
 
-If we have WCondition, why do we need WConditionOneShot? Assume the following situation. You have two parallel threads T1 and T2. One thread's object (T1) offers a WCondition member, lets name it T1::c. Furthermore assume, that the condition c will only fire once! A typical example would be initialization flags. So, if T2 starts, grabs the condition and waits, everything will be fine. T1 will later (after T2 got asleep) fire the condition and T2 will wake up. But if T2 gets delayed and uses T1's condition c.wait() '''after''' T1 notified it, it will sleep forever. This will be no problem if the condition fires repeatedly, as in our above example. But since T1 just fires it once, to notify everybody that T1 is not initialized, every Thread which came to late is stuck.
+If we have WCondition, why do we need WConditionOneShot? Assume the following situation. You have two parallel threads T1 and T2. One thread's object (T1) offers a WCondition member, lets name it T1::c. Furthermore assume, that the condition c will only fire once! A typical example would be initialization flags. So, if T2 starts, grabs the condition and waits, everything will be fine. T1 will later (after T2 got asleep) fire the condition and T2 will wake up. But if T2 gets delayed and uses T1's condition c.wait() **after** T1 notified it, it will sleep forever. This will be no problem if the condition fires repeatedly, as in our above example. But since T1 just fires it once, to notify everybody that T1 is not initialized, every Thread which came to late is stuck.
 One trivial solution would be to check a boolean flag variable before going asleep if the condition already came true. This would work if it is ensured that, while checking it with an IF statement, the flag will not change in the meanwile. That's where WConditionOneShot comes into play.
 
 WConditionOneShot will prevent c.wait() to wait endlessly if the condition got fired in the past. Therefore it does not use a boolean flag. It uses shared mutex, since locking operations on them are atomic. So, you can use wait() in such cases without headaches.
@@ -112,7 +112,7 @@ Although the conditions are very useable, they miss the possibility to conjunct
 
 The good news is: you can specify what kind of condition a flag should use. In this example a one shot condition to avoid endless waiting of "someThread". You can access the associated variable using get() or the () operator. To wait for it use wait() as with the conditions. Which condition type to use also has to be decided by the owning class, since it knows best what is needed.
 
-**Note**: please note, that for convenience reasons, a class WBoolFlag is available (, which simply is a WFlag< bool > shortcut).
+**Note**: Please note, that for convenience reasons, a class WBoolFlag is available (which simply is a ```WFlag< bool >``` shortcut).
 
 **Note**: The getter for WFlag instances should always return const references or const pointer.