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

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-09-10 14:31:07

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

> > In this case, it is exactly the cleanliness of the OO design that I find
> > the member functions break.  The reason is that the wait functions are
> > not primarily acting on the object, but rather on the current thread.
> > The item being waited for is just a parameter, much as is auto_ptr x in
> > the statement: y.reset(x).  In this case, the object being acted upon
> > doesn't have a variable name, since it is the current thread.  We could
> > make a global called this_thread, so one could have
> > this_thread.wait_for(something).  That reads very nicely, but so does
> > wait_for(something), and it avoids the hassle of the global variable
> > just for syntactic sugar.  Still, the strongest argument seems to be how
> > the interface becomes very consistent and easy to read, with code always
> > looking like wait_for(something), where something is a magic overload of
> > all things that could be waited for.
> 
> I mostly agree with your pro-free arguments mainly because I've already came
> to the same conclusion (they are logically 'members' of the current thread.)
> 
> 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.  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.

However, for the common case of using the predefined locking classes, it would be possible to just use an overloaded wait by defining specific overloads for those classes, falling back on the template function only if necessary.

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.