Common OS Pitfalls

Certain OS misconceptions come up again and again, in exams, interviews, and real debugging sessions. They usually arise from a plausible-sounding simplification that breaks down under closer scrutiny. This lesson walks through the most common pitfalls — what students typically get wrong, why the wrong version is tempting, and the precise correction — so you can recognize and avoid them.

This is close but students often conflate it with 'the scheduler decides who runs next' in general, forgetting the timing dimension. The precise distinction is about whether the OS can interrupt a running process before it blocks or finishes. Non-preemptive scheduling (like plain FCFS or non-preemptive SJF) never takes the CPU away mid-execution; preemptive scheduling (like Round Robin or preemptive Priority) can interrupt at any time, e.g., on timer-quantum expiry or arrival of a higher-priority job. Mixing these up leads to wrong turnaround/waiting-time calculations on scheduling problems, since preemption changes when a process actually finishes.

This is a common and understandable simplification, but it is wrong in an important way: ownership. A binary semaphore has no concept of who acquired it — any thread can call 'signal' on it, even one that never called 'wait'. A mutex is explicitly owned by the thread that locked it, and typically only that thread is allowed to unlock it; violating this is a programming error many mutex implementations detect and reject. This matters for correctness: using a semaphore for mutual exclusion can hide bugs where the wrong thread accidentally releases the lock.

A common mistake is assuming deadlock can occur even if one condition is clearly false, or conversely assuming you must eliminate all four conditions to prevent deadlock. Neither is right. All four conditions — mutual exclusion, hold-and-wait, no preemption, and circular wait — must hold simultaneously for deadlock to occur, so preventing deadlock only requires breaking any single one of them (for example, requiring processes to request all resources at once eliminates hold-and-wait). Students often lose exam marks by listing only two or three conditions, or by claiming deadlock prevention requires attacking every condition.

Both are called 'fragmentation' and students frequently swap them. Internal fragmentation is wasted space inside an allocated block — for example, unused bytes in the last page of a process because pages are fixed-size and the process doesn't need the whole last page. External fragmentation is wasted space between allocated blocks — free memory exists in total but is scattered in pieces too small individually to satisfy a request, which happens with variable-size allocation schemes like segmentation or contiguous allocation with variable partitions. Paging suffers from internal fragmentation but not external; segmentation is the reverse.

This is one of the most persistent misconceptions. Virtual memory is an addressing abstraction: it gives each process the illusion of a large, contiguous, private address space, decoupled from the actual physical memory layout, and it enables demand paging so only needed pages are resident. It can extend the amount of addressable data beyond physical RAM by using disk as backing store for pages not currently in use, but this comes at a steep performance cost (disk is orders of magnitude slower than RAM), and it does not increase the physical RAM available — excessive reliance on it causes thrashing rather than 'more memory'.

Students sometimes treat spinlocks and blocking semaphores as interchangeable synchronization tools. A spinlock makes the waiting thread continuously poll a condition in a tight loop, consuming CPU cycles the whole time it waits — acceptable only for very short critical sections, especially on multiprocessor systems. A semaphore (in its typical OS implementation) puts the waiting thread on a wait queue and blocks it, so the CPU is freed for other work while it waits, which is far more efficient for longer or unpredictable wait times.

Only under strict priority scheduling with no other constraints, and even then, priority inversion can violate this expectation: a low-priority process holding a lock needed by a high-priority process can effectively block it, while a medium-priority process that needs no shared resource keeps running. Students often forget this scenario exists, assuming priority alone fully determines execution order. Solutions like priority inheritance exist specifically to address this pitfall.

FCFS treats jobs fairly in arrival order but is notorious for the 'convoy effect,' where a long job at the front makes many short jobs behind it wait excessively, hurting average waiting time. SJF minimizes average waiting time provably, but it can starve long jobs indefinitely if short jobs keep arriving, and it requires knowing (or estimating) burst time in advance, which is not always realistic. Assuming either algorithm is universally 'fair' overlooks these specific failure modes.