Closed 20352fad-961d-4fc9-904e-f350e717636e closed 14 years ago
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:
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:
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.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields: ```python assignee = None closed_at =
created_at =
labels = ['extension-modules', 'type-feature']
title = 'Read Write lock'
updated_at =
user = 'https://bugs.python.org/loupgaroublond'
```
bugs.python.org fields:
```python
activity =
actor = 'rutsky'
assignee = 'none'
closed = True
closed_date =
closer = 'terry.reedy'
components = ['Extension Modules']
creation =
creator = 'loupgaroublond'
dependencies = []
files = ['8065', '8066']
hgrepos = []
issue_num = 1744382
keywords = ['patch']
message_count = 6.0
messages = ['52800', '52801', '52802', '52803', '113375', '113521']
nosy_count = 4.0
nosy_names = ['loewis', 'terry.reedy', 'loupgaroublond', 'rutsky']
pr_nums = []
priority = 'normal'
resolution = 'later'
stage = 'test needed'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1744382'
versions = ['Python 3.2']
```