Re: [boost] Re: Review: Boost.Threads

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-22 13:59:33

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>

> > As counterintuitive as I find this way of thinking, I'm willing to
assume
> > you understand threads at a deeper level than I do, and when I get to
your
> > level I'll see that it all makes sense. So, if we make that assumption,
I
> > would want to see something more like condition::get() than
> > condition::wait(). The condition doesn't wait any more than a blocking
> read
> > from a file causes the file to wait. I don't really see any difference
> > between blocking and waiting, but if you insist that there is a
> difference,
> > it seems like we should abolish the term "wait". If anything, I think it
> > will confuse people.
>
> The only consistent approach to naming is to adopt POSIX names AS-IS. The
> POSIX committee has already done the arguing for us.
>
> This means thread::join, condition::{wait, signal, broadcast.}

Well, OK, but POSIX doesn't have member functions (or overloading) to work
with. When you write x.f() most of us think that "x is performing action
f()", and (overgeneralizing broadly here) nobody except thread library
implementors will find it natural to think of a "condition" performing an
action, especially one called "wait". A condition (speaking English here) is
a passive thing which arises out of the circumstances.

> 'sleep' is interesting because every 'sleep' primitive is usually named
> '*sleep' but takes duration, not an absolute time; so I favor
> thread::sleep(long ms) and thread::wait(xtime).
>
> Another point to keep in mind is that overloading interacts badly with
> generic algorithms, since taking the address of an overloaded function is
a
> bit complicated. IOW I can write
>
> std::for_each(first, last, thread::join);
>
> but given an 'uniform' wait() syntax I'll need
>
> std::for_each(first, last, (void (*) (thread &))thread::wait);
>
> Of course this doesn't really apply here since a container of thread's is
> impossible but the general argument against overloading is sound.

There are lots of ways around that problem, like defining forwading
functions, or using member functions on thread and condition (I have no
objection to implementing the global wait(condition) in terms of
condition.wait()).

I think one really needs to consider which interfaces will be the most
useful to most people, most of the time. We can never know for sure, of
course, but it seems as though programs using generic algorithms on
collections of conditions, even, would be very rare compared to programs
which deal with a few condition objects with distinct names.

Threading is difficult territory. It will lower the barrier to entry if
people are able to use a single name for a class of very similar operations.
Speaking as someone who hasn't had to do much threading, I know that if I'm
given a wait/sleep/etc. interface, the first thing I'll do (after figuring
out what's in the library and getting over my frustration at its seemingly
fractured naming system) is to write an interface layer that makes usage
more uniform.

-Dave