Modern operating systems support multiple processes and multiple users. Many tasks appear to run “together” because the OS switches the CPU among tasks and overlaps CPU work with I/O work. This is the principle of concurrency: multiple activities make progress during the same time interval.
A race condition occurs when two or more processes access and manipulate shared data concurrently, and the final outcome depends on the strict order of execution (timing/interleaving). Because CPU scheduling and hardware interrupts are unpredictable, the resulting data state can become corrupt.
Statements that look atomic (single-step) in high-level code like C or Java are translated into multiple low-level machine instructions. If a context switch happens in the middle of these steps, the shared data becomes inconsistent.
// Shared memory variable
int count = 5;
// Producer Process
count++;
// Consumer Process
count--;// count++ (Requires 3 steps)
r1 = count;
r1 = r1 + 1;
count = r1;
// count-- (Requires 3 steps)
r2 = count;
r2 = r2 - 1;
count = r2;Core Concept: If correctness depends on "Process A must finish before Process B starts" across concurrent systems, you must apply synchronization to control their interleaving.
In concurrent programming, a critical section is the specific segment of code where a process accesses and modifies shared variables, tables, or files. The OS must guarantee that when one process executes inside its critical section, no other process is allowed to execute in theirs.
do {
// Entry Section (Request permission / Lock)
/* --- CRITICAL SECTION --- */
/* Access shared memory */
// Exit Section (Release permission / Unlock)
// Remainder Section (Independent code)
} while (true);| Requirement | Definition | What it Prevents |
|---|---|---|
| Mutual Exclusion | If process P_i is in its critical section, no other process P_j may be in its critical section. | Data corruption / Race conditions. |
| Progress | If no process is in the critical section, processes wishing to enter cannot be postponed indefinitely. | System deadlocks and freezing. |
| Bounded Waiting | There must be a strict limit on how many times other processes can enter their critical sections after a process has requested entry. | Process starvation (waiting forever). |
On old, single-core systems, developers could simply disable hardware interrupts before modifying a shared variable, preventing context switches. However, on modern multiprocessor architectures, globally disabling interrupts across all cores is extremely slow, harms system clock timing, and drastically reduces overall system efficiency. Modern operating systems require software and hardware synchronization tools instead.
TestAndSet or CompareAndSwap).While synchronization solves race conditions, poorly implemented locks introduce a new danger: Deadlock. If Process A locks Resource 1 and waits for Resource 2, while Process B locks Resource 2 and waits for Resource 1, both processes will freeze indefinitely.
Consider the OS maintaining a shared variable next_available_pid.
If two processes request to create children at nearly the exact same time, both may read the same PID before either writes back the incremented value.
This leads to duplicate PID assignment — a catastrophically incorrect state for an OS kernel.
// Shared kernel variable
next_available_pid = 2615;
// Inside the fork() system call:
pid = next_available_pid;
next_available_pid = next_available_pid + 1;
return pid;2615 before the increment step occurs.count++) are multiple steps and can interleave.