Re: Review: Boost.Threads

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-09-17 09:16:22

From: "Scott McCaskill" <scott_at_[hidden]>
>>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.

The implementation doesn't have anything to do with the above description.

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

Threads never wait.  They block.  A thread blocking is always a side effect 
(until you introduce suspend() and resume() operations).  When you call 
condition::wait() the *side* effect is that the thread blocks, while the 
cause (the actual action taking place) is the condition waiting for a 
signal.  If you try and argue that the thread waits for the condition then I 
can also turn around and argue that the thread waits for the mutex to be 
locked.  Doing this turns the operations completely around from what they 
are, making the side effect the action and the action the side effect.

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

Again, this implies that *ALL* blocking operations (condition::wait(), 
thread::join(), mutex::lock(), semaphore::down(), iostream::read(), etc, 
etc) are actions taken by the thread.  They execute on a thread context, but 
they are not operations of the thread.  The opposite of condition::wait() 
isn't condition::run() but condition::notify_*().

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

The *primary* action of condition::wait() is for the condition to wait to be 
signaled (in another thread), which (as a side effect) causes the current 
thread to block.  Can you explain how condition::wait() is any different 
from any other blocking operation in this regard?  If not, how are the 
distinction for the other blocking operations relevant to the users?

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

Then you've made an arbitrary distinction, which only leads to confusion 
since the interface isn't consistent.

Bill Kempf

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp