Re: Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-21 14:31:51

--- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> My suggestions seem to be getting lost in a flurry of nitpicking 
> over the example code, so let me restate the idea.

I'm sorry, obviously my objections to your code are being 
misconstrued.

> Thread primitives are dangerous.  It is very easy to write programs
> that lock up, and very difficult to debug them.  Therefore I do not
> want, and will continue to resist, the inclusion of thread
> primitives in Boost, unless they are shown to be truly necessary
> for implementing some other part of Boost, and we provide higher
> level facilities for most uses.

Unfortunately, there is no "high level facility" that will address 
any but the most specific problems.  Your "example code" is a classic 
example of this.  You've not defined a monitor, but instead have 
defined a specific implementation of a monitor for a bounded buffer.  
That's only one, very specific, problem addressed.  We're left with 
an infinite number of other problems to solve.  The key to what I 
just said is _infinite_.
 
> I believe the correct approach is to identify patterns of safe 
> usage and create facilities that enforce those patterns -- at 
> compile time if possible, at run time if not.  I have been pushing 
> the "monitor" pattern in my examples.  If that pattern is not 
> adequate for certain applications the best alternative is not to 
> revert to primitives, but to provide the new pattern(s) as a safe
> facility.

The "monitor pattern" does not limit itself to two conditions, let 
alone the two very specific conditions in the example.  A monitor is 
not constrained in this way, nor can it be if it's to be a general 
solution.  If you have a general solution for the monitor pattern 
that fully encapsulates the "primitive mutex and CV" (I put this in 
quotes, because at that point the monitor becomes just another 
primitive... and one with the same potential pitfalls) then we'd have 
something to consider.

The fact of the matter is, a monitor isn't anything more than a 
pattern that uses a mutex and a CV.  Because of this, it has the 
exact same potential for error as using a mutex and CV seperately.  
It would be nice if we could find a pattern or primitive that didn't 
have the potential to be misused, resulting in deadlock or race 
conditions, but I doubt that any such pattern or primitive exists.

What we should do is strive to reduce the potential for mistakes.  I 
think we've done that so far, but if there are other ideas to further 
reduce errors I'm fully open to hearing them.
 
> I'm sorry if I seem hard nosed about this, but I have my reasons.
> First, I have seen how much trouble the Java threading primitives
> cause for programmers trying to use them, and have read the rather
> devastating critiques of those primitives by experts like Brinch
> Hansen and Hoare (e.g. "... designed by amateurs who were in over
> their depth").  I don't want us to make the same mistakes.  Second,
> we have hopes that much of Boost will be suitable for the next
> revision of the C++ standard library.  To date, the committee has
> been extremely wary of suggestions to add threading facilities, so
> whatever is proposed must be good enough to overcome that wariness
> and withstand the strong criticism to which the committee will
> subject it.

I'd really like to read these critiques. :(

I agree that we have to be vary wary of potential problems.  We need 
to prevent as many errors as possible, and most such prevention 
should occur at compile time.  However, that said, I don't really see 
your argument/objection here.  Your example is just as open to misuse 
and error as the seperate primitives are.  Further, it's stuck in a 
single problem domain.  This doesn't necessarily mean that the 
primitives are needed, though to exclude them I'd have to see a 
general purpose solution.  To my knowledge, no such solution exists.  
For any research to go further in finding such a solution, we'll need 
the primitives upon which to build them.

Bill Kempf