How to practise operating systems viva questions
Operating systems viva questions are rarely difficult because of one missing definition. They are difficult because the examiner can move from a definition to an implementation detail, then ask you to justify a design choice.
A useful answer therefore needs three layers:
- Definition — state what the mechanism is.
- Mechanism — explain what happens, in the right order.
- Consequence — identify the benefit, cost, limitation or failure case.
For example, do not stop at “a page fault occurs when a page is not in memory”. Continue with the trap to the operating system, the page-table check, frame selection, possible eviction, disk read, page-table update and instruction restart. Then mention that the operation is expensive because storage access is much slower than RAM access.
Use the same structure when answering questions about processes, threads, scheduling, synchronisation, virtual memory, file systems and deadlocks. If the question asks you to compare two mechanisms, name the comparison criteria before giving the comparison. Typical criteria include isolation, address space, switching cost, communication, failure impact and suitability for a particular workload.
Do not present these as facts about a particular university or professional examination. Course vivas vary in length, permitted material and marking approach, so check your unit handbook or official assessment page for the local format. The method below is designed to make your spoken answers precise when the question and follow-up questions are not known in advance.
Build an oral revision board
Start with your own lecture notes, textbook diagrams and programming exercises. Divide the material into sections that can produce a question and a follow-up. “Processes” is more useful than a board section called “Week 4”, because it tells you what you need to retrieve under pressure.
For each section, record:
- the definition an examiner expects;
- one sequence or diagram that you can explain without looking at it;
- one numerical or concrete example;
- one trade-off or limitation;
- one common confusion;
- one question that would force you to apply the idea.
A board should not become a second textbook. Keep the detail that supports an answer, and link out to longer notes only when you need to check an implementation detail. The following example shows the level of specificity to aim for.
In MySummaries, a revision board for an operating systems viva can collect definitions, mechanisms and follow-up points in one place:
- Process — a protected execution environment with its own virtual address space and resources
- Thread — an execution path within a process; threads share code, data and open files
- A context switch saves registers and program counter, then restores another runnable context
- The PCB commonly stores state, PID, program counter, registers and scheduling information
A user programme requests kernel service through a controlled system-call interface. The transition changes privilege level; the kernel validates arguments and performs the operation before returning a result.
- A page fault is a trap caused when a referenced virtual page is not resident in a valid frame
- Page-table entry may contain a present bit, frame number, protection bits and dirty bit
- FIFO can show Belady's anomaly; LRU uses recent access history but needs implementation support
| Policy | Strength | Risk |
|---|---|---|
| FCFS | Simple; no starvation from queue order | Convoy effect |
| Round-robin | Responsive sharing with a time quantum | Too-small quantum increases overhead |
| Priority | Can favour urgent work | Starvation without ageing |
- Mutual exclusion, hold and wait, no pre-emption and circular wait are all required
- Banker's algorithm avoids unsafe allocations when maximum claims are known
- A wait-for graph cycle proves deadlock for single-instance resource types
The board is useful only if it becomes spoken retrieval. Read a heading, look away, and explain the process in sequence. Then ask yourself what would change if one assumption changed: a single-core system instead of a multicore system, a shared resource instead of private memory, or a workload with many short jobs instead of one long job.
Set up the examiner and stations
A good oral practice session should not be a sequence of isolated flashcards. It should contain an opening question, interruptions, requests for clarification and a final comparison or application. Give each station a narrow topic, a clear opening question and a target speaking time. The target is not a claim about the format of your assessment; it is a practical constraint that stops you giving an unfocused lecture.
The examiner should listen for four things: correctness and precision, ordered reasoning, explicit trade-offs, and clear communication. These are useful practice criteria even where your course uses a different rubric. A technically correct answer can still be weak if it skips the mechanism or hides an incorrect assumption.
The station list below gives a starting set for an operating systems viva.
Use four or five stations in a session, but sit only one or two when you are learning a new topic. Record yourself. On review, mark the exact point where you changed from a precise claim to a vague one. “It gets handled by the kernel” is not enough: name the event, the kernel data structure or the decision being made.
Station 1: process and thread comparison
This question tests whether you can separate protection from execution. Start with the address space and resource boundary, then describe what threads share. Avoid saying that a thread has no state: it has its own program counter, registers and stack, while sharing selected process resources.
Examiner
Compare a process and a thread, then explain what happens when a thread blocks on input.
You correctly identified separate process address spaces and shared resources between threads.
ImproveState explicitly that each thread has its own stack, registers and program counter.
You explained that another thread can run when one blocks, but did not distinguish single-core from multicore execution.
ImproveSay that on a single core another runnable thread is scheduled; on multiple cores it may run concurrently on another core.
You mentioned cheaper thread switching and weaker isolation, but did not connect shared memory to synchronisation risk.
ImproveAdd that shared data enables communication but introduces races and the need for locks or other synchronisation.
The answer was understandable and direct, but the blocking case needed a more exact sequence.
ImproveDescribe the blocking thread leaving the runnable queue and the scheduler selecting another runnable thread.
A strong answerA process is a protected execution environment with its own virtual address space and operating-system resources, whereas a thread is an execution path within that process. Threads in one process share code, data and usually open files, but each has its own stack, registers and program counter. If one thread blocks for input, the operating system marks that thread blocked and can schedule another runnable thread; on a multicore system, another thread may run on a different core at the same time. Threads are cheaper to create and communicate through shared memory, but that sharing creates race conditions and reduces fault isolation compared with separate processes.
After this station, practise the likely follow-ups: “Can a process have one thread?”, “What does a context switch save?”, and “Why might a server use processes rather than threads?” Keep the answer conditional. A process can contain one or many threads; the exact cost of switching depends on the operating system and hardware; separate processes provide stronger isolation but make communication more expensive than shared memory.
Station 2: explain a page fault
This is one of the most useful operating systems viva questions because it tests a complete control path. Do not describe a page fault as a normal disk read. It begins while an instruction is executing and becomes a trap because the translation or protection check cannot complete normally.
Examiner
Walk me through a page fault from the executing instruction to its restart. What can make the fault especially expensive?
You correctly described the missing page, frame allocation, disk read, page-table update and instruction restart.
ImproveMention that a protection violation is not the same as a valid not-present page and may terminate the programme.
The sequence was clear from trap through service routine to resumption.
ImproveIdentify the present or valid bit check before discussing frame selection.
You explained the storage latency and possible dirty-page write-back, but did not mention replacement policy.
ImproveAdd that if no free frame exists, the operating system selects a victim and writes it back if dirty.
You answered the cost question with a concrete contrast between memory and storage access.
ImproveSeparate a minor fault, where data is already available in memory, from a major fault requiring storage I/O if your course uses that terminology.
A strong answerThe processor references a virtual address and the memory-management hardware checks its page-table entry. If the page is not present but the reference is valid, the hardware raises a page-fault trap to the kernel. The kernel checks the access, finds a free frame or chooses a victim page, writes the victim back if it is dirty, reads the required page into the frame and updates the page-table entry. It then restores the process state and restarts the faulting instruction. The fault is especially expensive when storage I/O is required, and a protection violation must be treated as an error rather than serviced as an ordinary page fault.
A strong follow-up answer distinguishes demand paging from replacement. Demand paging explains why the page is brought in when referenced; replacement explains what happens when there is no free frame. It also helps to name the evidence in a page-table entry: a present or valid bit, a frame number and protection information, with a dirty bit often used to decide whether eviction requires a write.
Station 3: diagnose deadlock
Deadlock questions reward exact conditions. Do not list “contention, waiting and no progress” as if they were the formal test. State the four necessary conditions and then explain what a graph or prevention policy does with them.
Examiner
State the four necessary conditions for deadlock and explain how a wait-for graph can reveal one for single-instance resources.
You named mutual exclusion, hold and wait, no pre-emption and circular wait, but called a cycle sufficient for every resource model.
ImproveQualify the graph result: for single-instance resource types, a cycle in the wait-for graph indicates deadlock.
You listed the conditions but did not explain how process edges are constructed.
ImproveDescribe an edge from process P to process Q when P waits for a resource held by Q.
You mentioned prevention but did not compare prevention, avoidance and detection with recovery.
ImproveGive one cost: prevention can reduce concurrency, avoidance needs maximum claims, while detection permits deadlock before recovery.
The response was concise, but the qualification about multiple resource instances was missing.
ImproveSay that a cycle is necessary but not always sufficient when resource types have multiple instances.
A strong answerDeadlock requires mutual exclusion, hold and wait, no pre-emption and circular wait to hold at the same time. For single-instance resource types, a wait-for graph has one node per process and an edge from P to Q when P is waiting for a resource currently held by Q. A cycle in that graph indicates that the processes are waiting on one another and are deadlocked. With multiple instances of a resource type, a cycle alone is not always sufficient, so the resource-allocation model must be considered. Systems can prevent a condition, avoid unsafe allocations when maximum claims are known, or detect deadlock and recover afterwards; each choice affects concurrency, overhead or recovery cost.
For follow-up practice, compare the three broad strategies. Prevention deliberately breaks a necessary condition, but may restrict useful concurrency. Avoidance checks whether granting a request leaves the system in a safe state and normally needs information about maximum claims. Detection allows allocations and checks later, after which the system needs a recovery action such as terminating processes or reclaiming resources. Do not imply that one policy is universally best.
Review the words that cost marks
The most useful review is not “I got 72 per cent”. It is a list of phrases that were too broad, unsupported or missing an assumption. Listen for these patterns:
- “The kernel handles it” without naming the trap, queue, table or decision;
- “Threads are faster” without saying whether you mean creation, switching or communication;
- “The page is loaded” without explaining where it comes from and how the translation changes;
- “There is a cycle, so there is deadlock” without stating the resource-instance assumption;
- “Round-robin is better” without naming the workload and time-quantum trade-off.
Use a transcript to replace vague phrases with sentences you can say naturally. Do not memorise a paragraph so rigidly that you cannot answer a changed question. Memorise the sequence and the decision points instead.
I would draw the processes and resources, then look for a cycle. A cycle means the system is deadlocked. For a single instance of each resource, that cycle in the wait-for graph indicates deadlock; with multiple instances I would need the resource-allocation state as well.
A cycle means the system is deadlocked.
The statement is too broad. A cycle in a wait-for graph is decisive under the single-instance assumption, but cycles involving multiple resource instances need further analysis.
Say: For single-instance resource types, a cycle indicates deadlock; with multiple instances, a cycle may be necessary without being sufficient.Read the replacement aloud three times, then answer the same station with a different example. For instance, use two processes and two locks, or describe a resource-allocation graph rather than a wait-for graph. The aim is flexible explanation, not recital.
A repeatable session plan
For a 30-minute practice session, spend five minutes recalling one board section without notes. Spend twelve minutes sitting two stations, including follow-ups. Spend eight minutes listening to the recording and identifying one missing mechanism and one unsupported claim. Spend the final five minutes making two new cards or a short correction note.
At the next session, begin with the corrections before adding new material. A useful progression is:
- Recall: define the mechanism and draw its sequence.
- Explain: answer the opening question in two to three minutes.
- Stress-test: change one assumption and answer the follow-up.
- Repair: practise the exact sentence that was missing.
- Transfer: apply the idea to a new workload, resource graph or memory reference.
For a wider syllabus, rotate sections rather than spending every session on processes. A balanced cycle might cover processes and threads, scheduling, synchronisation, deadlocks, memory management, virtual memory, storage and file systems, input/output, protection and system calls. Use your course outline to decide the order and depth.
How MySummaries helps
MySummaries can turn your operating systems notes into a board, generate oral stations from that board, record your answers and return criteria-based feedback on correctness, reasoning, trade-offs and clarity. It can also turn repeated omissions—such as forgetting the single-instance assumption—into revision cards for later practice. Start at MySummaries.