Synchronisation vs Coordination

Two different questions, two different answers

Most concurrency confusion goes away once the problem splits into one of these two questions:

1. Are two threads about to step on the same data? That's synchronisation. The goal is only one thread inside the critical section at a time.
2. Does thread B need to wait until thread A has finished something? That's coordination. The goal is for B to sleep until A says go.

Both are real. They need different tools. Mixing them up is where the bad code comes from.

Two everyday pictures

Synchronisation is a single-occupancy bathroom. The lock on the door has one purpose: only one person inside at a time. There's no notion of "wait until someone specific is done." Whoever gets there first goes in. Everyone else waits in the hallway.

Coordination is a relay race baton handoff. Runner B isn't trying to be alone on the track. B is waiting for A to finish a lap and pass the baton. The lock is irrelevant; the timing is the point.

A mutex is the bathroom lock. A latch, channel, or condition variable is the baton.

Side-by-side: which tool for which job

                    SYNCHRONISATION                    COORDINATION
                    "one at a time"                    "wait for a signal"

Mutex                   Y primary use                  X wrong tool
RWLock                  Y primary use                  X wrong tool
Atomic / volatile       Y primary use (one var)        X wrong tool
Semaphore (count=1)     Y acts like a mutex            - awkward
Semaphore (count=N)     - rate-limit only              Y N-permit signaling

CountDownLatch          X wrong tool                   Y "wait until ready"
CyclicBarrier           X wrong tool                   Y "all N arrive, then go"
Condition variable      Y holds the lock               Y wait for predicate
Future / Promise        X wrong tool                   Y "wait for a result"
Channel (Go)            Y via send>recv ordering       Y "wait for a value"
Event (Python)          X wrong tool                   Y "wait until set"
Queue / BlockingQueue   Y protects internal storage    Y producer-consumer

The middle column ("primitives that do both") is real. A condition variable holds a lock (synchronisation) and lets a thread sleep on a predicate (coordination). A channel send orders memory (synchronisation) and delivers a value (coordination). A blocking queue does both at once.

That overlap is useful in design. It also means knowing which jobs each primitive handles cleanly and which ones must be bolted on.

Two failure modes from mixing them up

Failure 1: using a lock to coordinate. The code spins inside a while loop, taking the lock, checking a flag, releasing, sleeping, retrying. Wastes CPU. Often deadlocks. The right move is a latch, event, channel, or condition variable.

BAD: spin under a lock to wait for an event
---------------------------------------------
while (true) {
    lock.acquire()
    if (ready_flag) { lock.release(); break; }
    lock.release()
    sleep(50ms)              // burns CPU, races with the writer
}

GOOD: actually wait
---------------------------------------------
event.wait()                  // sleeps; wakes when set

Failure 2: using a channel where a lock would do. Three lines of mutex-guarded counter become twenty lines with a goroutine, a channel, a select, a shutdown protocol. The original problem was just "increment safely." The original tool is a mutex (or an atomic).

BAD: a goroutine + channel for what should be a mutex
---------------------------------------------
counter := newCounterActor()
counter.inc <- struct{}{}     // send to actor
val := <-counter.read         // ask the actor
// plus: spawn the actor, handle shutdown, drain the channel...

GOOD: just a mutex
---------------------------------------------
var mu sync.Mutex
var counter int64

mu.Lock(); counter++; mu.Unlock()

Both bugs come from not splitting the question first. Once it's split, the right primitive is usually obvious.