Mutual Exclusion: Why Should Shared State Have Only One Editor at a Time?

Mutual exclusion allows several activities to proceed concurrently while admitting only one of them at a time to a particular critical operation. It does not protect all work; it protects the small part that reads and writes the same shared state.

Suppose two ticket terminals both try to sell the final seat. If each reads “available” before either records the sale, both may complete a booking. A mutual-exclusion lock lets one terminal enter, check and update the state, then release access. The other waits and makes its decision from the changed state. The whole ticketing service has not been reduced to one customer at a time; only the update to that final seat has been serialised.

Mutual exclusion is related to a race condition but is not the same thing. A race condition is the risk that a result depends on accidental execution order; mutual exclusion is one way to restrict access to shared state. It also carries a cost: an oversized protected region turns work that could run concurrently into a queue. The central point is that mutual exclusion does not reject concurrency. It exchanges limited waiting for coherent state precisely where simultaneous modification is unsafe.

https://pkg.go.dev/sync