fix: prevent writer starvation in RWLock

[Waqar53]

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.

---

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 RWLock by tracking _waiting_writers and blocking new readers in r_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.}

[cursor]

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.

[cursor]

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)

• lib/crewai/tests/utilities/events/test_rw_lock.py#L242-L251