This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients Sebastian.Noack, asvetlov, jyasskin, kristjan.jonsson, mklauber, pitrou, sbt
Date 2012-09-30.19:55:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
>A shared/exclusive lock isn't one lock but two locks, which are >synchronized, but must be acquired separately. Similar to a pipe, >which isn't one file, but one file connected to another file that >reads whatever you have written into the first file. So it isn't >strange to create two lock objects, as it also isn't strange that >os.pipe() returns two file descriptors

That's one way to look at it.  Another (and the more common) is to say that it is one lock, which can be in two different states.  The original patch is modeled on seveal such constructs that exist in the field, such as for example the SRW locks in windows:

(In fact, I am rather leaning back towards the RWLock name again, since that seems to be the most commonly used on other platforms.  Oh, how tempting it is to bikeshed about such trivialities.)

Note that in my last patch, I provide the exclusive_locked() and shared_locked() methods that return exactly such locks as you describe.

I'd much rather have a single RW Lock object, with retgular locking proxies, rather than two distinct object, attached only by some shared common variables.

Also, with the structured approach I suggest, you can relatively easily create such a lock that also works across process boundaries by implementing a concrete class with SharableLockBase as a base.
Date User Action Args
2012-09-30 19:55:19kristjan.jonssonsetrecipients: + kristjan.jonsson, pitrou, jyasskin, asvetlov, sbt, mklauber, Sebastian.Noack
2012-09-30 19:55:19kristjan.jonssonsetmessageid: <>
2012-09-30 19:55:19kristjan.jonssonlinkissue8800 messages
2012-09-30 19:55:18kristjan.jonssoncreate