[orthur2]

Summary

On 32-bit targets, a Barrier breaks after 2^32 completed generations. Its generation is a usize advanced with += 1, and poll treats a woken follower as done only when the generation it joined is less than the current one, while Drop checks for any difference. I reproduced both failure modes on v0.7.4 by starting the counter at usize::MAX. Debug builds panic on the overflow, and every later generation's final arrival panics again, so no waiter is released after that. Release builds wrap to 0, and polling a follower released by the wrapping generation re-registers its stale waker token, which panics on a vacant slot or makes a next-generation follower that reused the slot miss its wakeup.

The first commit makes the counter a u64 advanced with wrapping_add, and poll and Drop now share one identity check, BarrierState::is_completed, the same shape Phaser uses for its phase number. Two new unit tests start the counter at u64::MAX, poll or drop a woken follower after the wrap, and check with a counting waker that the next generation's follower is still woken. The existing drop test in barrier_test now asserts that wake as well. Before, it passed even with the check in Drop removed.

The second commit is a separate optimization. If you'd rather land only the fix, I'll drop it. A follower's first poll currently takes the state lock twice, once in wait to count the arrival and once in BarrierWait::poll to register the waker. Both now happen in the future's first poll under one lock, and the wait future stays at 40 bytes on 64-bit targets.

Design Notes

The identity check alone makes the wrap harmless, but a woken follower left unpolled for a full cycle of the counter would match the current generation again. With a 32-bit usize that cycle is 2^32 generations, so the counter is 64 bits on every target, which on i686 grows the wait future from 20 to 24 bytes and Barrier itself from 40 to 44 bytes. At the roughly 60 ns per generation of reused_generation_fanout/1 below, a full u64 cycle would take about 35,000 years. I also tried removing the counter and keeping per-node completion state in a WaitList. That closes the full-cycle case, but it would replace the WakerSet storage to cover a state that needs 2^64 generations.

Benchmarks

main is cbdcd0f. #412 landed after it but doesn't touch Barrier. Apple M5, macOS 26.4, Rust 1.96.0. These are the cases of cargo x bench --bench primitives -- barrier, which poll the futures by hand without an executor. I ran binaries for main, the first commit and both commits in rotating order. Each cell is the median of 12 rounds, each round the median of 5 runs, in ms. Change compares both commits with main.

Benchmark	main	First commit	Both commits	Change
reused_generation_fanout/1	313	306	294	-6.1%
reused_generation_fanout/4	216	213	192	-11.1%
reused_generation_fanout/16	179	179	155	-13.4%
cancel_pending	332	335	314	-5.4%

On 64-bit targets the first commit only changes a branch condition, so its column shows noise.

Validation

cargo x test (696 passed), cargo x check (26 feature configurations), cargo x lint, and Miri on the Barrier unit tests and barrier_test, natively and for i686-unknown-linux-gnu.