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

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

Disagree.  While this description is technically correct, IMO it is too
implementation-centric.

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

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