From: MenTaLguY Date: 2008-03-11T12:56:03+09:00 Subject: Re: [PATCH] timeouts for ConditionVariable#wait --=-uZz16OfNBISQF7+R2IWg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 --=-uZz16OfNBISQF7+R2IWg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBH1gKKEpMFVe94r24RAgyXAJ431W8HUVlD6CWWVqiVyTc/Y25fLgCdHEMD SMV28C+hztFZpKdctgcwPw8= =8WO2 -----END PGP SIGNATURE----- --=-uZz16OfNBISQF7+R2IWg--