Conversation
Add _waiting_writers counter so new readers block when writers are waiting for the lock. Without this, a continuous stream of readers can indefinitely starve writers. Changes: - Add _waiting_writers field initialized to 0 - r_acquire now blocks when _waiting_writers > 0 - w_acquire increments _waiting_writers before waiting, decrements in finally block after acquiring - Add test_writer_not_starved_by_continuous_readers test This is standard practice for production RWLock implementations and does not change behavior when there are no waiting writers.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
This is the final PR Bugbot will review for you during this billing cycle
Your free Bugbot reviews will reset on February 28
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| """Acquire a read lock, blocking if a writer holds or is waiting for the lock.""" | ||
| with self._cond: | ||
| while self._writer: | ||
| while self._writer or self._waiting_writers > 0: |
There was a problem hiding this comment.
Nested read locks deadlock when writers are waiting
Medium Severity
The _waiting_writers > 0 check in r_acquire breaks re-entrant read lock support. If a thread already holds a read lock and a writer begins waiting, a nested r_acquire on the same thread will block on _waiting_writers > 0, while the writer blocks on _readers > 0 from the outer read — a classic deadlock. The existing test_nested_read_locks_same_thread test passes only because it has no concurrent writer, giving false confidence that reentrancy still works.
Additional Locations (1)
|
This PR is stale because it has been open for 45 days with no activity. |
|
Closing this PR as stale due to inactivity. If you believe this change is still needed, please open an issue and reference this PR. |
Add _waiting_writers counter so new readers block when writers are waiting for the lock. Without this, a continuous stream of readers can indefinitely starve writers.
Changes:
This is standard practice for production RWLock implementations and does not change behavior when there are no waiting writers.
Note
Medium Risk
Changes core concurrency/locking behavior and may affect throughput/latency or expose subtle deadlocks under edge scheduling, though the change is small and covered by a new regression test.
Overview
Prevents writer starvation in
RWLockby tracking_waiting_writersand blocking new readers inr_acquire()whenever a writer is queued.Updates
w_acquire()to increment/decrement the waiting-writer counter around the wait loop, and adds a regression test (test_writer_not_starved_by_continuous_readers) that simulates continuous readers and asserts a writer acquires the lock within a timeout.Written by Cursor Bugbot for commit 43706a5. This will update automatically on new commits. Configure here.