[I'm not sure I was able to cancel a previous reply. The previous reply
contained a wrong patch which still contained the (SIGNAL-DEADLINE) in
the ETIMEOUT case.]
"Tobias C. Rittweiler" <tcr@...> writes:
> Hi all!
> I think I found a subtle bug in CONDITION-WAIT and deadlines:
> Let's say the FUTEX-WAIT in CONDITION-WAIT's definition returns due to
> After the return of FUTEX-WAIT, the mutex is reaquired.
> Notice, however, that GET-MUTEX may involve signaling due to
> exhaustion of the current deadline!
> Let's say that deadline is signaled there, and defered in the handler.
> We return from GET-MUTEX back into CONDITION-WAIT,
> get into the (1) clause of the CASE due to FUTEX-WAIT's previous
> and signal the old deadline _again_!!!
> At least that's how I explain a failure that I'm currently seeing.
> I'll try to come up with an independent test case, and a patch in the
Bug is now logged at
Test case can be found there.
Patch is rather easy:
--- target-thread.lisp.~1.116.~ 2009-12-11 00:27:40.000000000 +0100
+++ target-thread.lisp 2010-01-26 20:43:49.000000000 +0100
@@ -574,7 +574,7 @@
(futex-wait (waitqueue-data-address queue)
- ;; our way if saying "no
+ ;; our way of saying "no
(or to-sec -1)
(or to-usec 0))))
@@ -584,8 +584,10 @@
;; them before entering the debugger, but this is
;; better than nothing.
(allow-with-interrupts (get-mutex mutex)))
- ;; ETIMEDOUT
- ((1) (signal-deadline))
+ ;; ETIMEDOUT; we cannot signal a deadline unconditionally
+ ;; here because the call to GET-MUTEX may already have
+ ;; signaled it.
;; EWOULDBLOCK, -1 here, is the possible spurious wakeup
I'm going to install this once 1.0.35 is out, along the test case.