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, christian.heimes, jyasskin, kristjan.jonsson, mklauber, neologix, pitrou, sbt
Date 2012-10-04.10:29:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Ok, here is a new patch.  It takes into account various comments and suggestions:
1) The interface is java-like. a single RWLock instance only has attributes reader_lock and writer_lock.
2) Since the "owning" array needs only be process local, the same semantics can be used for multiprocessing.  Multiprocessing version only does minimal patching of the threading classes, similarly to Barrier.  There is implementation coupling between threading and multiprocessing but that is probably ok.
3) Test are there, except that the final tests in the multiprocessing, those that used to rely on data gathered in lists, are nerfed.  Not sure how to gather data when multiprocessing
4) I also didn't get the "manager" tests to work.  I don't know what managers are or what they are supposed to do, and why they use proxy objects.  I attempted to create a proxy object in but it failed the tests.  Also, I am unsure if it is sufficient to proxy only the RWLock object, or if the _ReaderLock and _WriterLock instances that are returned should be proxied too.

Documentation i stole from Java.
The locking policy is the same as the RecursiveReaderWiterLock from java, i.e. readers wait for writers, but otherwise no preference.  Recursion is provided for readers and writers, but not upgrade/downgrade.

Again, this is not intended to be final code, particularly I would like help and suggestions for the multiprocessing tests and the manager code.

Also, while I strongly prefer RWLock, or ReaderWriterLock, or something similar, basically because it fits with our already java-ized threading module and the terminology from everywhere else in the field today, I'm not going to be enormously difficult about it.

Date User Action Args
2012-10-04 10:29:48kristjan.jonssonsetrecipients: + kristjan.jonsson, pitrou, christian.heimes, jyasskin, asvetlov, neologix, sbt, mklauber, Sebastian.Noack
2012-10-04 10:29:47kristjan.jonssonsetmessageid: <>
2012-10-04 10:29:46kristjan.jonssonlinkissue8800 messages
2012-10-04 10:29:46kristjan.jonssoncreate