Boost C++ Libraries: Ticket #8306: named mutex does not unlock as expected

attachment set

Mon, 18 Mar 2013 18:26:27 GMT

attachment → namedMutexExample.cpp

Minimal example of using named mutexes and unlocking them several times consecutively. Linked with -lpthread. The program is expected to never return.

Steven Watanabe — Mon, 18 Mar 2013 18:51:53 GMT

Violating the preconditions of a function has undefined behavior. Once you do this, you cannot rely on the object (or the program) being in a sane state.

Mon, 18 Mar 2013 18:58:10 GMT

Replying to steven_watanabe:

Violating the preconditions of a function has undefined behavior. Once you do this, you cannot rely on the object (or the program) being in a sane state.

Yes, I am acknowledging that this scenario would violate the preconditions defined in the documentation. My intention is that the behaviour is not as one would expect it from a mutex in general (see [Tanenbaum]).

Steven Watanabe — Mon, 18 Mar 2013 19:23:31 GMT

I don't understand why you expect this behavior. 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.

$ 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.
...

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?

Mon, 18 Mar 2013 19:53:26 GMT

Replying to 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!

Steven Watanabe — Mon, 18 Mar 2013 21:10:34 GMT

Replying to David Hebbeker <david.hebbeker@…>:

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.

I'm afraid that isn't how mutexes work.

What about PTHREAD_MUTEX_ERRORCHECK? In that case an EPERM error would be returned, which is better than undefined behaviour.

But note that it's still considered an error. It's just detected. Also, in the standard, C++11 30.4.1.2: "21 The expression m.unlock() shall be well-formed and have the following semantics. 22 Requires: The calling thread shall own the mutex."

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.

If you already hold the mutex, then for a non-recursive mutex, you can't call try_lock and for a recursive mutex, calling unlock after try_lock will leave you exactly where you started.

Suppose that your semantics were implemented. Then consider the following code:

Thread A:
1 - if(foo()) m.lock();
2 - m.unlock();
Thread B:
3 - m.lock();
4 - // do something
5 - m.unlock();

If B is at (4) and foo() returns false then, thread A has undefined behavior. In order to make A correct, we'd have to make m.unlock() be a no-op even if another thread holds m. It seems rather counterintuitive that m.unlock() should be legal and leave the mutex locked.

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
}

This code has exactly the same problems as plain mutex.unlock().

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?

It's not going to happen. The bottom line is that you have to know whether you hold a mutex in order to do anything useful with it. I don't think that the library should go out of its way to support usage which is very dangerous and which is not supported by any other mutex implementation that I'm aware of.

Also, I don't even want to think about the implications of your proposed behavior for recursive mutexes.

Tue, 19 Mar 2013 01:33:32 GMT

Replying to steven_watanabe:

Replying to David Hebbeker <david.hebbeker@…>:

What about PTHREAD_MUTEX_ERRORCHECK? In that case an EPERM error would be returned, which is better than undefined behaviour.

But note that it's still considered an error. It's just detected.

[...]

It's not going to happen. The bottom line is that you have to know whether you hold a mutex in order to do anything useful with it. I don't think that the library should go out of its way to support usage which is very dangerous and which is not supported by any other mutex implementation that I'm aware of.

As I understand the behaviour I described is implemented by pthread mutexes of type PTHREAD_MUTEX_ERRORCHECK. It improves the behaviour as it may not result in an undefined state in contrast to the default mutex, but it returns an error value. The downside would be the performance overhead.

status changed; resolution set

Ion Gaztañaga — Wed, 29 May 2013 07:42:30 GMT

status new → closed
resolution → worksforme

As Steven correctly points out, violating the precondition must not be supported. std::mutex behaves also this way. ERRORCHECK mutexes are not available in al platforms and they have a perfomance impact.