Re: [PATCH] timeouts for ConditionVariable#wait

On Tue, 2008-03-11 at 10:56 +0900, Nobuyoshi Nakada wrote:
> Mutex#sleep is not guaranteed that it exits in the specified
> time, it just sleeps the time with unlocking, and tries to
> achieve the lock again.  If another thread takes the lock at
> that time, it sleeps forever.
>=20
>   $ ruby19 -e '
>   m=3DMutex.new
>   Thread.start{sleep(1); m.synchronize{sleep(10)}}
>   m.synchronize{p m.sleep(2)}'
>   11
>=20
> So I don't think your implementation is very intuitive or
> intented.

It is correct and intended.

In order to preserve correct semantics for condition variables, wait
*MUST* re-acquire the mutex before it returns, and therefore it may have
to compete with other threads in order to do so.  This is the case with
essentially all modern condition variable implementations, including
pthread_cond_timedwait() in POSIX and Object.wait in Java.  This is also
likely the reason that Mutex#sleep was written the way it was, since it
is used as the basis for Ruby 1.9 condition variables.

In real-world practice, the results of this behavior are not especially
counter-intuitive, since condition variables are used in ways which tend
to remove the need to hold their mutex for long periods of time.

> Timeout.timeout works properly in such case.

No it doesn't, for two reasons:

 1. it evidently does not guarantee that the mutex will be correctly
re-acquired upon timeout (if it did, it would display the same behavior
as my wait timeout implementation)

 2. the delivery of an exception injected via Thread.raise is
uncontrolled, potentially leaving the wait list or user data structures
in an inconsistent state

-mental