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.