From vsedach at gmail.com Tue Nov 30 05:02:05 2010 From: vsedach at gmail.com (Vladimir Sedach) Date: Tue, 30 Nov 2010 00:02:05 -0500 Subject: [Bordeaux-threads-devel] Clarifying some behavior in the documentation Message-ID: Hello, I've encountered two cases that affect behavior of code but aren't clarified in the documentation: 1. At least one implementation (SBCL) requires that the lock on which condition-wait is called is to be held by the thread that calls condition-notify on the corresponding CV. This should be mentioned in the documentation as a requirement. 2. It is undefined what happens when release-lock is called inside a with-lock-held on the same lock. SBCL and Clozure appear to handle this "properly," although I think the documented behavior should be the same as with regular release-lock ("It is an error to call this unless the lock has previously been acquired (and not released) by the same thread," that is, it should be an error to call release-lock inside a with-lock-held). Thank you, Vladimir From martin at lispworks.com Tue Nov 30 12:27:28 2010 From: martin at lispworks.com (Martin Simmons) Date: Tue, 30 Nov 2010 12:27:28 GMT Subject: [Bordeaux-threads-devel] Clarifying some behavior in the documentation In-Reply-To: (message from Vladimir Sedach on Tue, 30 Nov 2010 00:02:05 -0500) References: Message-ID: <201011301227.oAUCRSbh004629@higson.cam.lispworks.com> >>>>> On Tue, 30 Nov 2010 00:02:05 -0500, Vladimir Sedach said: > > Hello, > > I've encountered two cases that affect behavior of code but aren't > clarified in the documentation: > > 1. At least one implementation (SBCL) requires that the lock on which > condition-wait is called is to be held by the thread that calls > condition-notify on the corresponding CV. This should be mentioned in > the documentation as a requirement. Yes, this is a standard, but ill-documented, requirement for condition variables. The lock is needed to synchronize the notify with the change to the underlying data in the application. > 2. It is undefined what happens when release-lock is called inside a > with-lock-held on the same lock. SBCL and Clozure appear to handle > this "properly," although I think the documented behavior should be > the same as with regular release-lock ("It is an error to call this > unless the lock has previously been acquired (and not released) by the > same thread," that is, it should be an error to call release-lock > inside a with-lock-held). I think release-lock can be allowed inside with-lock-held, as long as you call acquire-lock before exiting the body. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ From vsedach at gmail.com Tue Nov 30 18:27:13 2010 From: vsedach at gmail.com (Vladimir Sedach) Date: Tue, 30 Nov 2010 13:27:13 -0500 Subject: [Bordeaux-threads-devel] Clarifying some behavior in the documentation In-Reply-To: <201011301227.oAUCRSbh004629@higson.cam.lispworks.com> References: <201011301227.oAUCRSbh004629@higson.cam.lispworks.com> Message-ID: >> 1. At least one implementation (SBCL) requires that the lock on which >> condition-wait is called is to be held by the thread that calls >> condition-notify on the corresponding CV. This should be mentioned in >> the documentation as a requirement. > > Yes, this is a standard, but ill-documented, requirement for condition > variables. ?The lock is needed to synchronize the notify with the change to > the underlying data in the application. At least on Clozure, B-T implements condition-wait/notify with semaphores, so this appears to work fine, even though on other implementations it might lead to race conditions. > I think release-lock can be allowed inside with-lock-held, as long as you call > acquire-lock before exiting the body. Good point. There's a lot of variation of this in the implementations - for some implementations B-T uses the with-lock-held equivalent provided by the implementation, which might have different semantics, and in other implementations (like SBCL) all locks are recursive, so it's harder to track down lock/unlock mismatch errors. Now that I think about it some more it might be a good idea to not just specify more semantics in the documentation, but provide assertions for the specified behavior. It would be nice to do this based on optimize declaration safety level. Does anyone know of a library that provides access to declarations at macro-expansion time like CLtL2's Environments (http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html)? Vladimir