Re: [boost] Re: Threads

From: jsiek_at_[hidden]
Date: 2000-08-21 14:18:44

I agree that higher-level patterns like monitor should be created.

However, to make headway in the near term I think we should also fully
develop the more primitive synchronization mechanisms. This will give
us something to build the higher-level patterns, and will give us a
more precise vocabulary with which to discuss the issues.

Later on down the line, once we have all the higher-level patterns
fleshed out, and once we know that all the bases are covered, then we
can think about moving primitives from the boost namespace into the
boost/detail namespace. (note that all of this will happen before the
release, so we will not be breaking people's code with this change).

As for CV's and monitors, to avoid confusion I think we should stick
to using the name ConditionVariable for the primitive mechanism used
in pthreads and other thread libraries. We can use Monitor to refer to
the higher level abstration that Greg is proposing. We should not try
to merge these two concepts. Later on, if Greg has his way ;) we can
remove ConditionVariable from the public view.

Anotherwords, we are now at a identification and brainstorming phase.
Later on we can think about keeping or discarding the various concepts
we've identified.

Cheers,

Jeremy

Greg Colvin writes:
 > My suggestions seem to be getting lost in a flurry of nitpicking 
 > over the example code, so let me restate the idea.
 > 
 > 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.
 > 
 > 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.
 > 
 > 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.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 >