25-Comp-A5 Operating Systems · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
(a) Priority inversion. Priority inversion occurs when a lower-priority process holds a resource (typically a lock) that a higher-priority process needs; the high-priority process blocks waiting for the lock, but instead of the low-priority holder finishing quickly, a medium-priority process — uninvolved with the lock at all — preempts the low-priority holder (since it outranks it) and runs freely, indirectly starving the high-priority process for as long as the medium-priority work keeps arriving. Effectively, the high-priority process is blocked by a medium-priority one, "inverting" the intended priority order. Example: the 1997 Mars Pathfinder mission experienced exactly this — a low-priority meteorological data-collection task held a mutex also needed by a high-priority information-bus-management task; a medium-priority communications task kept preempting the low-priority task (which never got to finish and release the mutex), so the high-priority task was denied the bus for long enough that a watchdog timer detected the stall and forced a system reset. The standard fix is priority inheritance: temporarily boost the lock-holder's priority to match the highest-priority process waiting on that same lock, so it can finish and release promptly.
(b) Security vs. protection. Protection is the set of internal mechanisms an operating system uses to control which processes/users may access which resources, according to a stated policy (access-control lists, permission bits, capabilities) — its goal is to ensure legitimate users/processes only touch what they are authorized for, preventing accidental or unauthorized interference among otherwise-trusted parties already inside the system. Security is the broader concern of defending the system as a whole against threats that may originate outside the trusted boundary or from malicious/unauthorized actors — its goal is authentication, defending against intrusion, malware, and breaches, and preserving confidentiality/integrity/availability against adversaries, not just regulating already-trusted internal access.
(c) Disk fragmentation. As files are created and deleted over time under contiguous allocation, the disk's free space breaks into many small, scattered, non-contiguous holes (external fragmentation): even if the total free space is ample, no single hole may be large enough for a new file, forcing it to be split across several extents or fail to allocate at all. Fixed-size block allocation can also waste space within a block when a file's last block is only partially used (internal fragmentation). Controlling technique: periodic compaction/defragmentation — relocate files so free space is consolidated into one (or a few) contiguous region(s); because copying whole files on disk is expensive, this is normally run offline or during idle periods rather than continuously. An alternative that avoids external fragmentation altogether is to use a non-contiguous allocation method (linked or indexed) so files never need to occupy one contiguous run in the first place.
(d) File Allocation Table (FAT). FAT is a variant of linked allocation that moves the "next block" pointers out of the data blocks and into one central table, kept in a reserved disk area and cached in memory, with one entry per disk block. A file's directory entry points to its first block; that block's FAT entry gives the next block's number, and so on until a special end-of-file marker. Because the whole FAT is normally cached in memory, walking a file's chain requires no disk I/O per hop (only the actual data blocks are read) — a clear performance advantage over a classic linked list whose pointers live inside each on-disk block. FAT was the allocation scheme used by MS-DOS and early Windows file systems.
(e) Compile-time vs. load-time address binding. Compile-time binding generates absolute memory addresses directly when the program is compiled, which requires knowing in advance exactly where in memory the program will be loaded; if that location ever changes, the program must be recompiled from scratch. Load-time binding instead has the compiler emit relocatable code (addresses expressed relative to a base of 0), with the actual absolute addresses computed only when the program is loaded into memory; this lets the same compiled binary be loaded at different memory locations on different runs, but once loaded and bound, its addresses are fixed for that entire execution — if the process needs to move while running, it must be reloaded, since load-time binding does nothing further after load.
