Boost logo

Boost :

From: Scott McCaskill (scott_at_[hidden])
Date: 2001-08-13 00:41:40

> williamkempf_at_[hidden] wrote:
> >
> > 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 disagree. But of course, it's so obvious to any Real Programmer that
> you must be right and I must be wrong that it would be quite
> unreasonable to ask you to justify your claim.

I don't understand this complaint. He _did_ justify and explain the claim,
in the sentences that followed immediately.

> > 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
> All I see there is yet another bare assertion that race conditions exist
> with no attempt to back it up with logic. And some broken code.

The point was that the example illustrates a common type of thing to do. If
the above sort of problem is easier to solve with events than with CVs, then
let's get to the point--please explain how!

> I'm giving up on this whole thing as of now. You've made it totally
> clear that your mind is made up and you aren't prepared to engage in any
> sort of discussion. I'm going to stop beating my head against a stone
> wall and go do something more productive.

This is completely out of line and unfair. I have watched several people
attempt to engage you in rational, productive discussion, and I have seen
extremely little reciprocation on your part. It's a shame, because I (like
many others here I think) would like to know what it is that you know that
we don't about why events are preferable to CVs. Responses such as yours
above do not benefit anyone. OTOH, giving concrete examples of situations
where events are a better solution than CVs would be immensely valuable.

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