Fix lost wakeup in FiberSequencer when advance races the combiner

[vadimskipin]

The flat-combining drain loop coordinates via combinerState (FREE/BUSY/PENDING) and reads counter to decide which waiters to wake. A producer advances counter then calls drain; finding a combiner already running, it returns and relies on that combiner to observe the advance. counter and combinerState are distinct locations, so this is a StoreLoad (Dekker) handshake - and acquire/release does not provide StoreLoad ordering.

The advance could therefore be invisible to the combiner's terminal pass, which would read a stale counter, skip a waiter whose token was just reached, and exit - losing the wakeup permanently. It reproduces under thread oversubscription on both x86-64 and arm64.

Add the two seq_cst fences that complete the handshake: the producer half at the top of drain (before observing combinerState) and the combiner half on the PENDING re-loop (before re-reading counter).

[Copilot]

Pull request overview

Fixes a concurrency bug in FiberSequencer where an advance() racing an already-running combiner could result in a permanently lost wakeup due to missing Store→Load ordering between counter and combinerState. The PR completes the intended Dekker-style handshake by adding two seq_cst fences so the combiner cannot miss counter advances that arrive concurrently.

Changes:

• Add a std::memory_order_seq_cst fence at the start of drain() to order a caller’s prior counter advance before observing/acting on combinerState.
• Add a std::memory_order_seq_cst fence on the PENDING re-loop path to ensure the next counter load observes advances that caused PENDING.
• Minor control-flow refactor in advance() and drain() (do/while → for (;;) loop) while preserving semantics.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.