On 3/18/11 4:41 PM, Ville Voutilainen wrote:

On 18 March 2011 17:37, Mark Evenson<evenson@panix.com> wrote:

...

This was the previous implementation, which was the subject of the criticism:

(defun condition-wait (condition lock) (check-type condition condition-variable) (release-lock lock) (do () ((acquire-lock lock nil)) (threads:synchronized-on condition (threads:object-wait condition))))

If this is directly mapped to a pthread implementation, the loop must be there.

I think it is slightly different, as the semantics of BT:CONDITION-WAIT are merely that the lock is always reacquired before returning. The caller of BT:CONDITION-WAIT is required to check for spurious wakeups.

...

I believe the race condition is on the the synchronization on the condition variable, not on the mutex lock.

The condition variable needs to use the mutex lock given, not a separate lock.

The condition variable interface is using the mutex lock specified in BT:CONDITION-WAIT. For the ABCL implementation, I'm using the Java monitor associated with the condition variable for the additional synchronization needed to implement BT:CONDITION-NOTIFY which couldn't use the mutex lock without contention problems. But definitely check my logic here, as it has been faulty before. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."