Kristján Valur Jónsson added the comment: >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: http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx (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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8800> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
