Re: Threads docs updated in CVS

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, 
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. 

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 
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?

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 
true

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 
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. 

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

Bill Kempf