Re: [boost] Re: More on Boost.Threads

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-18 07:48:34

"William Kempf" <williamkempf_at_[hidden]> writes:

> >From: Jonathan Biggar <jon_at_[hidden]>
> >
> >Sorry, I meant encapsulating the loop *and* the locking, so it would be
> >equivalent to:
> >
> >     lock->acquire();
> >     while (!predicate())
> >	cond.wait();
> >     action();
> >     lock->release();
> 
> As yet another alternative, possibly, but not as a replacement.  If
> the above were encapsulated into the wait(pred, act) function, the
> action function object would be difficult to construct in many cases
> since it would require access to data outside of the current scope
> (i.e. a closure).  This will occur more frequently with the action
> then with the predicate, btw.
> 
> Dave, this answers why we have a non-predicated version as well.
> Without a very elaborate lambda library (which isn't available on all
> compilers, and with out language support is still complex enough to be
> confusing and difficult to use for some users, etc.) there are many
> use cases where the predicate version puts a very high burden on the
> developer, where the non-predicated version, though easier to misuse,
> is by far easier to code.  More rationale, and possibly a lessening of
> the emphasis on the "danger" of using the non-predicate version.

I understand that. I'm not sure I'd de-emphasize the danger...

> As for locking the unlocked mutex in the wait... I'll have to ponder
> that one some.  It hadn't occured to me to do that since it would be
> wrong to do so in the non-predicated version.  For consistency, I'd
> probably reject this idea, but I should be fair and evaluate all the
> pros/cons of this.

I think the predicate and non-predicate versions are two very
different beasts, so the logic that applies to one may not apply to
the other. However, that might speak for changing the name of one of
them.

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html