Hello,
Gilbert Baumann writes:
The common use case is like this:
(defun reader () (with-lock-held (*lock*) (loop (condition-wait *condvar* *lock*) (when <something there> <consume>))))
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.
Also, you version seems to release the lock (through calling condition-wait) before consumption starts.
Perhaps we need a macro that captures the preceding idiom, like:
(defun reader () (with-condition-variable-and-lock (*condvar* *lock*) (loop while <something there> do <consume>)))
(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*)))
The notification cannot be lost since entering CONDITION-WAIT is while the lock is held at which point the writer cannot have it. Only after things are set up within the deep magic of CONDITION-WAIT to actually wait for the condition to be notified the lock is released.
OK, I think I got it.
Or put the other way round: The reader only releases the lock while being blocked within CONDITION-WAIT. The writer can only notify while holding the lock.
=> CONDITION-NOTIFY can only be called when the reader is blocked in CONDITION-WAIT => no notifications get lost.
qed :)
Thanks for the explanation.