[rokadepiyush49-rgb]

Summary

Reduce fresh LazyCell forcing cost by taking two of three internal semaphore permits instead of locking its state Mutex, following #412 for OnceCell. The Mutex guard always released through the semaphore's wait-queue lock; the spare permit lets an uncontended release skip it while still allowing only one caller to drive the stored future.

On an Apple M4 (macOS), three alternating rounds of ten runs reduced the median for seven million LazyCell::new constructions and first forces from 309–317 ms to 115–127 ms, and for LazyCell::from_future from 280–309 ms to 130–141 ms. Forcing an initialized cell stayed at about 300 ms for 85 million operations. An allocation counter observed one 64-byte allocation per fresh cell before this change and none after.

Add once::force benchmarks for both constructors and an initialized cell, plus regression coverage for a queued caller resuming the same pinned future after the driver is cancelled, poisoning observed by a queued caller, cancellation after a partial or full permit grant, and completion observed from another thread. The handoff case is also covered by the Miri unsafe_paths_test target.

Fixes #399.

Design Notes

LazyCell uses the internal semaphore with a small permit guard rather than the public Semaphore, so lazy-cell = ["mutex"] is unchanged; depending on semaphore instead would change which modules the feature enables. With the state in an UnsafeCell, Sync is implemented with the bounds the Mutex previously produced (T: Send + Sync, Fut: Send, F: Send), and Send remains automatic.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.