Sebastian Noack added the comment:

Yes, you could also look at the shared/exclusive lock as one lock with 
different states. But this approach is neither more common, have a look at 
Java's ReadWriteLock [1] for example, which works just like my patch does, 
except that a factory is returned instead of a tuple. Nor does it provide any 
of the benefits, I have mentioned before (same API as Lock and RLock, better 
compatibility with existing code an with statement, ability to pass the shared 
or exclusive lock separetly around). But maybe we could satisfy anybody, by 
following Richard's and Antoine's suggestion of returning a named tuple. So you 
could use the ShrdExclLock both ways:

# use a single object
lock = ShrdExclLock()

with lock.shared:
  ...

with lock.exclusive:
  ...

# unpack the the object into two variables and pass them separately around
shrd_lock, excl_lock = ShrdExclLock()

Thread(target=reader, args=(shrd_lock,)).start()
Thread(target=writer, args=(excl_lock,)).start)


The majority of us seems to prefer the terms shared and exclusive. However I 
can't deny that the terms read and write are more common, even though there are 
also notable exmples where the terms shared and exclusive are used [2] [3]. But 
let us ignore how other call it for now, and get to the origin of both set of 
terms, in order to figure out which fits best into Python:

shared/exclusive -> abstract description of what it is
read/write       -> best known use case

The reason why I prefer the terms shared and exculsive, is that it is more 
distinct and less likely to get misunderstand. Also naming a generic 
implementation after a specific use case is bad API design and I don't know any 
other case where that was done, in the Python core library.


[1] 
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReadWriteLock.html
[2] http://www.postgresql.org/docs/9.2/static/explicit-locking.html
[3] http://www.unix.com/man-page/freebsd/9/SX/

----------

_______________________________________
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