On Sat, 30 Jun 2012 15:10:09 -0400, James M Lawrence said:
If release-lock fails then do not call acquire-lock.
What can cause release-lock to fail? Or do you mean that something might do an async throw on entry to release-lock? If so, what prevents an async throw on exit from release-lock in the new version (causing the opposite bug)?
On Tue, Jul 3, 2012 at 9:11 AM, Martin Simmons martin@lispworks.com wrote:
On Sat, 30 Jun 2012 15:10:09 -0400, James M Lawrence said:
If release-lock fails then do not call acquire-lock.
What can cause release-lock to fail? Or do you mean that something might do an async throw on entry to release-lock? If so, what prevents an async throw on exit from release-lock in the new version (causing the opposite bug)?
release-lock signals an error when the lock is not owned. Without the patch, when condition-wait fails in this manner it silently acquires the lock. To complicate matters, CCL lacks non-recursive locks (consecutive acquire-lock calls do not cause an error), so this local failure can cause a global problem which is not immediately detected.
If we are talking about interrupts then there are problems in either case, both before and after the patch. Making condition-wait robust in the face of interrupts is a different issue, and may not be possible here. One solution might be the following, although it may have implications of its own.
(defun condition-wait (condition-variable lock) (ccl:without-interrupts (release-lock lock) (unwind-protect (ccl:with-interrupts-enabled (ccl:wait-on-semaphore condition-variable)) (acquire-lock lock))))
On Sat, 2012-06-30 at 15:10 -0400, James M. Lawrence wrote:
If release-lock fails then do not call acquire-lock.
Thanks, patch committed
bordeaux-threads-devel@common-lisp.net
-
James M. Lawrence -
Martin Simmons -
Stelian Ionescu