Operating Systems (BCA 251): A Study Guide
Operating Systems is the course where hardware and software finally meet. This guide covers the ideas worth mastering and the habits that make them stick.
Operating Systems (BCA 251) is a three-credit course in the fourth semester of BCA, with three lecture hours and three practical hours a week. It arrives after Data Structure and Algorithms and before Computer Network, and it asks a single question in many forms: how does one machine share one processor, one memory and one disk between many programs at once? If you plan the term around it, the fourth semester guide shows where it sits next to Software Engineering, Numerical Methods and Project-I.
The subject rewards understanding far more than memorisation. Most exam questions ask you to trace a mechanism: how a process moves between states, how a page fault is serviced, why a deadlock cannot occur under a particular scheme. Narrate those steps in plain sentences and the definitions fall into place around them.
How to think about an operating system
An operating system is a resource manager and an abstraction layer at the same time. As a manager it decides which process gets the processor, which page stays in memory and which blocks are written to disk. As an abstraction it hides that machinery behind system calls, so a program can ask to open a file rather than address a disk sector directly.
Keep a two-column note for every mechanism: what problem it solves, and what it costs. Round-robin scheduling solves starvation and costs context switches; caching solves slow disk reads and costs memory. That habit turns a list of topics into a set of trade-offs, which is what examiners ask about.
Processes and threads
A process is a program in execution with its own address space. It passes through a small set of states: new, ready, running, waiting and terminated. The ready queue holds processes that could run but do not have the processor; a waiting queue holds those blocked on an event such as a disk read. A context switch saves the state of the running process and restores another, and from the point of view of useful work it is pure overhead.
A thread is a unit of execution inside a process. Threads in the same process share code, data and open files, but each keeps its own program counter, registers and stack. Sharing makes communication cheap and races likely, which is why synchronisation belongs with this topic.
CPU scheduling
A scheduler chooses which ready process runs next. The metrics that matter are processor utilisation, throughput, turnaround time, waiting time and response time, and no policy improves all of them at once. Short jobs do well under shortest-job-first, interactive users do well under round-robin, and long jobs can starve if priorities are mishandled.
- First come, first served: simple, but one long job holds up everything behind it.
- Shortest job first: gives the lowest average waiting time when job lengths are known in advance, which they rarely are.
- Round robin: every process receives a fixed time slice, and a very small slice improves response time while raising switching overhead.
- Priority scheduling: important work runs first, and ageing is the usual cure for starvation.
- Multilevel feedback queues: several queues with different slice sizes, so interactive and batch jobs can coexist.
Synchronisation and deadlock
Mutual exclusion means only one process at a time executes in a critical section. A correct solution also needs progress, bounded waiting and no assumption about the relative speed of processes. The classical tools are hardware instructions such as test-and-set and compare-and-swap, with semaphores, mutex locks and monitors built above them. The standard problems, including producer and consumer, readers and writers, and the dining philosophers, are worth working through by hand, because they reappear in questions under different names.
Deadlock requires four conditions at once: mutual exclusion, hold and wait, no preemption, and circular wait. Break any one of them and deadlock cannot occur. Detection builds a resource allocation graph and looks for a cycle, while avoidance keeps the system in a safe state, which is what the Banker algorithm tests. Most real systems prevent the circular wait by ordering resources.
Memory management and paging
Early systems kept a whole process in one contiguous block, so fragmentation was the central problem, internal when the block was too large and external when free gaps were too small. Paging divides logical memory into fixed-size pages and physical memory into frames, with a page table mapping one to the other. That removes external fragmentation, and a small translation lookaside buffer keeps the average lookup fast.
Virtual memory allows a program to run when only part of it is resident. A reference to a page that is not in memory causes a page fault, which the system traps, services from disk and then resumes. The replacement policy decides what leaves. Least recently used is the usual benchmark, while first in, first out is the usual demonstration of failure, because with some reference strings adding frames increases the number of faults.
| Concept | The question it answers | Typical exercise |
|---|---|---|
| Paging | How is a logical address translated into a physical one? | Split an address into page number and offset, then read the page table. |
| Page fault | What happens when the required page is not resident? | Describe the trap, service and resume sequence in the right order. |
| Replacement | Which page leaves when memory is full? | Run one reference string through FIFO and LRU and count the faults. |
| Segmentation | How is a program split by meaning rather than by size? | Compare segment tables with page tables and note the fragmentation. |
File systems
A file system gives files names, a place in a directory tree and a mapping onto disk blocks. Allocation can be contiguous, linked or indexed, and that choice decides how cheaply a file grows and how costly a random read becomes. Metadata lives in a structure such as an inode: owner, size, permissions, timestamps and block pointers.
- Directory structures, from a single level to a tree or a graph with links.
- Allocation methods and the fragmentation and seek behaviour each one causes.
- Free space management with bitmaps or linked lists, and permissions as access control.
How to prepare
Work in three passes: read a topic and summarise it from memory, then do the numerical exercises for it, then explain it aloud for five minutes without notes. The gaps you hear are the gaps you need to revise.
Lab work carries real weight here, and each practical needs a written record, so keep it current rather than leaving a backlog for the end of term. Departments also sequence topics to suit their own staff and labs, so confirm the order and the practical list with your teacher rather than assuming another campus does it the same way.
Is Operating Systems a hard BCA subject?
It is demanding rather than abstract. Once you can trace a context switch or a page fault step by step, most questions become manageable.
Do I need to memorise code for the exam?
No. You need to describe mechanisms, run small numerical examples and compare policies. Short pseudocode helps, but the reasoning carries most of the marks.
How much mathematics is involved?
Little beyond arithmetic. You compute averages, run reference strings through replacement policies and fill resource tables, all of which become quick with a few practised examples.
Should I use the textbook or my class notes?
Your notes tell you what will be examined; a standard textbook explains anything unclear. Read the chapter first, then your notes.