OS Scheduler¶

Thread states¶

waiting. For example, waiting for disk, network, the os system calls or synchronization calls (atomic, mutexes).
runnable. Thread is ready to execute and waits for time on a core.
executing. A core executed the thread's instructions.

CPU-Bound. This work never creates a situation when the thread will be in wait status, because thread constantly calculate something. For example, calculating Pi in the Nth digit.
IO-Bound. This work causes thread to enter into "waiting" status. For example, operations with disk, network, the os system calls or synchronization calls (atomic, mutexes)

the scheduler is unpredictable when it comes to what Threads will be chosen to run at any given time
You must control the synchronization and orchestration of Threads if you need determinism in your application.
A context switch happens when the scheduler pulls an Executing thread off a core and replaces it with a Runnable Thread. The Thread that was pulled can move back into a Runnable state (if it still has the ability to run), or into a Waiting state (if was replaced because of an IO-Bound type of request).
Context switch is expensive operation between ~1000 and ~1500 nanoseconds.
In cases where a program is focused on IO-Bound work, then context switches are going to be an advantage.
In cases where a program is focused on CPU-Bound work, then context switches are going to be a performance nightmare.

Accessing data from main memory: ~100 to ~300 clock cycles
Accessing data from caches: ~3 to ~40 clock cycles cache-coherency problem introduces problems like false sharing and if cache value is dirty increases latency because cores must change the dirty cache value.