Re: Review: Boost.Threads

From: williamkempf_at_[hidden]
Date: 2001-09-25 15:21:55

--- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > A case for signal/broadcast:
> >
> > * Q: Why? A: POSIX.
> >
> 
> This (and existing literature) are the strongest arguments in favor 
of
> signal/broadcast, IMO.

Personally, I could care less about POSIX.  POSIX really is a small 
blip on the radar when discussing history.  It's ALL the other 
libraries, languages and literature that makes this compelling for me.

> > * Q: notify_* readable by non-experts, signal/broadcast not?
> >
> > A:
> >
> > It is a feature that signal/broadcast are unreadable by non-
experts. This
> > causes an immediate task-switch to documentation reading mode.
> >
> 
> That borders on intentional obfuscation.  Classes and methods 
should be
> named according to what they are or what they do, respectively.

And both signal() and broadcast() are meaningful for what is done. 
Not as intuitive as the others for newbies, but I find this argument 
less compelling then the inertia of historic usage.  Again, I can't 
state this enough.  Newbies should *NOT* be attempting to learn how 
to write MT programs by looking at MT code.  It's just too 
dangerous.  Threading is a complex and error prone way of 
programming, no matter how intuitive the idea of it is, or how 
intuitive the interface names are.  And when these newbies go to look 
at the literature they will find it confusing that everyone else uses 
terminology that we don't use in Boost.Threads.

> > notify_one/notify_all are readable enough that a non-expert would 
be
> tempted
> > to _not_ check what their precise semantics are - and get burned.
> >
> 
> One could make that argument for any well-named, non-trivial 
function.  API
> names are meant to be mnemonic, not substitues for documentation.

Exactly, and the vast library of documentation on the concepts (as 
opposed to the Boost.Threads library and it's documentation) will use 
the names signal() and broadcast(). 

Bill Kempf