Re: [boost] condition Win32 based on events

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2005-09-17 17:06:30

Roland Schwarz wrote:
> Yuval Ronen schrieb:
> 
> 
>>As far as I could understand from this, the POSIX standard specifies 
>>that calling pthread_cond_wait() with a recursively locked mutex 
>>(lock_count > 1) is forbidden and yields undefined behaviour.
>>
> 
> This issue is known,
> http://aspn.activestate.com/ASPN/Mail/Message/2118928
> 
> As there is currently a rewrite going on this issue will be covered.
> I currently think a meaningful implementation would throw an exception
> from the wait (with the mutex still locked). Either the stack unwinding
> will restore the program invariant then or a user supplied exception
> handler might try to remedy this situation.
> 
> Would this be reasonable?

My intuition is to make it work. Meaning that the wait() will unlock 
lock_count() times, to a full unlock state, and then lock it back again 
the same amout of times. Why shouldn't it work?

However, the link that Alexander Terekhov gave points out that the POSIX 
people think it's a bad idea, and the link you gave points out that the 
consensus on this mailing list is also that it's a bad idea, so maybe 
I'm wrong after all... ;-) I guess I'll have to read the thread where 
this consensus emerged and see if I agree or not.

And even if I agree, throwing seems weird. As I mentioned, if a 
combination of a condition variable and a recursive mutex is a bad 
thing, then make it not compile at all. Isn't this better? Allowing 
usage of a recursive mutex as long as it's not being used recursively is 
the opposite of logical, to me.

Yuval