Boost logo

Boost :

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

> 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

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

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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at