Re: Review: Boost.Threads

From: williamkempf_at_[hidden]
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 
functions  are
> > > not primarily acting on the object, but rather on the current  
thread.
> > 
> > We disagree here.  To me you are waiting entirely on the 
condition, 
> > it's just a side effect that the current thread blocks.  Let us 
take 
> > 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 
think 
> > this does a poorer job of self documenting, so I'd elect to make 
this 
> > a static method on thread.  So we'd have thread::wait() with 
several 
> > 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
(semaphore)?
 
> 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 
orthogonal 
> > with other waits.  With other waits there's something that you're 
> > waiting on and an (optional) timeout.  With sleep() there's 
nothing 
> > 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.
 
Bill Kempf