Author kristjan.jonsson
Recipients Sebastian.Noack, asvetlov, christian.heimes, jyasskin, kristjan.jonsson, mklauber, neologix, pitrou, sbt
Date 2012-10-03.10:44:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349261073.91.0.919055467667.issue8800@psf.upfronthosting.co.za>
In-reply-to
Content
I admit that I kind of like Java's approach to this.  First off, they define an interface, ReadWriteLock:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html
There, they also discuss the different choices an implementation of the interface can make, regarding a) policy, b) reentrancy, c) upgrading or downgrading.
A concrete implemention is then presented in the form of the ReentrantReadWriteLock, with documented behaviour for the above.
The rest of threading is also, as previously pointed out, more or less a rip-off from Java.

Since there is no single "correct" choice for the above, and since the implementation restrictions are different between inter-process and inter-thread locks, it would make sense to adopt a similar model, where a RWLock() function is a factory function, taking an argument specify a desired class of locks.

The policies that have been seen in this thread are:
a) greedy policy (no policy)
b) writer preference
c) 'Fair' (or in-order) preference.
All have their benefits and disadvantages.

We have also seen "recursive" and "nonrecursive".

The restrictions appear more serious in the inter-process case since I don't know if it is possible to maintain a shared dynamic array of thread ids across processes.
History
Date User Action Args
2012-10-03 10:44:34kristjan.jonssonsetrecipients: + kristjan.jonsson, pitrou, christian.heimes, jyasskin, asvetlov, neologix, sbt, mklauber, Sebastian.Noack
2012-10-03 10:44:33kristjan.jonssonsetmessageid: <1349261073.91.0.919055467667.issue8800@psf.upfronthosting.co.za>
2012-10-03 10:44:33kristjan.jonssonlinkissue8800 messages
2012-10-03 10:44:33kristjan.jonssoncreate