Date: 2001-09-13 16:56:25
--- In boost_at_y..., "Ed Brey" <edbrey_at_y...> wrote:
> From: <williamkempf_at_h...>
> > >
> > > In this case, it is exactly the cleanliness of the OO design
that I find
> > > the member functions break. The reason is that the wait
> > > not primarily acting on the object, but rather on the current
> > We disagree here. To me you are waiting entirely on the
> > it's just a side effect that the current thread blocks. Let us
> > your viewpoint for granted though and carry it to its final
> > conclusion (I cheated and read some of the other posts on this
> > thread, so I'll reference things said later).
> I agree with you that blocking can be viewed as a side effect of
waiting on a condition. But given this view, the function is named
for its side effect, rather than its primary effect of locking and
unlocking the mutex. In addition, it isn't the condition that waits,
it's this_thread, but waits membership in condition implies
otherwise. I see two consistent approaches that can be taken: (1)
keep the function a member of condition and call it unlock_then_lock,
or something less, or arduous, or (2) make it a free function and
call it wait. In the latter case, blocking would be considered the
primary effect and unlocking and locking would be considered side
effects. Each view is equally valid. The second seems focus more on
the effects that the user cares about.
You're thinking a little too low level here (and I don't know if
thinking about it at the proper level will change your mind, but we
need to get up there to discuss this). The locking and unlocking are
side effects of waiting, not the primary functionality, nor what
causes the thread to block (though the locking could extend the
length of time that the thread blocks). The actual action is that of
the condition object waiting for a signal that some state has changed.
> > You contend that the action is on the current thread, not the
> > condition. I'd still not opt for a free function since I truly
> > this does a poorer job of self documenting, so I'd elect to make
> > a static method on thread. So we'd have thread::wait() with
> > overloads for the condition.
> Certainly not every function that blocks (waits) should be called
wait. Wait is only a good name if waiting is the primary (or only)
effect. For example, istream::open, printf and semaphore::decrement
open, print and decrement, plus block as a side effect, whereas wait
(xtime) just waits, wait(thread) just waits, and wait(condition,
lock) waits, plus has a side effect.
That's awfully subjective. What's a side effect and what's not?
What does mutex.lock() or semaphore.up() do that's not a side effect
thus eliminating them from candidates for wait(mutex) and wait
> Waiting on time and waiting on a thread seem rather clear-cut,
since they have no effects other than waiting. For example, waiting
on a thread (aka join) has only the effect of blocking the current
thread until some other thread terminates. The other thread is like
a tree in the forest, on its way to terminating independent of
whether anyone is listening (waiting) or not.
Actually, join() does more than wait for the thread to finish. It
also cleans up all resources associated with that thread. It's akin
to fstream::close() in this regard. But this is a different argument
from the one in this current discussion.
> > As for changing the name of sleep() to wait()... it's not
> > with other waits. With other waits there's something that you're
> > waiting on and an (optional) timeout. With sleep() there's
> > that you're waiting on. If it were renamed to wait() you'd be
> > waiting on nothing with a timeout, which I'd say should return
> > immediately with out blocking.
> The notion of thinking of sleep as waiting on nothing with a
timeout seems like a good one to me. Take it a step further and it
all works quite nicely. Consider that wait waits for a signal of
completion from whatever it is waiting for. It returns when it gets
that signal or when the timeout, if any, expires. If there is no
object to wait for, then wait never gets the signal of completion,
and so blocks until the timeout expires.
To me this just further shows how this concept is too ambiguous.
Given the name "wait" you and I have completely different notions of
what to expect. Given the name "sleep" we both have a clear
understanding of what to expect.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk