[Boost-bugs] [Boost C++ Libraries] #8306: named mutex does not unlock as expected

Subject: [Boost-bugs] [Boost C++ Libraries] #8306: named mutex does not unlock as expected
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-03-18 18:22:56

#8306: named mutex does not unlock as expected
--------------------------------------------------------------------------------+
 Reporter:  David Hebbeker <david.hebbeker@…>                                   |       Owner:  igaztanaga  
     Type:  Bugs                                                                |      Status:  new         
Milestone:  To Be Determined                                                    |   Component:  interprocess
  Version:  Boost 1.52.0                                                        |    Severity:  Optimization
 Keywords:  named mutex, named_mutex, semaphore, posix_named_semaphore, unlock  |  
--------------------------------------------------------------------------------+
 {{{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].

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/8306>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.