This is a Lock for handling both multiple readers and a single or multiple writers.  It allows any number of readers to acquire a 'lock' via a modified semaphore.  It also allows any number of writers to try to acquire a lock, which signals the lock to block new readers from acquiring, until the writers have had a chance to do their business.  Through a simple lock, multiple writers can wait in line, although only one writer can actually write at a time.

It also lets the developer use the 'with' statement, via  methods that return contextmanagers.

I actually had a couple of unimplemented ideas.

A) Writers can specify a deadline (or even use a default) such that after the deadline passes, the lock can use a callback to rollback/kill/pause readers, so that the writer doesn't wait an eternity.

B) Allowing the semaphore to have an upper limit of allowed readers (or anythings), Since I don't need it, i never programmed it, but it should be fairly trivial to implement if there is any demand.

The patch is unacceptable in its current form:
- it should be provided as a patch to threading.py, not as a separate module
- it should have a name that follows "the convention", which seems to be that 
  it should have "reader" and "writer" in its name (or "rw"). See how C# and
  Java do it (and other libraries you can find that provide such a mechanism)
- it needs documentation
- it needs tests.

Out of those four deliverables, i have three (albeit the easiest).  Attached is a copy of the newly dubbed ReadWriteLock along with his pal ReverseSemaphore, and two new helper objects ReadLock and WriteLock (can you do the java equivalent of anonymous inner classes?).  This is a patch on the copy of threading.py that is delivered with Fedora 7 aka:
Version: 2.5
Release: 12.fc7

which was done for convenience (my convenience that is, and certainly not yours ;))

The naming convention has been changed to follow that of Java's, the acquire/release pattern notwithstanding.  There is some documentation via docstrings, as I wasn't sure of the best way to document this module.

The last point, unit testing, I am not sure as the best way to go about a multithreaded unit test.  I can look into it later, but honestly, it's friday, and there are two days left till monday.

Please let me know if I am on the right track here at least.

Yaakov
File Added: threading.py

I'm skeptical about the implementation strategy chosen, in particular about the notion of a reversed semaphore, which I have never heard of. Is there prior art for such a construct?
Traditionally, rw locks provide certain fairness guarantees - why doesn't this implementation? To put it more bluntly: why is that so extravagant?

As for the style of the patch itself:
- please provide it as a unified or context diff. Making it relative to some released 2.5 version is fine.
- please drop the redundant pass statements
- documentation patches should be made against Doc/lib/libthreading.tex. If you cannot write LaTeX, just adding sections in plain text is fine.
- tests should be added to Lib/test/test_threading.py

Yaakov, do you have any interest in this, or should we close this.

Feel free to close this. I can't commit to maintaining this right now, if i ever find the time, i can reopen the issue.