Re: [boost] condition Win32 based on events

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2005-09-18 13:55:50

>>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?
> 
> Ok, I'll try to explain, altough I am afraid I am not too good in this.
> You are true, in believing that it can be made working. But you are
> about to create extremely dangerous code by this.
> 
> Once you place this semantics into work _every_ subroutine call
> from within a locked scope attains wait semantics, i.e the state of
> your locked memory might have changed. This wouldn't be expected
> by most programmers.
> 
> E.g.
> 
> ...
>     {
>         scoped_lock l(m);
>          // do something to the locked data
>          foo(); // call a member function which _might_ wait
>          // do something else to the locked data
>          // ouch, the locking was removed in between, data has
>          // unexpectedly changed. I did not expect this, did you?
>     }

I can't understand why this example shows why a condition variable with 
recursive mutex is dangerous. How this example would be any different if 
the mutex is non-recursive? Calling foo() which might wait, *always* 
have the potential of releasing the mutex, so a recursive mutex doesn't 
change anything here. And this is, actually, a good thing, that it 
doesn't change anything. This way the behaviour is expected, and all is 
dandy.

> Ok, this is no good, but why then allow recursive mutex anyways?
> 
> I find it harder to come up with a convincing example, but basically
> I think to forbid it entirely simply is too strict. It is possible to write
> correct, yet safe programs with recursive_mutex. I'll try:

<snip exmaple why a condition variable with recursive mutex can be useful>

I disagree that the runtime correctness issue in this example is 
relevant to the condition variable stuff. This example had some logic 
about what can or can't be the answer, and tried to manipulate the
condition variable to validate this. I find this very confusing. If I 
wanted to say that an asnwer smaller than 42 is a runtime error, then 
I'd just write

if (answer < 42)
     throw ...;

which is much simpler and understandable. IMHO, Condition variable are 
meant for completely different purposes than checking runtime 
correctness of application business logic.

> Of course, better programming style would have choosen
> a different grouping of the functions, so the recursive_mutex
> could have been avoided entirely. But you also have
> things like reinterpret_cast<> which usually are beeing
> avoided whenever possible. Still it is there because there
> are times when it is useful, you simply have to put a lot
> more thought into it when using it.

Ok, then. If it's considered ok, then allow it, as I can't find any good 
reason to say that a recursive mutex is ok, but a condition variable 
with such a mutex is not ok.

Of course, anything I say is completely my humble opinion, and may very 
well turn out to be complete nonsense.

Yuval