From: Nikodemus S. <nik...@ra...> - 2010-03-23 09:29:57
|
On 23 March 2010 10:59, Tobias C. Rittweiler <tc...@fr...> wrote: > (with-test (:name (:condition-variable :wait-multiple)) > (loop repeat 40 do > (let ((waitqueue (sb-thread:make-waitqueue :name "Q")) > (mutex (sb-thread:make-mutex :name "M")) > (failedp nil)) > (format t ".") > (finish-output t) > (let ((threads (loop repeat 200 > collect > (sb-thread:make-thread > (lambda () > (handler-case > (sb-sys:with-deadline (:seconds 0.01) > (sb-thread:with-mutex (mutex) > (sb-thread:condition-wait waitqueue > mutex) > (setq failedp t))) > (sb-sys:deadline-timeout (c) > (declare (ignore c))))))))) > (mapc #'sb-thread:join-thread threads) > (assert (not failedp)))))) > > The test case is bogus because it does not account for spurious wakeups > in CONDITION-WAIT. Agreed. > With the current code (which uses NIL as futex token in CONDITION-WAIT), > spurious wakeups may only come due to the futex() syscall returning > EINTR -- I can't judge whether that's really impossible in the above > code, but it's highly unlikely at least. > > Using NIL as futex token is a bug though (as I depicted in the "lost > wakeup" threads of the last month) -- and fixing it, will make spurious > wakeups less unlikely--making this test case fail almost reliably on a > highly parallel machine. Since the commit that introduced that test-case also introduced the NIL as futex token, I'm OK with removing the test-case. Gabor might have something to say about pessimizing waitqueues again, though... For the record, I think Paul was on to something when he proposed a max timeout as a way to deal with lost wakeups. Maybe a :fast <max-timeout> keyword to make-waitqueue that means using NIL as the wait token, thread as the wakeup token, and using the max timeout for futex_wait -- so lost wakeups at most incur a <max-timeout> cost? Cheers, -- Nikodemus |