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
 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:
 { // The mutex was free and is now locked by this thread
 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

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

 By the way: Thanks for the fast responses!

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:12 UTC