Race Conditions and Mutual Exclusion

Use this teaching model: an increment has separate read, change and write steps. Threads can take turns between those steps. The increment is not atomic in this model. Actual languages also offer atomic operations, and their rules for unsynchronized access differ; this trace is not a promise about every language.

A critical section accesses shared data that needs mutual exclusion. A thread can be paused while inside it; holding a lock does not stop context switches. Instead, another thread using the same lock cannot enter the protected operation until the lock is released. Unrelated work can still run.

For the balance update, acquire one shared lock before reading. Read, calculate and store while holding it, then release it. Every conflicting balance update must follow that same rule. Locking only the store is too late: both threads could already have read the same old balance.

For check-then-act, hold the same lock across the check and the action that depends on it. Every participant that can change the checked state must coordinate with that lock. The next thread then checks the updated state, rather than using a result from before another thread's action.

Choose a protected region that covers the full shared-data requirement. Keep unrelated printing or slow work outside when it does not need the lock. Longer lock holding can make contenders wait longer. A smaller region is useful only if it still protects the required relationship; cutting out the read can reintroduce the race.