Kristján Valur Jónsson added the comment:

> 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.

----------

_______________________________________
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

Reply via email to