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

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-09-13 08:55:44

From: <williamkempf_at_[hidden]>
> > 
> > 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 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.

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.

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

> There can be multiple locks on a single recursive mutex.  So the 
> scoped locks maintain a lock state in order to determine whether or 
> not the mutex needs to be unlocked during destruction and each mutex 
> keeps it's own state that actually indicates whether or not it is 
> locked.  If the lock object has a locked state then you know the 
> associated mutex has a locked state as well, but if the lock object 
> is not locked you don't have any idea about whether or not the 
> associated mutex is locked.  Since lock objects have to maintain this 
> state the checks are "free" and so the exceptions help us to catch 
> errors.  Such checks are not necessarily free for mutexes, however, 
> so it's only recommended that they throw when errors in usage occur.

OK.  Thanks for the explanation.