mutual exclusion

Mutual exclusion is the simplest of the three critical-section requirements, and the most important: at most one thread may be inside the critical section for a given piece of shared data at any moment. It is 'mutual' because the threads exclude one another — if I am in, you are kept out, and vice versa. The single-occupancy bathroom is the perfect picture: the lock guarantees that whoever is inside has it entirely to themselves, and everyone else waits their turn.

Mutual exclusion is the property that directly defeats race conditions. Recall that a race happens because two threads' multi-step operations on shared data interleave. If mutual exclusion holds over the critical section that does those steps, the steps cannot interleave: thread A finishes its read-add-write completely before thread B is allowed to begin, so no update is lost. In effect, mutual exclusion turns a non-atomic region into an effectively atomic one. The mechanisms that provide it range from clever pure-software protocols (Peterson's solution) up through hardware atomic instructions, mutex locks, and semaphores; they differ in cost and convenience but all promise the same one-at-a-time guarantee.

Two honest cautions. First, mutual exclusion is a safety property, not a liveness one: by itself it says nothing about whether waiting threads ever get in, so a mutually exclusive scheme can still deadlock or starve someone — that is why progress and bounded waiting are separate requirements. Second, mutual exclusion is not free and is not always desirable. While one thread holds it, all others that need the resource are blocked, which serializes that part of the program and limits how much parallel speedup you can get; this is why good designs keep critical sections short and protect only what truly must be exclusive. Sometimes a read-only workload needs no exclusion at all, or can use a weaker scheme that allows many readers but one writer.