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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:12 UTC