[Bordeaux-threads-devel] Clarifying some behavior in the documentation
Martin Simmons
martin at lispworks.com
Wed Dec 1 12:08:07 UTC 2010
>>>>> On Tue, 30 Nov 2010 13:27:13 -0500, Vladimir Sedach said:
>
> >> 1. At least one implementation (SBCL) requires that the lock on which
> >> condition-wait is called is to be held by the thread that calls
> >> condition-notify on the corresponding CV. This should be mentioned in
> >> the documentation as a requirement.
> >
> > Yes, this is a standard, but ill-documented, requirement for condition
> > variables. The lock is needed to synchronize the notify with the change to
> > the underlying data in the application.
>
> At least on Clozure, B-T implements condition-wait/notify with
> semaphores, so this appears to work fine, even though on other
> implementations it might lead to race conditions.
OK, I see what you mean -- the implementation of condition-notify might not be
thread safe within itself unless the lock is held.
I was referring to a different problem though. If you call condition-notify
without holding the lock, then you can lose notifications, i.e. condition-wait
might never wake up.
A typical use of condition-wait is like this:
(defun wait-for-it ()
(with-lock-held (lock)
(loop (when (application-state-says-ready-p)
(return))
;; **
(condition-wait cv lock))))
and the corresponding use of condition-notify should be like this:
(defun provide-it ()
(with-lock-held (lock)
(setf (application-state-says-ready-p) t)
(condition-notify cv)))
You must use with-lock-held to change the application state and notify
atomically w.r.t. the call to application-state-says-ready-p and
condition-wait. This is because, at least according to the pthreads
definition, condition variables have no memory of calls to notify that
occurred when noone was waiting. If provide-it can run (in another thread) at
the point labelled ** in wait-for-it, then the notify will be lost. The lock
prevents provide-it from doing that.
--
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/
More information about the bordeaux-threads-devel
mailing list