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

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-09-10 16:33:24

From: "Peter Dimov" <pdimov_at_[hidden]>

> and perhaps you could also wait until specified time xt is reached with
> 
> wait(xt);
> 
> (replacing thread::sleep.) [ This probably goes too far. ;-) ]

Cute.  Hard to say whether its too cute.  It's difficult to shed my familiarity with the old C interface and get a fresh perspective.

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

It definately has the advantage of fewer parameters.  But it's not really the condition that's waiting, it's the "this_thread" object.

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

My mistake.  I was thinking that the additional argument (xtime) was templatized, and so wait(ScopedTimedLock&, const xtime&) would be ambiguous with wait(ScopedLock&, Pr).  But it isn't.  Given that, I'd say drop the timed_ prefix.

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

Quite reasonable.  I now appreciate the templatization.

Back to the sleep vs. wait question, I've had some time to think about that and attempt some legacy-bias-shedding.  The function in question is blocking the thread until some event occurs in exactly the same manner as the other wait functions.  The only difference is the type of event that wakes the thread back up.  Given this, sleeping and waiting are fundamentally the same thing, and don't really deserve varying terminology.  The history of using diverse, cute names for similar concepts from back in the UNIX days (e.g wait/sleep/pause/select, signal/alarm) is probably due in part to the lack of operator overloading.  There is little advantage in keeping legacy terminology (if inferior), since it will die off in time (unless new libraries such as this one perpetuate it).  So I'd say that wait(time) is the way to go.  The variation among wait operations seem rather analogous to the variation among operations of vector::insert.