Re: [boost] Review: Boost.Threads

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-25 12:05:50

I hate to just stand on the sidelines and declare "hear, hear!", but,
well...

   "hear hear!"

I also found Peter's arguments quite compelling. This speaks well of the
level of discourse we have here.

I realize that the problems Bill K. has had to face in designing this
library were/are substantial, and there is definitely some value in limiting
the scope of any problem we try to solve at one time. Maybe we just have to
say, "as a first step, we can't expect to come up with ``good'' names and
easy semantics right away".

All the same, it is never satisfying to have to lower one's standards, and
we know we can do better in the long run. At boost, however, we are all
volunteers. It behooves us to acknowledge the impressive job Bill has done,
much of which was the research that allows him to engage with authority in
debates over the library's design. Part of that acknowledgement, I think,
has to be the willingness to pick up the ball at this point. If we are going
to server community (2) below, some of us may need to begin the design of an
appropriate interface layer.

-Dave

----- Original Message -----
From: "Ed Brey" <edbrey_at_[hidden]>

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.
>
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>