Re: Review: Boost.Threads

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-09-18 11:03:37

From: "David Abrahams" <david.abrahams_at_[hidden]>
>From: "William Kempf" <williamkempf_at_[hidden]>
>>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?
>
>As counterintuitive as I find this way of thinking, I'm willing to assume
>you understand threads at a deeper level than I do, and when I get to your
>level I'll see that it all makes sense. So, if we make that assumption, I
>would want to see something more like condition::get() than
>condition::wait(). The condition doesn't wait any more than a blocking read
>from a file causes the file to wait. I don't really see any difference
>between blocking and waiting, but if you insist that there is a difference,
>it seems like we should abolish the term "wait". If anything, I think it
>will confuse people.

I don't find it counterintuitive at all.  Let me give a few examples.

The argument is that the action really should be understood as telling a 
thread to wait for the condition to be signaled.  But the proposed interface 
points out a failing in this thinking because no thread object is referenced 
anywhere within the interface:

wait(cond);

The only argument that can get us back to the idea that it's the thread that 
is doing the action is to claim there's an implied thread object (similar to 
the implied "this" in class methods) for the current thread.  To me that 
certainly obscures the understandability of the interface, which is why I 
suggested static methods instead.

thread::wait(cond);

However!  I can make the same claim about *ANY* method, free, class static 
or class instance.  After all, it's the thread that does the work, using the 
same logic applied to this particular action.  So we should have the 
following as well:

thread::read(stream, ch);

See, the thread *object* isn't performing any action.  The condition object 
is performing the action within the context of the current thread of 
execution.  The action it's performing is to wait for a notification.  
Because it's waiting within the context of the current thread of execution 
it blocks that thread as a side effect.

If you find the name to be confusing that's an entirely different argument, 
and one that I truly hate.  In this case the name is totally logical and 
meaningful to me, and seemed to be to everyone until it was suggested that 
it be made a free function for reasons that I don't think apply.  There's 
something wrong if the reasons they don't apply make it so that the name no 
longer makes sense to you.  I disagree with all of this (obviously), so I'll 
need some convincing that the name isn't still valid.

Bill Kempf

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