Loading...
Loading...
Loading...
Core CS and SQL interview guide
Processes, threads, scheduling, memory management and deadlocks. Every answer is short enough to say aloud, and every question links to the lesson that teaches it.
60 questionsLast updated
A process is a program in execution with its own address space and resources. A thread is a unit of execution inside a process; threads share the process's heap, code and files but each has its own stack, registers and program counter. Threads are cheaper to create and switch, processes are better isolated.
Follow-up: When would you choose processes instead of threads? When isolation matters, such as browser tabs or an untrusted plug-in: a crash or an attack cannot reach another process's memory. Threads suit tasks that share data cheaply, like requests inside one server.
Common mistake: Saying "threads are faster" with no reason. Say what is shared (code, heap, files), what is private (stack, registers) and the trade-off.
Lesson: Processes, threads, process states and context switchingA system call is a program's request to the kernel to do something privileged, which switches the CPU from user mode to kernel mode and back. Examples are read, write, open, fork and exit; in Java they happen inside library calls such as file reads.
Follow-up: Is calling a Java library method a system call? Not directly. A method such as Files.readString runs in user mode and makes one or more system calls inside when it needs the kernel.
Common mistake: Calling it a normal function call. It switches the CPU into kernel mode and back, which is why it costs more than a method call.
Lesson: Processes, threads, process states and context switchingThey share code, heap objects, static data and open files. Each thread has its own stack, local variables, program counter and register values.
Follow-up: Does a local variable need a lock between two threads? No. Local variables live on each thread's own stack, so they are private. Only shared heap objects and static fields can cause race conditions.
Common mistake: Saying threads share the stack. Each thread has its own stack, which is exactly why its local variables are safe.
Lesson: Processes, threads, process states and context switchingA new process is admitted to ready, the scheduler moves it to running, and from running it goes to waiting for I/O, back to ready when preempted, or to terminated when it exits. A waiting process returns to ready, not directly to running.
Follow-up: Why does a waiting process go to ready and not to running? Another process may hold the CPU when the I/O finishes. Only the scheduler decides who runs, so the process joins the ready queue and waits for its turn.
Common mistake: Drawing an arrow from waiting straight to running. That arrow does not exist; every process must pass through ready first.
Lesson: Processes, threads, process states and context switchingThe kernel saves the current process's registers and program counter in its PCB and loads the next process's state. No useful work happens meanwhile, and for processes the memory map changes, so caches and the TLB lose their warm data.
Follow-up: Why is a thread switch cheaper than a process switch? Threads of one process share the address space, so the page table and most cache and TLB contents stay valid. Mostly the registers and stack pointer change.
Common mistake: Calling it free, or "just changing a variable". It is pure overhead: no user work happens while the kernel saves and loads state.
Lesson: Processes, threads, process states and context switchingA program is a passive file on disk, such as App.class or chrome.exe. A process is that program while it is running, with its own memory, program counter, open files and state. One program can run as several processes at once.
Follow-up: Can one program run as several processes? Yes. Open the same app twice, or let a browser start one process per tab, and each process gets its own memory and PCB.
Common mistake: Using the two words as the same thing. A program is a passive file on disk; the process is that file while it runs.
Lesson: Processes, threads, process states and context switchingProcess management (creating, scheduling and ending processes), memory management, file-system management, device and I/O management, and security and protection. It also gives users an interface, such as a shell or a desktop.
Lesson: Processes, threads, process states and context switchingIt has a text (code) section, a data section for global and static variables, a heap that grows for dynamically created objects, and a stack for method calls and local variables. The heap and stack usually grow towards each other.
Lesson: Processes, threads, process states and context switchingA monolithic kernel runs most OS services, such as file systems and drivers, inside the kernel, which is fast but a bug can crash everything; Linux is the usual example, with loadable modules. A microkernel keeps only the basics in the kernel and runs other services as user-space processes, which is more robust but adds message-passing overhead.
Lesson: Processes, threads, process states and context switchingAn interrupt comes from hardware, such as a keyboard press or a timer, and arrives at any time. A trap (or exception) is caused by the running program itself, such as a divide by zero or a system call instruction. Both hand control to the kernel.
Lesson: Processes, threads, process states and context switchingThe scheduler chooses which ready process runs next. The dispatcher actually hands over the CPU: it does the context switch, switches to user mode and jumps to the right instruction. The time it takes is called dispatch latency.
Lesson: Processes, threads, process states and context switchingA CPU-bound process spends most of its time computing, like video encoding. An I/O-bound process mostly waits for disk or network, like a file copier or web server. A good mix keeps both the CPU and the devices busy.
Lesson: Processes, threads, process states and context switchingMultiprogramming keeps several programs in memory so the CPU always has work while one waits for I/O. Multitasking switches between them quickly so users feel they run together. Multiprocessing uses more than one CPU or core. Multithreading runs several threads inside one process.
Lesson: Processes, threads, process states and context switchingfork() and what does it return?fork() creates a new child process that is a copy of the parent. It returns 0 in the child, the child's process id in the parent, and −1 if it fails. Modern systems use copy-on-write so memory is copied only when one side changes it.
Follow-up: Does fork copy all the memory at once? No. Modern systems use copy-on-write: parent and child share the pages and a page is copied only when one of them writes to it.
Common mistake: Saying fork returns the parent's id. It returns 0 in the child, the child's id in the parent, and -1 on failure.
Lesson: Processes, threads, process states and context switchingexec do after fork?exec replaces the current process's program with a new program, keeping the same process id. A shell runs a command by forking a child and having the child call exec on the command.
An orphan is a child whose parent exited first. On Linux it is adopted by init/systemd (or a designated subreaper), which later reaps it, so orphans are normally harmless.
A daemon is a background process with no terminal that provides a service, such as a web server, cron or sshd. On Windows the similar idea is a service.
Inter-process communication lets separate processes exchange data. Common mechanisms are pipes, message queues, shared memory, sockets and signals.
Lesson: Processes, threads, process states and context switchingUser-level threads are managed by a library without the kernel knowing, so switching is very cheap, but one blocking call can block them all. Kernel-level threads are known to the OS, so they can run on different cores and block independently, at a higher switching cost.
Lesson: Processes, threads, process states and context switchingPlatform threads, the normal new Thread(...), map one-to-one to OS threads on HotSpot. Virtual threads, final in Java 21, are scheduled by the JVM onto a small pool of carrier OS threads, so millions can exist cheaply.
Follow-up: Then why were virtual threads added? Virtual threads are cheap, so a server can give every request its own thread and the JVM parks it during blocking I/O, without running out of OS threads.
Lesson: Processes, threads, process states and context switchingNEW and TERMINATED match directly. Java's RUNNABLE covers both ready and running, and BLOCKED, WAITING and TIMED_WAITING correspond to the OS waiting state for locks, signals or timeouts.
The shell asks the OS to create a process: the loader reads the program file, the OS sets up its address space and a PCB, loads code and libraries, and puts the process in the ready queue. When the scheduler picks it, the dispatcher starts it at its entry point.
Lesson: Processes, threads, process states and context switchingIn FCFS, when a long CPU-bound job runs first, many short jobs queue behind it, like vehicles behind a slow truck. Average waiting time rises sharply even though total work is the same.
Follow-up: How would you reduce it? Run short jobs first (SJF) or use preemption such as Round Robin, so one long job cannot hold the CPU while many short jobs wait.
Common mistake: Calling it a deadlock or saying FCFS starves jobs. Nothing waits forever; the short jobs only wait a long time.
Lesson: CPU scheduling: FCFS and SJFTurnaround time is the total time from arrival to completion. Waiting time is the part of it spent in the ready queue, so waiting = turnaround − burst.
Follow-up: A process arrives at 3, needs 4 ms and finishes at 15. Give both. Turnaround is 15 - 3 = 12 ms. Waiting is 12 - 4 = 8 ms.
Common mistake: Forgetting to subtract the arrival time. Turnaround starts counting at arrival, not at time 0.
Lesson: CPU scheduling: FCFS and SJFFCFS runs processes in arrival order, each until it finishes or blocks, using a simple FIFO queue. It is non-preemptive.
Follow-up: What does the chart show if the next process has not arrived yet? An idle gap. The next start is the larger of the current time and the arrival time, so the CPU waits for it.
Common mistake: Starting the next process at the previous finish time even though it has not arrived. That gives a negative waiting time, a sure sign of a mistake.
Lesson: CPU scheduling: FCFS and SJFSJF is non-preemptive: the chosen job runs to completion. SRTF is preemptive: if a new job arrives with less remaining time than the running job, the running job is stopped and returned to the ready queue.
Follow-up: Which one has more context switches? SRTF, because every arrival can preempt the running process. SJF switches only when a job finishes.
Common mistake: Saying they always give the same schedule. They differ as soon as a shorter job arrives while another is running.
Lesson: CPU scheduling: FCFS and SJFResponse time is the time from arrival until the process first gets the CPU. A user typing or clicking notices delay before the first reaction, even if the whole task takes longer.
Follow-up: Which algorithm gives the best response time? Round Robin with a small quantum, because every process gets the CPU soon after arriving. FCFS is worst for jobs stuck behind a long one.
Common mistake: Treating response time and waiting time as the same. Response stops at the first run; waiting counts all the time spent ready.
Lesson: CPU scheduling: FCFS and SJFCPU utilisation and throughput, which we want high, and turnaround time, waiting time and response time, which we want low. Different systems weight them differently: batch systems care about throughput, interactive systems about response time.
Follow-up: Which of these criteria conflict with each other? Throughput and response time often pull apart: fewer context switches raise throughput, but frequent switching gives faster first responses.
Common mistake: Naming only waiting time. Name utilisation and throughput (maximise) and turnaround, waiting and response time (minimise).
Lesson: CPU scheduling: FCFS and SJFCPU scheduling is choosing which ready process gets the CPU next. It is needed because there are usually more ready processes than cores, and the order decides how busy the CPU stays and how long users wait.
Lesson: CPU scheduling: FCFS and SJFIt is the share of time the CPU is busy doing process work. If a 9 ms schedule has 3 ms of idle time, utilisation is 6 ÷ 9 = 66.7%.
Lesson: CPU scheduling: FCFS and SJFWhen a running process waits for I/O, when it is interrupted and goes back to ready, when a waiting process becomes ready, and when a process terminates. Non-preemptive scheduling decides only in the first and last cases.
Follow-up: Which of those cases can a non-preemptive scheduler decide in? Only when a process blocks for I/O or terminates. A preemptive scheduler decides in all four cases.
Lesson: CPU scheduling: FCFS and SJFNo. Every process eventually reaches the front of the queue, as long as each job finishes. Its problem is long waits, not starvation.
Lesson: CPU scheduling: FCFS and SJFYes. SRTF preempts only when a new process arrives, and with no later arrivals nothing ever interrupts the shortest job.
Lesson: CPU scheduling: FCFS and SJFBy convention, equal bursts are broken by arrival order, that is FCFS among the tied jobs, unless the question gives another rule.
Lesson: CPU scheduling: FCFS and SJFIt favours short CPU bursts, which are typical of I/O-bound and interactive processes. That keeps devices busy and users happy, but CPU-heavy jobs can wait too long.
Lesson: CPU scheduling: FCFS and SJFRead each process's completion time, compute turnaround as completion minus arrival, subtract the burst to get waiting time, then average. For a preempted process, this automatically counts all the separate waiting gaps.
Lesson: CPU scheduling: FCFS and SJFPreemptive, because interactive users need quick response, and preemption stops one long job from holding the CPU. The cost is more context switches and care with shared data.
Lesson: CPU scheduling: FCFS and SJFIt is the time the dispatcher takes to stop one process and start another. Algorithms that switch very often, like SRTF or Round Robin with a small slice, pay this cost many times.
Lesson: CPU scheduling: FCFS and SJFNot as the main desktop scheduler. Linux used the Completely Fair Scheduler for many years and moved to EEVDF in kernel 6.6, and Windows uses priority-based preemptive scheduling. FCFS and SJF ideas still appear inside batch queues and as building blocks.
Lesson: CPU scheduling: FCFS and SJFEvery process finishes within its first quantum, so Round Robin behaves exactly like FCFS, including the convoy effect.
Follow-up: Then when does Round Robin differ from FCFS? When the quantum is smaller than some bursts. Long jobs are then preempted and short jobs finish sooner instead of waiting in a convoy.
Common mistake: Saying a big quantum is best because it avoids switches. Round Robin then loses its fairness and its good response time.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesThe CPU spends a large share of time on context switches instead of useful work, and throughput drops. In the extreme, the system does little except switch.
Follow-up: How would you measure the loss? Useful share = q / (q + switch time). With q = 1 ms and a 0.1 ms switch, about 9% of the CPU goes to switching.
Common mistake: Ignoring the switch cost when choosing q. The quantum must be much larger than the context-switch time.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesNo. The FIFO order guarantees every ready process a turn in each round.
Follow-up: Can SJF starve a job? What is the difference? Yes. A long job is never the shortest while short jobs keep arriving. Round Robin picks by queue position, not by length, so every process gets a turn.
Common mistake: Saying long jobs starve because they need many turns. They are slow, not starved: they still get a turn every round.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesEach process has a priority, and the CPU goes to the ready process with the highest priority. It can be preemptive, where a higher-priority arrival takes the CPU, or non-preemptive.
Follow-up: What is the difference between the preemptive and non-preemptive version? Preemptive: a newly arrived higher-priority process takes the CPU at once. Non-preemptive: it waits until the running process finishes or blocks.
Common mistake: Assuming a bigger number always means higher priority. Check the question: textbooks often use a smaller number for a higher priority.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesAging gradually raises a process's priority the longer it waits. For example, improving the priority by 1 every 15 minutes means even the lowest-priority process will eventually run.
Follow-up: Give an example with numbers. Raise the priority by 1 every 15 minutes. A process at priority 127 reaches 0 after about 32 hours, so even the lowest-priority job eventually runs.
Common mistake: Saying aging lowers the priority of long-waiting jobs. It raises it, so waiting jobs become more important with time.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesIt is a multilevel queue where processes can move. A process that uses its full quantum is moved down to a queue with a longer quantum; one that waits too long can be moved up to prevent starvation.
Follow-up: How does a CPU-heavy process end up in the lowest queue? It uses its whole quantum every time, so it is demoted level by level until it reaches the last queue, which has the longest quantum.
Common mistake: Describing MLFQ as fixed queues. The key idea is movement: processes move down when they use full quanta and can move up while waiting.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesThe usual textbook convention puts the new arrival in the queue before the preempted process. Different books differ, so in an exam I state the assumption I am using.
Follow-up: Does the convention change the answer? It can change the order and so the numbers. That is why I state the convention (new arrival first) before I solve.
Common mistake: Silently picking an order. A different convention gives a different chart, so say which one you used.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesYes. The timer interrupt takes the CPU away at the end of each quantum, even if the process still has work.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesEvery process gets a turn within a bounded time, so response time is predictable and no one starves. Users at many terminals all feel the system is responding.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesUsually not. Round Robin often has higher average waiting and turnaround times than SJF, but much better response time and fairness.
Common mistake: Saying Round Robin is always better than SJF. It trades a higher average waiting time for fairness and a quick first response.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesIt depends on the system. Many textbooks and Unix-style systems use smaller numbers for higher priority, but some systems do the opposite, so I always check the question.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesInternally by the OS from measurable things such as memory needs, time limits or I/O-to-CPU ratio, or externally by users and admins, for example importance or payment. On Linux, nice values are one external control.
The ready queue is split into separate queues by process type, such as system, interactive and batch, each with its own algorithm. A process stays in one queue, and higher queues usually run before lower ones.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesFrom behaviour. A process that keeps using its whole quantum is treated as CPU-heavy and demoted, while one that blocks quickly for I/O stays high, so interactive jobs get fast service.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesIn a multilevel queue, a process is permanently assigned to one queue. In MLFQ, processes move between queues based on their CPU usage and waiting time.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesEither by fixed priority, where a lower queue runs only when higher ones are empty, which can starve lower queues, or by time slicing between queues, for example 80% to interactive and 20% to batch.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesEach quantum ends with a switch. If the quantum is 1 ms and a switch costs 0.1 ms, about 9% of CPU time is lost; with a 10 ms quantum, it is under 1%.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuesA preemptive priority scheme where foreground and UI threads get higher priority and short quanta, with background work in lower levels, close to an MLFQ. Aging or fair-share rules keep background work from starving.
Lesson: CPU scheduling: Round Robin, priority and multilevel queuescount++ not atomic?It compiles to three steps: load the value, add one, store it back. Another thread can run between those steps and read the old value.
Follow-up: How do you fix it in Java? Use synchronized or a ReentrantLock around the update, or AtomicInteger.incrementAndGet, which does the whole update as one atomic step.
Common mistake: Saying it is atomic because it is one line. The line compiles to load, add and store, and a switch can happen between them.
Lesson: Synchronisation, critical sections and semaphoresA mutex is a lock with an owner: the thread that locks it must unlock it, and it protects a critical section. A semaphore has no owner and holds a count, so it can also be used for signalling, where one thread waits and another signals.
Follow-up: When would you use a semaphore instead of a mutex? To limit access to N copies of a resource, such as 3 printers or 30 licences, or to let one thread signal another, for example to wait until a job is done.
Common mistake: Stopping at "a mutex is a binary semaphore". Add the ownership difference: only the thread that locked a mutex should unlock it.
Lesson: Synchronisation, critical sections and semaphoresIt is the part of the code that reads or writes shared data. Only one thread at a time should run it.
Follow-up: What should you avoid inside one? Long work such as network calls, disk I/O or sleeping, because every other thread waits outside. Keep it as short as possible.
Lesson: Synchronisation, critical sections and semaphoresEach lesson has quizzes, practice and more interview questions on the same topic.
Open the first lesson