Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk