---
title: "Race Conditions and Mutual Exclusion"
description: "Conflicting shared-data accesses can produce results that depend on their order. A non-atomic read-change-write sequence can lose an update. Mutual exclusion uses a shared lock to protect the required"
canonical: https://lightmysky.com/learn/computing/race-conditions-and-mutual-exclusion-mt_hygT74jJDE
source: https://lightmysky.com/learn/computing/race-conditions-and-mutual-exclusion-mt_hygT74jJDE.md
retrieved: 2026-11-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Race Conditions and Mutual Exclusion

Conflicting shared-data accesses can produce results that depend on their order. A non-atomic read-change-write sequence can lose an update. Mutual exclusion uses a shared lock to protect the required region; threads contending for that lock may have to wait.

Subject: Computing · Area: Computer Systems · Ages 20 to 22
Page: https://lightmysky.com/learn/computing/race-conditions-and-mutual-exclusion-mt_hygT74jJDE

## Ready when they can

- Interleave two increment sequences to produce a lost update
- Place a lock around the smallest region that fixes the race
- Explain why a check followed by an action can be wrong even when both are correct

## Lesson: Locking the lines that must not mix

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.

**Example.** A shared balance starts at 10. Two threads each add 5. Both read 10, each calculates 15 locally, then each stores 15. The final balance is 15 instead of 20. One update is lost because the later store replaces the earlier result using the same old value.

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.

*(drawing: A check can become stale before its action. Two successful checks do not mean two items exist.)*

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.

**Recap.** Use one shared lock for conflicting operations. Protect the full read-change-write or check-and-act region; unrelated work can continue outside it.

*Original lesson, questions and study cards on race conditions and mutual exclusion, written for this topic.*

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Threads and Shared Memory](https://lightmysky.com/learn/computing/threads-and-shared-memory-mt_N4EGNbN6Xh)

## Optional connections

- [Instruction Set Architecture as a Contract](https://lightmysky.com/learn/computing/instruction-set-architecture-as-a-contract-mt_pbwHRePY5M)

## Opens up

- [Code Generation and What an Optimiser May Change](https://lightmysky.com/learn/computing/code-generation-and-what-an-optimiser-may-change-mt__ZSPwP4hfA)
- [Deadlock and the Four Conditions](https://lightmysky.com/learn/computing/deadlock-and-the-four-conditions-mt_CsMOA4sBb1)
- [Clocks, Ordering and Happens-Before](https://lightmysky.com/learn/computing/clocks-ordering-and-happens-before-mt_ratia1eb_2)
- [Isolation Levels and the Anomalies They Allow](https://lightmysky.com/learn/computing/isolation-levels-and-the-anomalies-they-allow-mt_utxPNgxveB)