Kristján Valur Jónsson added the comment: Here is a new patch. it is complete with: threading implementation and tests multiprocessing implementation and tests.
Let's leave the naming bikeshedding a bit and focus on some practical aspects: 1) The threading version contains a RWLock and a FairRWLock. Both support recursion, although not upgrading from read to write access. This is achieved with a list of 'owning' threads. 2) the "Fair" version provides 'write' priority, blocking further first acquisitions in read mode until no writers are waiting. Multiprocessing: Because there is no way I know to share a list of owning thread ids, this version is more limited: a) The RWLock() only contains one owing thread ID. This allows recursion but some error checking present in the threading version cannot be implemented. b) the FairRWLock() again provides writer priority. But to do that, we have to allow 'recursive' read if a writer is waiting, if we allow recursion at all. And for that, we need to know what threds own the lock in read mode. Since we don't have that information, this version of the lock disallows recursion alltogether. Discussion: Recursion/No recursion? The Windows SRW locks disallow recursion. Their rationale is here: http://msdn.microsoft.com/en-us/magazine/cc163405.aspx: "First, regarding recursive acquires: if the locking policy you’ve designed for your application requires that synchronization objects be acquired recursively, this is very possibly a red flag telling you to re-examine your locking policy to eliminate the recursion. This is our opinion and results from the additional overhead of executing the lock acquisition and release code multiple times and, perhaps more importantly, because ensuring that the balance of lock releases with the lock acquisitions is often difficult to prove correct." Of course the SRWLock is a "slim" lock and thus can be forgiven for not providing such functionality. "Fair" vs "Non-fair" (Fair is not a good term, writer priority would be better). The reason I'm coming back to this being useful is tests using the multiprocessing module. The tests there show without doubt that a simple greedy locking algorithm fails miserably if there are more readers than writers. The test "test_writer_success" has been adorned with a timer, and the simple version completes in 15 seconds, while the "fair" version completes in 0.5 seconds. Good times! ---------- Added file: http://bugs.python.org/file27385/rwlock.patch _______________________________________ 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
