Boost logo

Boost :

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


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


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

but you wait on a CV with

wait(cv, lock);


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

It doesn't, timed_wait has one additional argument.

> That brings up a question I have. What is an envisioned scenario for not
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at