---
title: "Race Conditions and Mutual Exclusion"
description: "When two threads read, change and write the same value, the result depends on timing that nobody controls. A critical section is the stretch that must not be interleaved, and a lock is the usual way t"
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-09-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

When two threads read, change and write the same value, the result depends on timing that nobody controls. A critical section is the stretch that must not be interleaved, and a lock is the usual way to enforce that, at the cost of everything waiting.

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

Two threads sharing one value can interleave badly. Each increment reads, changes, and writes back. When both read before either writes, one update is lost.

**Example.** A balance of 10 gets plus 5 from two threads. Both read 10, both add 5, both write 15. The expected 20 never appears. The lost update leaves 15.

The critical section is the stretch that must not be interleaved: the read, change, and write together. A lock around exactly those lines fixes the race. Everything outside stays unlocked so waiting stays short.

**Tip.** A check followed by an action can fail even when both look correct. Between your check and your act, another thread can change the value. Lock the check together with the act.

**Recap.** Wrap the read-change-write stretch in a lock, including any check it relies on.

## 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)
- [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)