> If you want to argue it this way, I counter that the attributes
> "shared" and "exclusive" apply to the type of "access to the
> protected object" you are talking about, and yet, the name suggest
> that they are attributes of the lock itself.

A lock's sole purpose is to synchronize access to a protected object or context. So naming a lock after its type of protection absolutely makes sense. Those names are also not supposed to be attributes of the lock, rather two locks (a shared and an exclusive lock) should be created, that might be returned as a namedtuple for convenience.

> In that sense, "reader lock" and "writer lock", describe attributes
> of the user of the lock, and the verbs "readlock" and "writelock"
> describe the operation being requested.

The user of the lock isn't necessarily a reader or writer. This is just one of many possible use cases. For example in a server application a shared/exclusive lock might be used to protect a connection to the client. So every time a thread wants to use the connection, a shared lock must be acquired and when a thread wants to shutdown the connection, the exclusive lock must be acquired, in order to ensure that it doesn't interrupt any thread still processing a request for that connection. In that case you clearly wouldn't call the users reader and writer.


> The patch looks like it was produced using git rather than hg, so
> perhaps Rietveld got confused by this.  In that case it is a bug
> in Rietveld that it produced a partial review instead of producing
> no review.

Yes, I have imported the Python 3.3.0 tree into a local git repository and created the patch that way. Since patches generated with git are still compatible with the 'patch' program in order to apply them, I hope that isn't a problem.


> Although using namedtuple is probably a good idea, I don't think it
> really adds much flexibility.  This example could just as easily be
> written
>
>  selock = ShrdExclLock()
>
>  Thread(target=reader, args=(selock.shared,)).start()
>  Thread(target=writer, args=(selock.exclusive,)).start()

Yes, that is true, but in some cases it is more convenient to be able unpack the shared/exclusive lock into two variables, with a one-liner. And defining a namedtuple doesn't require any extra code compared to defining a class that holds both locks. In fact it needs less code to be implemented.

However the flexibility comes from having two lock objects, doesn't matter how they are accessed, instead as suggested by Kristján to have a single lock object, which just provides proxies for use with the with statement.


> I also think it is time to drop the "writer preference" model, since
> it just adds complexity with doubtful benefits.  Sebastian's model
> also does that.

I have implemented the simplest possible acquisition order. The lock acquired first will be granted first. Without that (or a more advanced policy) in applications with concurrent threads/processes that are heavily using the shared lock, the exclusive lock can never be acquired, because of there is always a shared lock acquired and before it is released the next shared lock will be acquired.