Re: Threads docs updated in CVS

From: flameframe_at_[hidden]
Date: 2001-08-13 02:56:03

--- In boost_at_y..., williamkempf_at_h... wrote:

> Condition variables *MUST* be used in conjunction with a mutex 
which 
> is locked before the wait, unlocked during the wait, and locked 
again 
> after the wait in a thread safe manner.  Condition variables use an 
> interface that makes this hard to do wrong (with Boost.Threads it 
> becomes impossible).  Events *MUST NOT* be used in conjunction with 
a 
> mutex, and if you attempt to you wind up with race conditions.  

Why? 
Probably I am not an expert here but I often use such a 
conjunction w/o any problem. What means '*MUST NOT*'? I have followed 
the discussion for a while and see that most of arguments are in 
declarative form. Where are the proofs?

> Nothing in their interface can prevent this misuse, and 
unfortunately 
> most programmers don't understand this danger.  So events are 
> dangerous in comparison to condition variables.  

Here is a quote from Boost.Thread docs about CV wait:
{{ Danger: This version should always be used within a loop checking 
that the state logically associated with the condition has become 
true. Without the loop, race conditions can ensue due to 
possible "spurious wake ups".  }}
And here is a comment from source code
{{//   23 May 01  WEKEMPF Removed "duration" timed_waits, as they are 
too difficult to use with spurious wakeups.
}}

//Sorry if these quotes are out of date or not appropriate out of 
context.

Could anything with word "spurious" w/o proofs be 
declared as less dangerous and more easy to use?

> Further, there are 
> very few designs in which an event is the optimal synchronization 
> object to use, and even in those rare cases a condition variable 
can 
> easily be used instead, while the converse isn't true.

Hmm, 'converse isn't true'. Can you show an example based on CV that 
can't be implemented with (event/mutex/semafore+multiple waits as it 
is in Win32) model? I believe this combination is a bit more low-
level concept than with CV, and therefore can be used inplace. It 
looks like Or/And/Not-based logic against Xor/And/Not-based. 

> 
> That said, those rare cases where an event is optimal are valid...
> 
> > than more specific synchronisation techniques. Would you agree?
> > And, more for Bill: is there anything preventing an
> > event synchronisation subsystem being added to the library?
> 
> No, event's can be trivially added to Boost.Threads, using the 
native 
> event objects in Win32 and condition variables in POSIX.  However, 
> because of the reasons I gave above, this is not an extension that 
> I'll be making before submission.  If people find a legitimate need 
> for them later we can discuss the pros and cons more carefully and 
> add events if we then deem them to be needed.

There are a lot of existing code using events. Would you expect them 
to change their way of thinking in a moment? 

Vitalij.