[armedbear-devel] [Bordeaux-threads-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
Chun Tian (binghe)
binghe.lisp at gmail.com
Mon Mar 21 14:21:42 UTC 2011
Hi, Mark
I'm interesting in your work.
First, I'd like to know, how to do a "condition variable wait with timeout" with your exist work,
Second, do you think it's possible to make ABCL supporting some atomic operations, something like ATOMIC-INCF or ATOMIC-PUSH, this can be very useful to implement some lockless algorithms.
Regards,
Chun Tian (binghe)
在 2011-3-18,15:50, Mark Evenson 写道:
> On 3/2/11 8:50 PM, Martin Simmons wrote:
>
>> I think that the implementation of condition-wait has some major problems:
>
> Thanks very much for the comments.
>
> I have an [updated patch][1] that attempts to address these issues for
> further review for inclusion in BORDEAUX-THREADS.
>
> [1]:
> http://detroit.slack.net/~evenson/abcl/bordeaux-threads-abcl-20110318a.diff
>
>> 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()][2] which clearly should wait.
>
> [2]:
> http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#wait%28%29
>
>> 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."
>
>
> _______________________________________________
> Bordeaux-threads-devel mailing list
> Bordeaux-threads-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
More information about the armedbear-devel
mailing list