Introduction to Operating System: Concepts, Types and a Worked System Call

An application appears to read a file, use memory and print output by itself. In reality, the operating system mediates every protected resource involved in that work. The broader OS foundation and an FCFS CPU-and-I/O schedule are developed in Introduction to Operating System: Core Concepts with a Worked CPU Schedule. A 12-byte protected read requires a different trace: exact buffer addresses, trap entry, device blocking, interrupt completion, the Ready state and dispatch.

Related reading: system call MCQs and process state MCQs.

What an Operating System Actually Does

An operating system is privileged software between applications and hardware. It exposes abstractions, allocates CPU time, memory, storage and devices, and controls unsafe operations.

Its three views fit together. As an interface, the OS offers usable operations. As a resource manager, it decides who receives a resource and when. As a control program, it checks permissions and prevents unsafe access. Its practical goals are convenience, efficient sharing, reliability and isolation. An application can request 12 bytes from a file descriptor, but it cannot command the storage controller or modify another process's memory.

The kernel is the OS's privileged core. A shell accepts commands, a utility handles maintenance, and an application solves a user problem. Firmware controls hardware below the OS. These roles are not synonyms.

Resources, Abstractions and OS Services

The OS turns hardware resources into abstractions that programs can use safely.

Around them, an OS provides program execution, I/O, file management, inter-process communication, error detection, resource allocation, accounting and protection. An abstraction hides details without making its resource unlimited. A file simplifies persistent access, but storage capacity and permissions still apply.

APIs and implementations differ. The shared pattern is separation: applications request services through controlled interfaces instead of manipulating protected hardware state.

User Mode, Kernel Mode and the System-Call Boundary

An API call uses a programmer-facing interface. A library may handle it or eventually request a system call. An ordinary function call transfers control without granting extra privilege. A system call uses protected entry so the kernel can perform work that user code cannot.

Assume a simplified teaching machine. Its mode values and calling convention are not claims about any processor's real ABI.

Process P1 is in user mode, represented by mode=1, at PC=0x00400120. It has open file descriptor fd=3 and a writable buffer starting at 0x7FFF1000. The file's next 12 ASCII bytes are OS-HELLO-123. P1 requests:

read(3, 0x7FFF1000, 12)

At t=0.000 ms, a protected trap saves return address 0x00400124, changes to kernel mode (mode=0) and transfers control to the system-call handler. The kernel validates descriptor 3 and checks that the destination is writable. For 12 bytes, the inclusive final address is:

0x7FFF1000 + 12 - 1 = 0x7FFF1000 + 0xB = 0x7FFF100B

Assume the data is not cached. P1 becomes Blocked while the device request runs, and P2 starts at t=0.080 ms. At t=2.400 ms, a device-completion interrupt makes P1 Ready. The scheduler dispatches P1 at t=3.000 ms. The kernel copies all 12 bytes, sets return value 12, restores mode=1 and resumes P1 at PC=0x00400124. These illustrative times are not universal OS latency figures.

Interrupts, Exceptions, Traps and Process-State Effects

An external interrupt comes from outside the current instruction stream, such as device completion. A synchronous exception comes from the current instruction, such as an invalid operation. An intentional trap enters a protected service handler. Terminology varies by architecture, so classify events first by source and timing.

The simplified trace has four privilege-boundary transitions: P1 user to kernel on the trap, kernel to P2 user after P1 blocks, P2 user to kernel on the interrupt, and kernel to P1 user when P1 is dispatched. It switches from P1 to P2 and later back. A mode switch alone need not change the process.

P1 follows Running -> Blocked -> Ready -> Running: it blocks at t=0.000 ms, becomes Ready at t=2.400 ms, and runs at t=3.000 ms. The scheduler, not the interrupt alone, selects it.

OS Structures and Types: Choose by Mechanism and Workload

A monolithic structure keeps many services in the kernel, shortening call paths but adding privileged code. A layered structure separates responsibilities by level. A microkernel keeps a smaller core and often uses messages with external services. Modular or hybrid designs combine mechanisms. Call cost, fault isolation and maintainability depend on implementation, so no structure is universally fastest or safest.

OS type labels describe workload constraints and can overlap. Batch systems process queues. Multiprogrammed systems keep work available for the CPU. Time-sharing systems support responsive sharing. Real-time systems focus on deadlines. Distributed or network systems coordinate machines. Embedded and mobile systems serve constrained devices and specialised interaction.

Multiprogramming keeps programs ready to use one CPU efficiently; multiprocessing requires more than one processing unit. A control task due within 5 ms is hard real-time only if missing that deadline means system failure. A media task targeting one frame every 16.7 ms may be soft real-time when an occasional late frame only reduces quality.

Common Traps That Break Otherwise Good Answers

• OS versus kernel: The kernel is central, but only it is the privileged core. Test the scope.

• Program versus process: Both involve code; only a process is an executing instance with state.

• User mode versus user interface: “User” misleads; one is privilege, the other interaction.

• Multiprogramming versus multiprocessing: Both involve multiple programs; only the latter requires multiple units.

• Mode switch versus context switch: Both change state; only the latter selects another process or thread.

An interrupt need not cause a context switch. The kernel may return to the same process. In this trace, the process changes only when P2 and later P1 are selected. Test the scope by naming the active process before and after each privilege change.

How GATE-Style Questions and Interviews Test the Foundation

Objective questions ask you to identify privileged work, classify events, follow process states, compare structures, or test whether a mode change changes the process. Interviewers often vary the same trace: what changes if the bytes are cached, can P1 stay Running during device wait, and does every mode switch select another process? Trace the mechanism, not keywords.

The address range, process-state sequence and interrupt source follow directly from the stated trace. First, 12 bytes from 0x7FFF1000 end at 0x7FFF100B because the final offset is 12 - 1 = 11 = 0xB. Second, P1 cannot move directly from Blocked to Running here. Completion makes it Ready at t=2.400 ms; dispatch makes it Running at t=3.000 ms. Third, device completion is external to P2's instruction stream, so it is an external interrupt.

Use GATE CS Exam Preparation for the wider syllabus. After you can explain why P1 becomes Ready before Running, continue with CPU Scheduling: FCFS, SJF and Round Robin with Gantt Charts; that lesson develops scheduling-policy comparisons and Gantt-chart arithmetic rather than repeating the system-call path.

The Short Version and What to Study Next

The operating system manages and protects resources.

Abstractions make hardware usable.

The kernel is the privileged core.

System calls cross a protected boundary.

Events can change mode without necessarily changing process.

For a broad semester-to-core-CS path, use Zero to Hero. For interview-focused core CS revision, choose Computer Science Interview Preparation. Next, study process management and CPU scheduling after you can reproduce the 12-byte trace unaided.