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

[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."