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

From: Scott McCaskill (scott_at_[hidden])
Date: 2001-09-18 14:15:40

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

No, a thread _object_ is not referenced.  But a thread _context_ always
exists.

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

I don't see why it matters whether there is any thread object, implied or
otherwise.  What matters is that a context of execution (a.k.a a thread)
always exists.

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

This comparison is misleading at best.  As with the other synchronization
functions, the whole point of condition::wait() is to block the thread under
certain circumstances.  If it didn't do this, it would be useless in a
multi-threaded program.  The same is _not_ true of most functions, such as a
function to read from a stream.  If someone were to implement a hypothetical
stream-reading function that _never_ blocks (i.e. is infinitely fast), it
would still be perfectly useable.

> 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 agree.  I acknowledge and appreciate the consistency of the naming scheme
you've come up with.  However, I think there are more trade-offs here than
you seem to be acknowledging.  In the present form of the API, it has
greater consistency at the expense of some readability.  IOW, that
consistency is not immediately apparent, and depends a great deal on one's
point of view.  This is why I have questioned it.

Scott McCaskill