Divide and Suffer
In Chapter 30, we met the Landlord (OS) who steals our time.
But usually, we are not the only tenant. There are thousands of threads—Browser tabs, Electron apps, Database workers—all screaming for the CPU.
The OS must stifle this screaming. It uses a Scheduler.
The Illusion of Simultaneity
If you have 1 Core and 4 Threads, you are not running 4 things at once.
Threads do not run in parallel. Cores run in parallel. Threads compete.
You are running 1 thing, then pausing it, then running the next thing...
This is Time Slicing. It creates the illusion of parallelism. But the math is brutal.
If 4 threads want the CPU, each thread gets (at most) 25% of reality. Plus, you pay the tax of switching between them.
1. Play: Watch the Core (Circle) rotate between threads.
2. Observe: Look at how slowly the progress bars move. While Thread A runs, B, C, and D are frozen.
3. Switching: Notice the "Red" flash. That is wasted time.
Priority Inversions
What if Thread A holds a lock that Thread B needs?
If the Scheduler pauses A to let C run, B is stuck waiting for A, which is waiting for the Scheduler.
The system deadlocks not because of logic, but because of scheduling luck.
Why is Node.js (Single Threaded) often faster?
Because it avoids the fight. By staying on one thread, it never context switches (for logic). It keeps the cache warm. It processes events sequentially, which matches the physics of a single core.
Does `sleep(1ms)` actually sleep for 1ms?
No. It creates a "soft timer." When 1ms is up, the OS puts your thread back in the Run Queue. But if 100 other threads are ahead of you, you might wait 10ms or 100ms before you actually run. Sleep is a request, not a guarantee.
We are slicing Time.
The Scheduler manages the "When". It ensures everyone gets a turn.
But programs also need "Where". They need memory. And just like CPU time, memory is a finite resource that must be lied about.
It is time to fracture Space.