From: Scott McCaskill (scott_at_[hidden])
Date: 2001-09-14 17:27:27
> We're going to argue in circles now. I disagree totally about which
> object does the waiting. To me it *IS* the condition that does the
Disagree. While this description is technically correct, IMO it is too
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 to
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).
> > Absolutely it's subjective. Fortunately, it also seems clear-cut
> enough that a consensous on what is the primary effect is easily
> reached. For example, we both agree that when waiting on a
> condition, waiting is the primary effect and locking is a side
> effect. In the case of mutex::scoped_lock::lock, I'd say that
> locking (i.e. guaranteeing exclusive access) is the primary effect,
> and blocking is an undesireable but necessary side effect needed to
> accoplish it. For semaphore, both the waiting and signalling are
> important, but perhaps we can all agree on the reasonable view that
> incrementing and decrementing are the primary effects, and blocking
> is a side effect. What do you think?
> No, it's not clear-cut at all, and a consensus is no where near to
> being reached. Waiting is the primary effect, yes, but you're making
> this synonymous with the thread blocking, which is as much a side
> effect as the locking/unlocking of the mutex.
Sorry, I don't understand something. Could you please explain the
difference between "thread blocking" and what happens when condition::wait()
causes the calling thread to block? And also how this distinction is
relevant to users of condition?
> Most (not all if you include sleep, which is yet another
> reason I wouldn't care to do this) of these operations have a
> converse operation. If you lump one side into a single name, wait,
> I'd expect you to lump the other side into a single name, and that's
> where things break down.
I wouldn't assume this, nor do I see it as necessary.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk