Re: Review: Boost.Threads

From: williamkempf_at_[hidden]
Date: 2001-09-21 14:02:17

--- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > >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.

And exists with every call, so why single out condition::wait() as a 
free function.  The logic is simply flawed (in that it's not really 
logic but your *perception* that some meaning is lost if it's not a 
free function, but this is PURELY a religious debate).

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

I agree.  I was following to the natural conclusion the logic you 
were applying for removal of condition::wait() as a member function 
and turning it into a free function "because it's the thread that 
waits".  I'm trying to illustrate why it's not the thread that waits, 
it's the condition that waits, which as a side effect causes the 
current execution context to block.  This clearly illustrates why I 
chose a different side to this *religious* debate.

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

What's misleading is trying to apply different logic in this specific 
case.  Even if I were to buy into the explanation that it should be 
different "because the point is to block the thread under certain 
circumstances" then you'd have to apply this logic to ALL blocking 
synchronization routines.  The logic doesn't follow, nor apply.
 
> > 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.

What I'm not "acknowledging" is that any readability is sacrificed.  
I'm doing so not because I haven't considered it, but because I don't 
agree with it, as illustrated by my arguments.  It will only be less 
readable to some, and the documentation will take care of them.  Even 
if it truly would be less readable to everyone, it still wouldn't be 
enough of a reason to violate OO design here (condition::wait() has 
to access state that's encapsulated and unavailable outside of the 
class, so to implement this as a free function we'd have to declare 
it as a friend, which is a very strong signal that you've violated OO 
design). 

Bill Kempf