Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request check-list
Please make sure to review and check all of these items:
NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.
Description of change
This implements the reader-write lock requested in #2372. It is a pretty sizeable standalone feature that may take a while to review.
The interface and implementation I think are explained decently well in docstrings and comments. Briefly: the lock state is stored in three keys:
<prefix>:write
: Standard mutex lease<prefix>:write_semaphore
: Semaphore that tracks waiting writers, implemented as an ordered set.<prefix>:read
: Semaphore that tracks readers.I tried to keep the interface (and implementation) similar to the existing
Lock
class while taking inspiration from the Rust and C++ standard libraries for the new bits. I got rid of thread-local state since each read/write guard now generates its own token.Other than supporting multiple readers, the only really "new" feature is the
max_writers
parameter, which can be used to cap the number of waiting writers. Typically I expect most users would only choose 0/None (unlimited) or 1 (guarantee single writer).Benchmark stuff
Other than tests, I included a "benchmark" which is in reality a simulation of the use-case that I originally wanted this feature for. It simulates a group of workers reading a cached value with expiration. When the cached value expires, the workers coordinate so only one tries to replace the cached value at a time. It also tries to verify that no concurrency errors occurred.
The simulation adds dev-dependencies on
pandas
(for computing min/mean/p95/max) andmatplotlib
(for reproducing graphs). The matplotlib dependency is not necessary to run the benchmark, however.I primarily wrote this simulation to provide empirical evidence of the correctness and viability of my design and implementation. Admittedly, I don't think the quantities it measures are very meaningful as-is from a rigorous performance perspective, so I'll leave it to maintainers to decide if it should go in or be omitted/replaced with a more useful benchmark.
Sample run output