Reduce uncontended Mutex lock and unlock overhead #403

Repeatedly acquiring and dropping a borrowed Mutex guard on the same mutex took 322 ms versus 199 ms for async-lock. The ordering changes under contention. With four queued waiters, Asyncband was faster than async-lock and behind Tokio.

Apple M4 Max, macOS arm64, rustc 1.101.0-nightly. Each cell gives rank, elapsed time relative to Asyncband and the whole-batch median over 10 interleaved runs. Lower is faster. Supplemental measurements

MutexGuard::drop returns the sole permit through release_with_lock, which takes the semaphore's queue lock even when nobody is waiting. This benchmark reuses the same mutex across rounds. In a separate run, substituting parking_lot for the internal lock moved the Asyncband median from 334 to 312 ms, with async-lock at 198 ms. The cost of taking the queue lock on each uncontended release is worth isolating.

First contribution

Profile acquisition and guard drop separately with an empty queue and with a registered waiter. Compare a candidate against both rows. Keep FIFO order for queued callers and verify that cancelling a waiter or a granted handoff still lets the next caller progress. Cross-check future-size work already under review in #394. Related PR #394

To run the supplemental peer_checks command below, save and run peer-checks.rb from the linked comment in a disposable checkout of 6102089. The benchmark and library sources match 36ba6f2. Generator and instructions

cargo x bench --bench primitives -- mutex::lock::uncontended_reuse --repeat 10 --raw
cargo x bench --bench peer_checks -- mutex/ --repeat 10 --raw

Performance tracking issue #396