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.17:19:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349025547.74.0.0202692057577.issue8800@psf.upfronthosting.co.za>
In-reply-to
Content
I can't say that I'm that familiar with multiprocessing to comment on that in particular.
But I do find your approach strange, to create two "lock-like" objects, in stead of the more familiar construct of having a "RWLock" (this is known from other languages) with two ways of claiming it.

Attached is a new patch.  I've adopted the name "SharableLock" perhaps it is bad.  It uses your idea of returning "lock-like" objects that do either shared or exclusive locking.

There are two implementations: SharableLock is much like the original patch, with two conditions and writer priority.
SimpleSharableLock drops all that, and uses a single condition and ad-hoc priority. I've added unittests that show that writer-starvation does not appear to be a problem.

Createing a Multiprocessing lock using the SharableLockBase should pose no difficulties.

The use of the SharableLock with Condition objects is forced to be Exclusive, since Condition objects typcially rely on their associated lock to synchronize internal state.
History
Date User Action Args
2012-09-30 17:19:08kristjan.jonssonsetrecipients: + kristjan.jonsson, pitrou, jyasskin, asvetlov, sbt, mklauber, Sebastian.Noack
2012-09-30 17:19:07kristjan.jonssonsetmessageid: <1349025547.74.0.0202692057577.issue8800@psf.upfronthosting.co.za>
2012-09-30 17:19:07kristjan.jonssonlinkissue8800 messages
2012-09-30 17:19:07kristjan.jonssoncreate