[boost] Re: More on Boost.Threads

From: Jonathan Biggar (jon_at_[hidden])
Date: 2002-10-16 17:30:35

David Abrahams wrote:
> * On condition.html
> 
>    a. What is the effective difference between notify_one() and
>    notify_all()? In the absence of any information about the
>    underlying system's scheduling mechanism, it seems as though there
>    is none: either way, one blocked thread will get to execute with
>    the mutex locked. If there is a difference between the two in
>    practice, the documentation should give some indication of it.

This would depend on whether the condition variable has a deterministic
thread queueing model like FIFO, or picks threads at random to wakeup. 
That in turn, depends on the particular implementation behavior that the
OS provides.

>    b. What is the rationale for condition::wait() throwing lock_error
>    if !lock.locked()? Would it not be cleaner to simply lock the lock
>    if it arrives in an unlocked condition?

It is almost certainly an error to call condition::wait() without having
the lock, since the application code is responsible for testing the
application data that the condition and lock protect.  If you aren't
holding the lock, you either have a race condition or a deadlock
lurking.

>    c. What is the rationale for the non-looping versions of wait() and
>    timed_wait() which have no predicate? The docs say they're
>    dangerous and should always be used with a loop, so why provide
>    them?
> 
>    d. If the predicate form of wait(lock, pred) were implemented the
>    way it's specified, there would be a race condition:
> 
>       while (!pred()) wait(lock);
> 
>    Since the predicate is checked before the non-predicate form checks
>    for the lock being locked and throws an exception. Fortunately,
>    your implementation doesn't work that way.

This is only a race condition if the code violates the pre-condition
that the lock must be locked before testing the predicate and calling
wait().

>    However, I think I like:
> 
>       do { wait(lock) } while(!pred());
> 
>    better.

This deadlocks if the predicate is already true before the loop is
entered!

>   e. misuse of the term `model'. Types model Concepts, objects do
>   not. You should just be saying "mutex object", not "mutex model".
> 
>   f. The non-predicate form of timed_wait Effects: clause ends with
>   "...and then reacquires the lock". This appears to mean the lock is
>   reacquired regardless of whether timeout arrives before
>   notification. I think that can't be intentional. Can it?

Yes, that is intentional.  The required condition variable pre- and
post-condition logic for wait() is that the associated lock is locked. 
Without that, you get race conditions.

-- 
Jon Biggar
Floorboard Software
jon_at_[hidden]
jon_at_[hidden]