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

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

#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                                                      
Resolution:                                             |    Keywords:  named mutex, named_mutex, semaphore, posix_named_semaphore, unlock
--------------------------------------------------------+-------------------

Comment (by David Hebbeker <david.hebbeker@…>):

 Replying to [comment:3 steven_watanabe]:
 > I don't understand why you expect this behavior.
 I expect this behaviour as I imagine that a mutex has some kind of state
 machine. I hoped that there is no error / undefined state and that an
 attempt to unlock in the unlocked stated would result in the unlocked
 state. Just that simple.
 > Your quote from Tanenbaum is irrelevant because valid states only apply
 as long as you follow the rules.  Once you break the rules, all bets are
 off.
 The point is, that I wish other rules.

 > {{{
 > $ man pthread_mutex_unlock
 > ...
 > If the mutex type is PTHREAD_MUTEX_DEFAULT, ... Attempting to
 > unlock the mutex if it was not locked by the calling thread
 > results in undefined behavior.  Attempting to ulock the mutex
 > if it is not locked results in undefined behavior.
 > ...
 > }}}
 What about {{{PTHREAD_MUTEX_ERRORCHECK}}}? In that case an {{{EPERM}}}
 error would be returned, which is better than undefined behaviour.

 > In any case, the precondition that you propose, "no other thread must
 have exclusive ownership of the mutex", is basically useless.  If the
 current thread doesn't hold the mutex, how do you know that no other
 thread holds it?
 I am not sure if I got your question: I could use try_lock() to test if an
 other thread holds it.

 Also my workaround from above is not complete! Maybe this can be
 considered, which is still not perfect:
 {{{
 if(mutex.try_lock())
 {       // The mutex was free and is now locked by this thread
         mutex.unlock();
 }
 else {  // The mutex is locked, try to unlock it
         mutex.unlock(); // Hopefully it is locked by this thread
         // in case an other thread holds the mutex > bad things happen
 }
 }}}
 The whole point is that I would like to be able to safely call unlock on a
 mutex. And the behaviour should not be undefined in case it already was
 unlocked.

 ''I am not saying, that the current implementation is defect!'' But that
 it could maybe be improved by removing the restriction applied in the
 precondition?

 By the way: Thanks for the fast responses!

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