Race Conditions, Mutex & Deadlock

Why counter++ isn't atomic, how a mutex prevents data corruption, what creates a deadlock, and how lock ordering breaks the cycle.

Stage 1 — Race Condition1 / 21

Shared Memory

counter (at address 0x4A2F)

Thread 1IDLE

CPU register—

Thread 2IDLE

CPU register—

FastSlow

Two threads each increment a shared counter 1 000 times — expected final value: 2 000. The increment operation is NOT atomic: it compiles to three CPU instructions: READ the value into a register → ADD 1 → WRITE back. Any context switch between these three steps corrupts the result.

Progress

Race Condition

Mutex Lock

Deadlock

Prevention

Coffman Conditions (all 4 needed for deadlock)

Mutual exclusion

Only one thread per resource

Hold and wait

Holds one lock, waits for another

No preemption

Locks can't be forcibly taken

Circular wait

T1 waits for T2, T2 waits for T1

Active Recall Quiz

Q1 of 3

Two threads each run counter++ 1 000 times. Without synchronization, what is the most likely final value?

Under the Hood

Loading visualizer…

DNSresolving host

TCPconnecting

TLShandshake

HTTPrequesting

DSAverse

Race Conditions, Mutex & Deadlock

Race Conditions, Mutex & Deadlock