Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-15 15:45:44

----- Original Message -----
From: "Scott McCaskill" <scott_at_[hidden]>

> Threads wait; conditions cause threads to wait. From a usage standpoint,
> when I call condition::wait(), I'm more interested in the effect (calling
> thread may be blocked) than the cause (condition may cause calling thread
> block).
> condition c;
> c.wait( lock );
> I read that as telling the condition to wait. But that makes no sense;
> conditions don't wait, they _cause_ threads to wait (or block, or whatever
> name you prefer). In this context, the ability of a thing to wait implies
> also the ability to not wait (continue, run, etc.) and these are clearly
> properties of a thread (not of a condition).

Though I've mostly stayed out of this conversation, I find myself coming
down strongly in favor of taking Scott's approach. Overloading wait() makes
a /lot/ of sense: it unifies functions which have the same action, but use
different criteria. In many ways, it seems to fall into the same category as
std algorithms which are overloaded to accept predicates.


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