Re: Threads docs updated in CVS

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.