Event vs Condition vs Barrier: Localhost Lab

Intro — what this post promises

Need to wake N worker threads from one controller — threading.Event, Condition.notify_all / notify(1), or a Barrier? This lab measures wake latency and wakes/s for broadcast-style sync on Linux localhost.

Related links:

• 01shoppercove.comthreadpoolexecutor vs sequential localhost lab
• 02shoppercove.comprocesspoolexecutor vs sequential localhost lab
• 03shoppercove.comasyncio gather vs taskgroup localhost lab
• 04shoppercove.comprocess vs thread pool GIL localhost lab
• 05shoppercove.commmap vs read scan localhost lab
• 06shoppercove.comdeque vs list queue localhost lab
• 07shoppercove.comcsv reader vs split localhost lab
• 08shoppercove.compickle vs json roundtrip localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Pure stdlib threading. Affiliates: 0. No Docker. Timing starts after all waiters are known to be waiting (no lost-wakeup races in the Condition arms).

Verdict up front (128 waiters broadcast): Event ~8.071 ms (~15860 wakes/s); Condition.notify_all ~7.068 ms (~18110/s); Barrier ~9.247 ms. Event ping-pong handoff ~16325 ns (~61254/s).

Arms

Lab topology

N waiters in {4,16,64,128} · 7 rounds · p50 wall for wake+join
ping-pong: 5000 handoffs × 5 outer rounds

Script: lab-evidence/83-threading-event-vs-condition/results/run_lab.py.

Lead table — broadcast wake (p50)

notify(1) × N (after all parked) at N=128: ~1.194 ms — useful when you must release workers one at a time, not as a faster broadcast.

Ping-pong latency

Two threads alternating Event signals: ~16325 ns/handoff (~61254 handoffs/s). That is the cost of a round-trip wake for a simple flag protocol — fine for control planes, not a substitute for a lock-free queue in a hot path.

Reading it

• Event is the simplest broadcast: sticky set() is hard to misuse for one-shot “go” flags.
• Condition.notify_all matched or slightly beat Event at large N here (~18110 vs ~15860 wakes/s at 128) and wins when you need a predicate loop (while not ready: cv.wait()).
• Barrier is for rendezvous (everyone meets), not “one signals many” — wall time includes all parties arriving.
• notify(1) × N is a different pattern (fair one-by-one release), not a drop-in faster notify_all.

When to pick which

Lost-wakeup note

Bare Condition.notify before the waiter enters wait() loses the signal. This lab parks everyone (counter + cv.wait handshake) before timing notifies. Production code should use predicate loops, not sleep-and-hope.

Scaling sketch

From N=4 → 128, Event wake wall grew ~45× while wakes/s stayed in a ~15–22k band once N≥64. That is thread create/join and scheduler fan-out, not a futex-only number. For hotter fan-out, prefer a work queue over waking idle thread armies.

Pitfalls

• Using Barrier when you meant broadcast (or vice versa).
• Forgetting to clear() an Event between phases.
• Calling notify(1) without holding the lock / without predicates.
• Measuring wake time without ensuring waiters are blocked first (optimistic numbers).

Reproduce

python3 lab-evidence/83-threading-event-vs-condition/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box, process-local threads only. Not multiprocessing Events. Not futex microbenchmarks. Scheduler noise dominates at sub-ms wakes.

Takeaway

For waking N waiters, Event and Condition.notify_all are in the same band (~8.071–7.068 ms at N=128, ~15–18k wakes/s). Use Event for simple flags, Condition for predicates, Barrier for rendezvous, and treat ping-pong ~16325 ns as the two-thread handoff floor — not a throughput engine.