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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-10 15:04:04

From: "Ed Brey" <edbrey_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> > But your proposed uniform wait() syntax doesn't work AFAICS. wait() on a
> > condition variable needs additional argument(s).
>
> In general, I don't see the additional arguments posing any problem.  You
just
> overload wait() with arguments as needed.

There is no technical problem. I'm only saying that the syntax is not
uniform. You wait on a thread with

wait(t);

and perhaps you could also wait until specified time xt is reached with

wait(xt);

(replacing thread::sleep.) [ This probably goes too far. ;-) ]

but you wait on a CV with

wait(cv, lock);

or

wait(cv, lock, pred);

In the CV case I find the member syntax cv.wait(...) a bit easier to read.

> The only exception is
> condition::timed_wait().  It would be nice to also call this wait(), and
just let the
> argument type perform the differentiation, but the templatezation prevents
this.

It doesn't, timed_wait has one additional argument.

[...]
> That brings up a question I have.  What is an envisioned scenario for not
using
> a predefined locking class in the first place?  If there isn't one,
dropping the
> templates brings forth the possibility of making the interface even
smaller and
> more consistent.

What if Boost.Threads doesn't include a critical section forcing me to roll
my own? The current design handles anything that is a ScopedLock, and this
is a good thing.

--
Peter Dimov
Multi Media Ltd.