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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-22 14:13:54

----- Original Message -----
From: "William Kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 18, 2001 12:03 PM
Subject: [boost] Re: Review: Boost.Threads

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

Okay, but threading really lives in the domain of program control. Your
argument should apply equally well to control structures which we take for
granted in C++:

  for (int x = 1; x < 30; ++x)
     f();

do { y += 2 * y} while(y < 1000);

Hmm, there's no program counter object visible anywhere for the for loop to
operate on. So, applying your argument:

  int x;
  x.iterate(1, 30, f);

  lambda(var(y) < 1000).iterate(lambda(var(y) += 2 * var(y)));

My point is that it is already natural for C++ programmers to think of
controlling execution flow by appealing to "the computer":

do { something() } while(condition).

and "wait(condition)" falls into exactly the same system of thought.

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

A static function is fine, I guess, but the extra scoping seems
unneccessary.

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

Agreed, that would be silly.

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

No, it's just the idea that the condition waits (or sleeps, or whatever else
you choose to call it) that's really odd.

-Dave