From: flameframe_at_[hidden]
Date: 2001-08-13 03:32:35
--- In boost_at_y..., williamkempf_at_h... wrote:
[snip]
> Usage of CVs is trivial and doesn't require any "careful analysis
to
> 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
almost
> always *IS* some external predicate (data) for which the event is
> associated. Thread A signals the event because some state (data)
has
> become true and Thread B must react to this situation, usually by
> reading/writing to data shared between the threads, possibly even
the
> very state data that caused the event to be signaled to begin
with.
> 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
relation.
>
> > 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
claim,
> 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
in
> e-mail and even gave the pseudo code that illustrates race
conditions
> 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;
a
> 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
all
> of the code you have that uses events. Any time that the response
to
> 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,
Vitalij.
P.S. I am also from community voting for 'wait' instead of 'join'. It
is not important but first name is more clear.