What is a mutex and how does it stop a race condition?

beginner

← All Concurrency & Multithreading questions

Re-explain

A mutex, short for mutual exclusion lock, is a gate that only one thread can hold at a time. A thread locks it before touching shared data and unlocks it when done. Others must wait.

By forcing threads to take turns, a mutex serializes access to a critical section. That is how it stops a race condition. No two threads read, modify, and write the same value at once, so the lost-update problem vanishes.

mutex.lock();
counter = counter + 1; // no other thread runs this line now
mutex.unlock();

A mutex trades some throughput for correctness. While one thread holds it, the others block and do nothing. Lock only the shared state, and always release the mutex, even when errors happen.

Rewriting in plainer words…

This answer doesn't lend itself to a diagram - it reads best . No credits were charged.

Why there's no diagram: “”

The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓

The diagram below the answer is the concept . Jump to it ↓

Tailored explanation · switch back to · ·

What should the new diagram focus on?

Guided practice for Concurrency & Multithreading One question at a time. Answer out loud, get graded, see what you missed.

How well did you know this?

AI:

Saved in this browser - sign in to keep your review list.

How should your speech become text?

Listening… your words appear above as you speak - tap Stop when you're done.

Recording · cr - tap Stop & transcribe when you're done.

Transcribing with AI…

Voice:

Keep going - a few more words and AI can grade it.

Interview lens How interviewers actually use this question

Likely follow-ups

What happens if the code throws an error after lock() but before unlock()? The mutex stays held, and every thread that waits for it blocks forever. Release it in a finally block or use a scoped lock that unlocks on exit.
Why should the code inside the lock be as short as possible? Every other thread waits while the lock is held. Do slow work like I/O outside the lock and lock only the lines that touch shared state.
For a single counter, why not use an atomic increment instead of a mutex? An atomic is enough for one read-modify-write on one value. A mutex is needed when several values or steps must change together.
How is a mutex different from a semaphore? A mutex has an owner and lets one thread in. A semaphore counts permits, lets up to N threads in, and any thread can signal it.
Two threads each hold one mutex and wait for the other's. What happens, and how do you avoid it? That is a deadlock. A strong answer fixes it by always taking locks in the same order, or by using a try-lock with a timeout and backing off.

What you can say

A mutex is a lock that only one thread can hold at a time, and it keeps two threads from changing shared data at once.
A thread locks it before it touches the shared data and unlocks it when it's done. Any other thread that tries to lock it in the meantime has to wait.
A race happens when two threads read, modify and write the same value at the same time, and one update overwrites the other.
With the mutex around that read-modify-write, the critical section runs one thread at a time, so a counter increment can't get lost.
You have to release it even on an error path, or every thread that wants it waits forever.
The cost is throughput, because blocked threads sit idle. So I'd lock only the shared state and keep the locked region small.

Weak answers to avoid

Defines the lock but never names the race Saying 'it locks the data' doesn't explain how. Walk through the read-modify-write interleaving that loses an update, then show how the mutex makes threads take turns.
Forgets to release on error paths An exception between lock and unlock leaves the mutex held, and every other thread stalls. Mention try/finally or a scoped lock that releases on exit.
Locks far more than the shared state Putting I/O or whole functions inside the lock makes threads queue for nothing. Say you'd lock only the lines that touch shared data.
Never mentions what the lock costs Blocked threads do no work, so a mutex costs throughput. Name that trade-off, and say when an atomic would be enough instead.

Interview lens

Likely follow-ups, what you can say, and the weak answers to avoid.

Want a quick review of the fundamentals? See the Concurrency & Multithreading cheatsheet.

← Back to all Concurrency & Multithreading questions

Pro · $10/mo

47 of 54 Concurrency & Multithreading answers are in Pro.

Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.

Full answers + code
AI explanations, simpler or deeper
1,000 AI credits / month
Cancel anytime

Get Pro → See plans & pricing →