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
- 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%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.
- 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.