[armedbear-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD

[Mark Evenson]

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 Evenson<evenson at panix.com>  wrote:
>> On 3/2/11 8:50 PM, Martin Simmons wrote:
>>
>>> 3) 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?


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."