Sharing without locks
Most concurrent code protects shared data with a mutex: a thread acquires it, touches the data, then releases. This is simple but brittle. If the holder is preempted, descheduled, or crashes while inside the lock, every other thread waits. Lock based code can also deadlock when locks are taken in conflicting orders.
Lock free programming avoids these hazards. Instead of mutual exclusion it relies on hardware atomic instructions, especially compare and swap, that let a thread publish a change in one indivisible step.
What lock free guarantees
Lock free does not mean wait free or fast. Its precise meaning is a progress guarantee:
- At least one thread always makes forward progress in a bounded number of steps.
- A thread stalled at any moment can never block all others forever.
So an individual thread may retry many times, but the system as a whole never gets stuck because one participant paused.
The cost
You trade simple reasoning for subtle hazards: the ABA problem, safe memory reclamation, and memory ordering. These are the real reasons lock free code is hard.
Key idea
Lock free programming replaces mutual exclusion with atomic instructions to guarantee that the whole system keeps progressing even when individual threads stall.