Editing Reentrant mutex (section)

==Motivation==
Recursive mutexes solve the problem of [[Reentrancy (computing)|non-reentrancy]] with regular mutexes: if a function that takes a lock and executes a callback is itself called by the callback, [[Deadlock (computer science)|deadlock]] ensues.<ref>{{cite book |title=Pattern-Oriented Software Architecture, A Pattern Language for Distributed Computing |first1=Frank |last1=Buschmann |first2=Kevlin |last2=Henney |first3=Douglas C. |last3=Schmidt |publisher=John Wiley & Sons |year=2007 |page=374 |isbn=9780470065303 |url=https://books.google.com/books?id=WVQF2PK2tlgC&pg=PA374}}</ref> In [[pseudocode]], that is the following situation:

 '''var''' m : Mutex  // A non-recursive mutex, initially unlocked.
 
 '''function''' lock_and_call(i : Integer)
     m.lock()
     callback(i)
     m.unlock()
 
 '''function''' callback(i : Integer)
     '''if''' i > 0
         lock_and_call(i - 1)
 
 lock_and_call(1)  // Invoking the function

Given these definitions, the function call {{mono|lock_and_call(1)}} will cause the following sequence of events:

* {{mono|m.lock()}} — mutex locked
* {{mono|callback(1)}}
* {{mono|lock_and_call(0)}} — because {{mono|i > 0}}
* {{mono|m.lock()}} — deadlock, because {{mono|m}} is already locked, so the executing thread will block, waiting for itself.

Replacing the mutex with a recursive one solves the problem, because the final {{mono|m.lock()}} will succeed without blocking.