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]