In message <20001004110040.A26666 / xs4all.nl>
hipster / xs4all.nl writes:

> Apperently CV::wait should use mutex.synchronize instead of exclusive
> unlock.

That's because ConditionVariable is NOT for general synchronization,
but condition variables in a monitor like context.
ConditionVariable#wait(mutex) means ``wait on a condition represented
by ConditionVariable, releasing lock for other threads do their job in
a critical region the waiting thread was held and the condition is
met.

Well, ``Threads wait on a same ConditionVariable must be acquire the
lock passed as the argument of ConditionVariable#wait''.  More
integrated version of condition variables are seen in monitor.rb.


> Broken As Designed  ;)
> The current CV implementation has an implicit precondition that wait
> is called before signal: there's no state kept about the number of
> signals received, any waiters are run and that's it. Your code
> obviously doesn't satisfy this precond (eventually).
> 
> IOW: CV is the wrong primitive for what you want to achieve.

Certainly.  The name `ConditionVariable' is stand on the paper or
successive texts describing concurrent programming with monitors.  So
it's not so strange that it is called so.  But native speaker's common
sence may not accept it....

As synchronization primitive needed in this context, Michael's
Semaphore or standard Queue can be used.  Of cource, new primitive
that has proper name can be introduced.  Arbitrary number of Threads
wait on it and can be signaled one by one, or one at a time, with or
without history sensitivity.  ....That cannot be distinguished
counting semaphore with broadcasting (that is, Michael's) for me :-P


-- 
kjana / os.xaxon.ne.jp                                October 4, 2000
What can't be seen is what can't be there.