Re: Threads docs updated in CVS

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 
general
> than events, but I certainly disagree with the second part. CVs are 
a
> complicated linkage of several disparate concepts -- mutex, 
predicate,
> etc -- that require careful analysis to figure out how to use them
> properly in any particular situation. Events are very simple: one 
thread
> 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 
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
   // 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 
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.

Bill Kempf