- 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.
I think release-lock can be allowed inside with-lock-held, as long as you call acquire-lock before exiting the body.
Good point. There's a lot of variation of this in the implementations - for some implementations B-T uses the with-lock-held equivalent provided by the implementation, which might have different semantics, and in other implementations (like SBCL) all locks are recursive, so it's harder to track down lock/unlock mismatch errors.
Now that I think about it some more it might be a good idea to not just specify more semantics in the documentation, but provide assertions for the specified behavior. It would be nice to do this based on optimize declaration safety level. Does anyone know of a library that provides access to declarations at macro-expansion time like CLtL2's Environments (http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html)?
Vladimir