Author kristjan.jonsson
Recipients Sebastian.Noack, asvetlov, jyasskin, kristjan.jonsson, mklauber, pitrou, sbt
Date 2012-10-01.09:41:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349084476.44.0.271979814602.issue8800@psf.upfronthosting.co.za>
In-reply-to
Content
> Personally, I would prefer to make the shared and exclusive locks
> attributes of the same object, so one could do
> 
>    with selock.shared:
>       ...
> 
>    with selock.exclusive:
>       ...
> Please note, the "same object" could simply be a namedtuple instance.
With this, you are stuck with employing a context manager model only.  You loose the flexibility to do explicit acquire_read() or acquire_write().
My latest patch has methods shared_lock(), exclusive_lock() that return proxy lock objects that can be used like context managers like you describe, but you still have the flexibility of using the lock manually.

As for the bikeshedding, let's look at the list of concrete implementations out there:
Windows: SRW locks (slim reader writer) http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx
Pthreads: rwlock_t (reader/writer) http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/apis/users_86.htm
Java: ReadWriteLock, http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html

Am I missing anything?
Don't see why we need to adopt a completly different name or idiom to what people are used to.  Also, note that the java version is quite similar to Richard's proposal.
History
Date User Action Args
2012-10-01 09:41:16kristjan.jonssonsetrecipients: + kristjan.jonsson, pitrou, jyasskin, asvetlov, sbt, mklauber, Sebastian.Noack
2012-10-01 09:41:16kristjan.jonssonsetmessageid: <1349084476.44.0.271979814602.issue8800@psf.upfronthosting.co.za>
2012-10-01 09:41:16kristjan.jonssonlinkissue8800 messages
2012-10-01 09:41:15kristjan.jonssoncreate