Concurrency And Race-Condition Mental Models
Concurrent work overlaps in time; a race occurs when correctness depends on an uncontrolled ordering.
Why This Matters
PHP requests, browser events, workers, databases, caches, and external APIs all create independently scheduled steps.
Working Model
Concurrent work overlaps in time; a race occurs when correctness depends on an uncontrolled ordering. Correctness comes from preserving an explicit invariant across every permitted ordering, not from expecting one observed timing.
Practical Rules
- Write the shared invariant.
- List reads, decisions, writes, and side effects.
- Assume operations can interleave unless one boundary guarantees otherwise.
- Distinguish atomicity from speed.
- Prefer designs that remain correct under every allowed order.
Failure Modes
- Testing only one sequential path.
- Calling asynchronous work parallel without checking dependencies.
- Using a delay as synchronization.
- Protecting code but not the shared resource.
Verification
- Draw two-operation timelines.
- Force alternate orderings.
- Repeat tests under contention.
- Observe final state and duplicate side effects.
What You Should Be Able To Do
After this lesson, you should be able to explain interleavings, shared invariants, atomic operations, and the difference between concurrency and parallel execution, choose a suitable approach for a real PHP project, and verify the result instead of relying on assumptions.
Practice
Practice: Map An Interleaving
Two requests read stock 1 and both try to buy it. Draw the unsafe order.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
Both reads can observe 1 before either write. Each then writes 0 and both report success. Replace the read-then-write decision with a conditional atomic update or lock.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.
Practice: Separate Concurrency From Parallelism
Explain overlapping requests on one CPU and multiple workers.
Your answer must:
- state the intended outcome;
- show the commands, data flow, or implementation shape;
- identify at least one unsafe alternative;
- explain how the result will be verified.
Show solution
One CPU can interleave concurrent work without simultaneous execution; multiple cores may execute in parallel. The race concern is overlapping access and ordering, not the processor count.
The important part is not memorising one command or vendor screen. The solution makes the invariant, failure behavior, and verification evidence explicit.