On 3/18/11 2:38 PM, Blake McBride wrote:
That is a particularly scary statement. Narrowing the window really means you are less likely to discover the bug in testing and more likely (because of Murphey's law and longer use) to discover it in production use. Can this be fixed without the reliance on luck?
On Fri, Mar 18, 2011 at 3:12 AM, Mark Evensonevenson@panix.com wrote:
On 3/2/11 8:50 PM, Martin Simmons wrote:
- If condition-notify is called by one thread when a waiting thread
is just about to enter the threads:synchronized-on form (but before it gets synchronized), then the notify will be lost. This happens because the underlying threading primitives have no "memory" of calls to notify when nothing it waiting (which is also the expected semantics for POSIX condition variables BTW).
THREADS:SYNCHRONIZED-ON is now the first form executed by BT:CONDITION-WAIT so the window here is considerably narrowed.
The current implementation is about as bare as one can get:
(defun condition-wait (condition lock) (threads:synchronized-on condition (release-lock lock) (threads:object-wait condition)) (acquire-lock lock))
I think all implementations of CONDITION-WAIT would have such a window as the environment gets setup to make the control transfer.
Maybe one could turn the CONDITION-WAIT into a macro?