Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-18 06:37:44


From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "William Kempf" <williamkempf_at_[hidden]>
> > The *primary* action of condition::wait() is for the condition to wait
to
> be
> > signaled (in another thread), which (as a side effect) causes the
current
> > thread to block. Can you explain how condition::wait() is any different
> > from any other blocking operation in this regard? If not, how are the
> > distinction for the other blocking operations relevant to the users?
>
> 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.}

'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.

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk