Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-08-12 08:42:25

--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> John Max Skaller wrote:
> >
> > Ross Smith wrote:
> > So please comment. It is my understanding that
> > events are
> >
> > a) more general
> > b) harder to use
> >
> > than more specific synchronisation techniques. Would you agree?
> I don't grok CVs well enough to say whether they're more or less
> than events, but I certainly disagree with the second part. CVs are
> complicated linkage of several disparate concepts -- mutex,
> etc -- that require careful analysis to figure out how to use them
> properly in any particular situation. Events are very simple: one
> sets an event, another waits for it. What could be simpler?

Usage of CVs is trivial and doesn't require any "careful analysis to
figure out how to use them properly in any particular situation".
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.

> I'm willing to be educated on this point, but only by actual
> argument. Bare assertions that events are more likely to lead to
> conditions aren't good enough (and neither is "because Knuth says
> If someone can present a solid argument that justifies that claim,
> 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
   // 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
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
> Sorry, I'm not arrogant enough for that line of argument to work; a
> 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.

Bill Kempf

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