Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-08-13 07:38:53

--- In boost_at_y..., flameframe_at_h... wrote:
> --- In boost_at_y..., williamkempf_at_h... wrote:
> > 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,
> > predicate and a mutex, but the three are totally unrelated and
> > is what leads to race conditions.
> Using multiple wait idiom as in Win32 we can easily build a
> relation.

Actually, you can't. There's no way for me to prove this, but I can
challenge you to do so and I'm willing to bet I can show race
conditions with each of your attempts.
> > > I'm willing to be educated on this point, but only by actual
> > rational
> > > argument. Bare assertions that events are more likely to lead
> > race
> > > conditions aren't good enough (and neither is "because Knuth
> > 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
> 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?

The state can't change if you've got a lock on a mutex that's
protecting the state.
> > // 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

No, because the Win32 WaitForMultiple*() operations won't gaurantee
you the order in which the objects are acquired. It's likely that
the mutex will be acquired first, preventing other threads from
modifying the state in order to signal the event, so you wind up with
a deadlock caused from a race condition.

> // 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
> > bad.
> > > Sorry, I'm not arrogant enough for that line of argument to
> a
> > bug
> > > in my code proves nothing more profound than the fact that I
> > 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
> to
> > waiting for an event includes acquiring a lock and changing
> > data you've got a race condition. Can this be programmed
> > 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.
> > 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.

Event's are good, for a very limited number of uses. They are
frequently misused. That's what's bad.

Bill Kempf

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