Daniel Barlow writes:

Robert Strandh <strandh@labri.fr> writes:

...

Hmmm... This is not what the new version of the API seems to be saying, but instead

(defun reader () (acquire-lock *lock*) (loop while <something there> do <consume>) (condition-wait *condvar* *lock*))

In fact, I think in your version, release-lock will be called when it is already released (provided that with-lock-held calls release lock.

condition-wait reacquires the lock before it returns to its caller, so in fact Gilbert's version is balanced and this one isn't.

OK, I see that this fact is indicated in the API proposal. But then this part is not true: 1) A acquires the lock that safeguards access to C 2) A processes and removes all events that are available in C 3) When C is empty, A calls CONDITION-WAIT, which atomically releases the lock and puts A to sleep on CV 4) Loop back to step 1, for as long as processing should continue 4 should say loop back to step 2, right?

...

...

(defun writer () (loop (with-lock-held (*lock*) <add something to be consumed> (condition-notify *condvar*))))

This also does not correspond. I interpret the new version of the API like this:

(defun writer () (loop (with-lock-held (*lock*) <add something>) (condition-notify *condvar*)))

I think this is an API bug, and Gilbert's approach - *lock* must be held when calling condition-notify - is correct. It's certainly the way that Java does it (Object.wait/Object.notify)

No wonder I am having a hard time figuring this out when it is so hard to explain what it is supposed to do. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------