sync.Cond

Canonical guidance

• use sync.Cond for condition waiting on shared state
• always wait in a loop
• hold the mutex while checking and updating the condition

Use when

• one state change wakes many waiters
• polling would be wasteful
• channels would create awkward ownership or fan-out

Avoid

• calling Wait without a loop
• using sync.Cond when a simple channel close would do
• guarding the condition with different locks

Preferred pattern

mu := sync.Mutex{}
cond := sync.NewCond(&mu)
ready := false

mu.Lock()
for !ready {
	cond.Wait()
}
mu.Unlock()

Anti-pattern

• treating Signal as if it permanently makes the condition true

Explanation: This anti-pattern is tempting because wake-ups feel definitive, but the real contract is the shared condition, not the wake-up event itself.

Why

• sync.Cond is low-level but sometimes the cleanest fit for shared-state coordination