[armedbear-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
evenson at panix.com
Fri Mar 18 08:12:34 UTC 2011
On 3/2/11 8:50 PM, Martin Simmons wrote:
> I think that the implementation of condition-wait has some major
Thanks very much for the comments.
I have an [updated patch] that attempts to address these issues for
further review for inclusion in BORDEAUX-THREADS.
> 1) If no other threads are trying to claim the lock, then
> condition-wait will return immediately rather than waiting.
I couldn't reproduce this behavior. In ABCL, the THREADS:OBJECT-WAIT
implementation is mainly a simple wrapping of the underlying
[java.lang.Object.wait()] which clearly should wait.
> 2) If two threads are waiting in condition-wait and two other threads
> call condition-notify, then it is possible that only one thread will
> return from condition-wait because the call to acquire-lock in one of
> them might return nil causing it to wait again.
The DO looping construct has been replaced with a simpler subsequent
BT:ACQUIRE-LOCK that should solve this bug.
> 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.
> Also, I think condition-notify should be using threads:object-notify
> rather than threads:object-notify-all.
We now use THREADS:OBJECT-NOTIFY.
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
More information about the armedbear-devel