Boost logo

Boost :

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
> is locked before the wait, unlocked during the wait, and locked
> 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
> mutex, and if you attempt to you wind up with race conditions.

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

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
> 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
> 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at