Re: [boost] Review: Boost.Threads

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-09-25 10:36:30

From: "Peter Dimov" <pdimov_at_[hidden]>
> 
> What I'm trying to say is that designing an uniform 'wait' layer is a
> serious task, and simply adding three wait overloads is unlikely to achieve
> the goal.
> 
> Another perspective: we have three categories of users:
> 
> 1. Threading experts;
> 2. Pthread programmers;
> 3. Programmers with little or no thread experience.
> 
> The problem we're trying to solve, AFAICS, is that the current design does
> not target (3). The proposed solutions so far concentrate on renaming
> functions. Does this help?
> 
> Not much, I'd say. We need another, higher level, abstraction layer that is
> specifically designed with (3) in mind. Let's leave the current low-level
> design suitable for (1) and (2). Using standard POSIX names (and semantics)
> is such a step.

Given the current direction of the threading library, this analysis seems accurate.  I think that it would be a shame for group (3) to be excluded from focus.  Certainly, end users will generally use higher level constructs that will be developed, but there will be times when the lower-level constructs being considered at this time will be the right tool, even for a non-expert.

So another way to broadly classify users is this:
(1) Experts who are familiar with threading concepts and legacy threading termonology
(2) New users who know neither the concepts or the termonology.

It is the second group that the Boost names should cater to.  They need names that help reinforce the concepts they are learning.  Every piece of history that ends up countering a new user's intuition is an addition hurdle and lessens the library's ability to "boost" the user's productivity.  The first group, on the other hand, has it easy; they need only learn a few new names and some minor adjustments to concepts they are already familiar with.

Given the audiance, history is the wrong place to look for names.  We should be looking instead at the present and future.  This makes Posix a lousy source to draw ideas from.  Why?  Because Posix primarily exists to standardize legacy names.  Take a look at its track record: putc, argv, execve, etc.  These are terrible names by today's standards.  Does this mean the Posix people did a bad job?  Of course not.  They were standardizing existing practice and were constrained by C.  Their mission was different than that of Boost.

How best to help the users most in need of help?  By seeking names and semantics that are out-of-the-box intuitive to the maximum extent possible.  If the rationale for a name choice must resort to history, it is likely that this goal has been compromised.

It is certainly true that making the library (new) user friendly takes more than good names.  Peter listed an excellent array of questions that I would love to see answered.  Granted, answers will not easily be forthcoming, but at least it makes sense to position the library so that when the answers are known, a minimum of changes will be needed.  That would seem to indicate that names supporting a common waiting framework would be a good idea.  Such names do a good job of saying what they do, so long as the functions can be tweaked to keep their semantics simple.  For example, Peter posed a question weeks ago whether waiting for a thread to complete can be made side-effect free; i.e. whether a subsequent wait has a defined (null) behavior.  I don't have the background to know whether this semantic is practical to implement, but I would love to find out.  It would be a valuable step to making the interface more orthagonal (and minimal).

Another issue raised recently was that notify_one has a unclear side effect.  This is certainly true.  Clearly a thread gets notified, but then what?  How does it react?  A better name is one that answers this question.  I propose resume_one.

Finally, there is the specific issue of how to model suspension of a thread until a condition is met.  The basic concept of a thread waiting (or blocked, paused, suspended, what have you), is easy for a user to grasp: the bottom line is that the program counter for that thread isn't going anywhere.  This isn't to say that there aren't other models that are also viable, such as considering a condition object as waiting.  This isn't wrong, but it also isn't out-of-the-box intuitive.  The thread-waiting model is intuitive and fully powerful.  It's the only model that is needed.  There just isn't any benefit that measures up to the cost of learning a new model.