Boost logo

Boost :

From: flameframe_at_[hidden]
Date: 2001-08-13 03:32:35

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

> Usage of CVs is trivial and doesn't require any "careful analysis
> figure out how to use them properly in any particular situation".

I am not sure that 'trivial' is appropriate argument here. At least
when discussion about CV usage already take place.

> And the complexity with events results precisely because there
> always *IS* some external predicate (data) for which the event is
> associated. Thread A signals the event because some state (data)
> become true and Thread B must react to this situation, usually by
> reading/writing to data shared between the threads, possibly even
> very state data that caused the event to be signaled to begin
> So in most usages even with an event you wind up using the event, a
> predicate and a mutex, but the three are totally unrelated and this
> is what leads to race conditions.

Using multiple wait idiom as in Win32 we can easily build a mentioned

> > I'm willing to be educated on this point, but only by actual
> rational
> > argument. Bare assertions that events are more likely to lead to
> race
> > conditions aren't good enough (and neither is "because Knuth says
> so").
> > If someone can present a solid argument that justifies that
> I'll
> > apologise and withdraw my objection. But not until I see it.
> We pointed you to literature that explains this better than we can
> e-mail and even gave the pseudo code that illustrates race
> with events. I'll give some pseudo code one more time.
> lock mutex
> check state data to see if we can proceed
> if false
> unlock mutex so other threads can have access to sate data

As stands at a line below in this pseudo-code state checking can be
done with waiting for event. So what are above lines for?

> // This is where one race occurs
> wait for event signaled by other threads when state is true
> // This is where another race occurs
> lock mutex

These lines just are to be written as following.
     wait mutex and event signaled by other threads when state is true
     // No chance for race condition
     make use of data

> make use of data
> > (Last time this came up someone pointed to an error in my own
> > event-based code, and claimed that the fact that my CV-based
> version of
> > the same code didn't have the error was evidence that events were
> bad.
> > Sorry, I'm not arrogant enough for that line of argument to work;
> bug
> > in my code proves nothing more profound than the fact that I can
> make a
> > mistake.)
> I'm willing to bet that I can show you a race condition in nearly
> of the code you have that uses events. Any time that the response
> waiting for an event includes acquiring a lock and changing shared
> data you've got a race condition. Can this be programmed correctly
> so that there is no race condition? Yes, as evidenced by the
> implementation of CVs on Win32, but it requires more than just an
> event to get it right and most people won't understand the
> implementation well enough to do this correctly to begin with. And
> in the end, what you get is a CV any way.

I believe that CV is a GOOD thing. But it does not mean that
alternatives are bad. I have written some high level abstractions
like reader-writer lock using events without getting something like
CVs in source code.

Best regards,

P.S. I am also from community voting for 'wait' instead of 'join'. It
is not important but first name is more clear.

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