id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
8306,named mutex does not unlock as expected,David Hebbeker <david.hebbeker@…>,Ion Gaztañaga,"{{{named_mutex}}} internally uses a {{{posix_named_semaphore}}} (in file {{{<boost/interprocess/sync/posix/named_mutex.hpp>}}}). When a mutex is unlocked (via {{{unlock()}}}) multiple times consecutively a single call to {{{lock()}}} will not lock the mutex!

In the documentation it says:
> void unlock()
> 
> Precondition: The thread must have exclusive ownership of the mutex.
[Boost][[BR]]
This precondition is violated within this scenario. But the expected precondition is that ''no other thread must have exclusive ownership of the mutex''. This way a free mutex could be unlocked safely.

The ''expected behaviour'' is that:
> A mutex is a variable that can be in one of two states: unlocked or locked.
[Tanenbaum][[BR]]
Thus locking an unlocked mutex would definitely lock it. To demonstrate that this expectation is not fulfilled a minimal program will be attached.

A workaround to securely unlock a {{{named_mutex}}} could be:
{{{
if(mutex.try_lock())
{
	mutex.unlock();
}
}}}
This way the mutex will only be unlocked if no other thread holds ownership of the mutex. Also the mutex will not be unlocked consecutively in case this snipped is called several times as it would be locked by {{{try_lock()}}} before. After this snipped the mutex will not be locked by the calling thread, but still might be locked by an other thread.

A real fix to this issue would probably be to use mutexes (like with {{{pthread_mutex_unlock}}}) instead of semaphores.

[Tanenbaum] A. S. Tanenbaum, Operating systems: design and implementation, 3rd ed. Upper Saddle River, N.J: Pearson/Prentice Hall, 2006.[[BR]]
[Boost] ‘Synchronization mechanisms - 1.53.0’. [Online]. Available: http://www.boost.org/doc/libs/1_53_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_mutex_operations. [Accessed: 18-Mar-2013].
",Bugs,closed,To Be Determined,interprocess,Boost 1.52.0,Optimization,worksforme,"named mutex, named_mutex, semaphore, posix_named_semaphore, unlock",info@… ayman@…