Operating System Fundamentals Questions

Comprehensive knowledge of operating system concepts and practical administration across Linux, Unix, and Windows platforms. Core theoretical topics include processes and threads, process creation and termination, scheduling and context switching, synchronization and deadlock conditions, system calls, kernel versus user space, interrupt handling, memory management including virtual memory, paging and swapping, and input and output semantics including file descriptors. Practical administration and tooling expectations include file systems and permission models, user and group account management, common system utilities and commands such as grep, find, ps, and top, package management, service and process management, startup and boot processes, environment variables, shell and scripting basics, system monitoring, and performance tuning. Platform specific knowledge should cover Unix and Linux topics such as signals and signal handling, kernel modules, initialization and service management systems, and command line administration, as well as Windows topics such as the registry, service management, event logs, user account control, and graphical and command line administration tools. Security and infrastructure topics include basic system hardening, common misconfigurations, and an understanding of containerization and virtualization at the operating system level. Interview questions may probe conceptual explanations, platform comparisons, troubleshooting scenarios, or hands on problem solving.

MediumTechnical

61 practiced

Define deadlock and its necessary conditions. Provide a small code or resource-allocation example that can deadlock and then explain three practical strategies to handle deadlocks in production systems: prevention, avoidance (e.g., Banker's algorithm), detection and recovery.

Sample Answer

Deadlock is a situation in concurrent systems where a set of processes/threads are each waiting indefinitely for resources held by others, so none can proceed.

Necessary conditions (Coffman):- Mutual exclusion — at least one resource is non-sharable.- Hold and wait — a process holds resources while waiting for others.- No preemption — resources cannot be forcibly taken away.- Circular wait — a circular chain of processes each waits for a resource held by the next.

Example (Python) — two threads and two locks can deadlock:

python

import threading
import time

lock_a = threading.Lock()
lock_b = threading.Lock()

def t1():
    with lock_a:
        time.sleep(0.1)
        with lock_b:
            print("t1 done")

def t2():
    with lock_b:
        time.sleep(0.1)
        with lock_a:
            print("t2 done")

threading.Thread(target=t1).start()
threading.Thread(target=t2).start()

If t1 acquires lock_a and t2 acquires lock_b, each waits for the other -> deadlock.

Three practical strategies

1) Prevention — eliminate one Coffman condition.- Example actions: enforce lock ordering to prevent circular wait; require threads to acquire all needed locks at once (no hold-and-wait); make some resources preemptible.- Tradeoffs: simplifies reasoning but can reduce concurrency or require redesign.

2) Avoidance (Banker’s algorithm) — make dynamic checks to ensure system never enters an unsafe state.- Model resources and maximum needs; only grant a request if system can still satisfy all processes' maximum needs later.- Practical use: works for small, well-known fixed resource types; not suitable for many dynamic resources (e.g., locks per object) due to state/overhead.

3) Detection and recovery — allow deadlocks, detect them, then recover.- Detection: build resource-allocation graph or run periodic detection (e.g., wait-for graph cycle detection).- Recovery: abort/rollback some transactions, preempt resources, or restart processes; choose victims by cost heuristics (least work lost, low priority).- Practical use: common in DBMS and distributed systems where prevention/avoidance is impractical.

In production choose depending on workload: lock-ordering + timeouts for short critical sections, detection+recovery for long transactions, and avoidance where resources and maximum demands are known. Monitor for long waits and log stack traces to help diagnose live deadlocks.

HardTechnical

65 practiced

Explain atomic operations and lock-free programming primitives. Compare atomic compare-and-swap (CAS) with mutexes in terms of fairness, performance under contention, and complexity. Provide a simple lock-free stack pseudocode sketch using CAS and discuss ABA problem and how to mitigate it.

Sample Answer

Atomic operations are indivisible CPU/OS-provided primitives that complete without intermediate observable states (no other thread sees a partial update). They enable lock-free algorithms where at least one thread makes progress. Common primitives: atomic read/write, fetch-and-add, and compare-and-swap (CAS).

CAS vs mutexes- Fairness: Mutexes can be fair (FIFO) if implemented so; CAS-based algorithms are typically unfair — a fast thread can repeatedly succeed while others starve.- Performance under contention: CAS has lower overhead when contention is low (no context switches). Under high contention, CAS can suffer wasted retries (livelock), while mutexes serialize access and may perform better because of queuing and blocking, despite context-switch costs.- Complexity: Mutexes are conceptually simple and easier to reason about. CAS-based lock-free code is more complex (correctness, memory ordering, ABA, retries) but offers higher concurrency and avoids priority inversion and blocking.

Simple lock-free stack (pseudocode using CAS)

cpp

struct Node { T value; Node* next; };

atomic<Node*> head = nullptr;

void push(T v) {
  Node* n = new Node{v, nullptr};
  while (true) {
    Node* h = head.load();
    n->next = h;
    // try to swing head from h to n
    if (compare_and_swap(&head, h, n)) return;
    // else retry
  }
}

Node* pop() {
  while (true) {
    Node* h = head.load();
    if (h == nullptr) return nullptr;
    Node* next = h->next;
    if (compare_and_swap(&head, h, next)) return h;
    // else retry
  }
}

ABA problem- Scenario: thread A reads head = X; paused; other threads pop X, pop Y, push X again — head returns to X but underlying state changed. CAS sees expected X and succeeds incorrectly.Mitigations- Use version/tagged pointers (pair head pointer with a counter and CAS both: pointer+counter).- Use hazard pointers or epoch-based reclamation to prevent reused node addresses until safe.- Use double-width CAS (DCAS) where available or language runtime atomic stamped references (e.g., Java's AtomicStampedReference).

Trade-offs summary: CAS lock-free code gives low-latency non-blocking progress and can scale well, but requires careful handling of memory reclamation, ABA, and complex reasoning. Mutexes are simpler and better under extreme contention or when blocking is acceptable.

MediumTechnical

107 practiced

How can you change environment variables for a running process? Explain what is and is not possible, and propose strategies to update runtime behavior without restarting the process (e.g., config reload endpoints, signaling, using a proxy process, or process supervisors).

Sample Answer

Short answer: you generally cannot change another running process’s environment from outside — a process’s environment is private memory inherited at start. You can change the environment variables inside the process itself (via setenv / os.environ), or restart the process with a new environment. To update runtime behavior without restarting, use patterns that let the process re-read configuration or route traffic through a component you can change.

What is and isn’t possible- Not possible externally: arbitrarily modify the env block of another running process from a different PID (Unix doesn’t provide a safe public API for that).- Possible inside the process: call setenv/putenv or modify os.environ (Python) to change its own environment and any subsequently spawned children will inherit those values.- Possible indirectly: replace the process (supervisor), or change externally used config sources the process reads.

Practical strategies to update behavior at runtime1) Config reload endpoint / API- Expose an authenticated HTTP endpoint (e.g., POST /-/reload) that validates and applies new settings in-memory.- Example (Python Flask skeleton):

python

from flask import Flask, request
app = Flask(__name__)
config = {"feature_x": False}

@app.route("/-/reload", methods=["POST"])
def reload():
    payload = request.json
    config.update(payload)
    # apply changes: flip internal flags, update log level, etc.
    return "ok", 200

2) Signal-driven reloading (SIGHUP)- Install a signal handler that re-reads a config file and atomically swaps state. Good for daemonized apps.- Example (Python):

python

import signal
def handle_hup(signum, frame):
    load_config_from_file()
signal.signal(signal.SIGHUP, handle_hup)

3) Watch a config file or service discovery store- Poll or use inotify/kqueue to detect changes; or subscribe to etcd/consul/watch to receive updates and apply them.4) Feature flags / config services- Store dynamic flags in a central store (LaunchDarkly, etcd) the process reads periodically or subscribes to. Allows fine-grained runtime toggles without restarts.5) Proxy or sidecar- Put a proxy (nginx/envoy) or sidecar in front of the process and change routing, TLS, or headers at the proxy without touching the app.6) Supervisor-managed restart (zero-downtime)- Supervisor/launcher (systemd, kubernetes deployments) can start a new process with updated env and switch traffic (rolling restart) to avoid downtime.7) Fork/exec pattern- A small supervisor process keeps the desired env and execs the worker. Update supervisor’s env then signal it to fork/exec a new worker so the worker always has correct env.

Trade-offs and best practices- Safety: in-process changes must be thread-safe and applied atomically; prefer immutable config objects and swap pointers.- Authentication & audit: ensure reload endpoints are authenticated and rate-limited.- Consistency: use versioned configs and health checks to avoid partial application across a cluster.- Observability: log config changes and expose metrics to verify effects.- When env variables are secrets: prefer vault/secret managers and dynamic tokens rather than raw env changes.

Recommendation: design apps to be config-reloadable from the start (signal or API + atomic swap), use central config/feature flagging for fast changes, and rely on supervisors/proxies for environment-level or structural changes requiring restart.

HardSystem Design

74 practiced

Design a scheduler for a multi-core operating system that must support tens of thousands of runnable threads, multiple priority levels, fairness, and low latency for interactive tasks. Describe data structures, CPU run queues, load balancing between cores, and how to handle priority inversion and starvation.

Sample Answer

Requirements:- Support 10k+ runnable threads, multiple priority levels, fairness, low latency for interactive tasks, multicore scalability, low locking overhead.

High-level design:- Each CPU has a private runqueue for scalability and cache locality. A global scheduler coordinates load balancing and long-term fairness.

Data structures:- Per-CPU runqueue: - priority_buckets: array[NUM_PRIORITIES] of doubly-linked lists (or intrusive queues) of runnable tasks. - runnable_bitmap: hierarchical bitset (e.g., 64-bit words + top-level summary) to find highest-priority non-empty bucket in O(1) with bit-scan. - counters: runnable_count, interactive_hint_count. - spinlock or per-CPU lock for short critical sections; most ops are lockless via per-CPU ownership.- Task struct: - priority, vruntime (for CFS-like fairness), cpu_affinity, last_cpu, sleep_time, flags (interactive, real-time).- Global structures: - global_idle_cores list, load_counters per node, periodic global bitmap for overloaded cores.

Scheduling policy:- Hybrid: real-time (fixed priority FIFO/RR) for highest classes; multilevel feedback + virtual runtime (CFS) for normal tasks. Interactive detection: boost recently unblocked short sleeps (sleep wakeup boosting) by lowering vruntime briefly.

Fast paths:- Wakeup path enqueues to local runqueue if target CPU == current or target core's queue unlocked. Update runnable_bitmap atomically.- Choose next: if realtime tasks in any non-empty realtime bucket, pick highest-priority realtime. Else pick lowest vruntime among top few priority buckets using per-priority min-heap or sampled candidate; bitmap gives quick selection.

Load balancing:- Periodic (e.g., every 10–50ms) global balancing: heavily overloaded cores push tasks to global balancer which tries to move tasks to idle/underloaded cores considering affinity and cache warmth.- Work-stealing: idle cores attempt to steal the largest-vruntime (i.e., stealable) tasks from random or neighboring cores, preferring non-cache-sensitive and not-interactive tasks.- Fast offload on wakeup: if wakeup from sleep and originating CPU is different from where it should run (e.g., interactive hint), steal to target CPU to reduce latency.

Fairness & starvation:- Use vruntime-based accounting (like CFS) to ensure long-term fairness. Each task accumulates vruntime weighted by priority/nice.- Aging: tasks not scheduled for X ms receive incremental priority boost or vruntime decay to prevent starvation.- Limit stealing to amount that preserves fairness.

Priority inversion:- For real-time priority inversion (threads waiting on locks), implement priority inheritance on blocking primitives: when a high-priority task blocks on a lock held by lower-priority task, temporarily boost holder’s priority to highest blocked priority until release.- For long critical sections, detect and warn; encourage fine-grained locking.

Low-latency for interactive tasks:- Short sleep detection: tasks that sleep < threshold get interactive flag and temporary priority/vruntime boost on wake to run quickly.- Preemption: enforce preemption ticks for high-priority bursts; allow tickless idle for reduced jitter.- CPU affinity policies: prefer last CPU to keep caches warm for interactive tasks; but preempt for urgent interactive boosts.

Implementation notes and trade-offs:- Per-CPU queues minimize contention and scale to many cores; global balancing trades immediacy for scalability (periodic + opportunistic work-stealing).- Bitmaps + bit-scan provide O(1) selection; per-priority lists avoid scanning thousands of threads.- Priority inheritance adds complexity to locks but solves common inversion; for distributed inversions (across CPUs) limit boosts to single-hop or use futex-like wait queues.- Tuning knobs: balancing interval, steal thresholds, interactive time windows.

Metrics to monitor:- scheduler latency (wake-to-run), throughput, load imbalance, number of priority boosts, lock contention hotspots.

This design balances low-latency interactive response with fairness and scalability using per-CPU runqueues, hierarchical bitmaps, vruntime accounting, aging, priority inheritance, and opportunistic load balancing (work-stealing + periodic rebalancing).

HardTechnical

70 practiced

Describe at a high level how to write a Linux kernel module that registers a character device. Include the steps to allocate device numbers, create a device file (/dev/mychardev), implement file_operations open/read/write/release, and load/unload the module safely. Mention common pitfalls for memory and concurrency in kernel modules.

Sample Answer

Approach (high level):- Reserve a major/minor via alloc_chrdev_region (or register_chrdev_region for fixed numbers).- Initialize a struct cdev with cdev_init and add it with cdev_add.- Create a sysfs class and device so udev creates /dev/mychardev (class_create + device_create).- Implement struct file_operations with .open, .read, .write, .release (and .unlocked_ioctl if needed).- Use proper locking (mutex or spinlock) and safe memory allocation/free (kmalloc/kfree).- Provide module_init to perform setup and module_exit to undo in reverse order.

Minimal skeleton (illustrative):

#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/uaccess.h>
#include <linux/mutex.h>

#define DEV_NAME "mychardev"
static dev_t devt;
static struct cdev my_cdev;
static struct class *my_class;
static char *kbuf;
static DEFINE_MUTEX(my_lock);

static int my_open(struct inode *inode, struct file *filp){
    return 0;
}

static ssize_t my_read(struct file *filp, char __user *buf, size_t len, loff_t *off){
    ssize_t ret = 0;
    if (mutex_lock_interruptible(&my_lock)) return -EINTR;
    /* copy_to_user from kbuf */
    if (copy_to_user(buf, kbuf, min(len, (size_t)strlen(kbuf)))) ret = -EFAULT;
    else ret = min(len, (size_t)strlen(kbuf));
    mutex_unlock(&my_lock);
    return ret;
}

static ssize_t my_write(struct file *filp, const char __user *buf, size_t len, loff_t *off){
    ssize_t ret = 0;
    if (len > 1024) return -EINVAL;
    if (mutex_lock_interruptible(&my_lock)) return -EINTR;
    if (copy_from_user(kbuf, buf, len)) ret = -EFAULT;
    else ret = len;
    mutex_unlock(&my_lock);
    return ret;
}

static int my_release(struct inode *inode, struct file *filp){ return 0; }

static const struct file_operations fops = {
    .owner = THIS_MODULE,
    .open = my_open,
    .read = my_read,
    .write = my_write,
    .release = my_release,
};

static int __init my_init(void){
    if (alloc_chrdev_region(&devt, 0, 1, DEV_NAME) < 0) return -1;
    cdev_init(&my_cdev, &fops);
    if (cdev_add(&my_cdev, devt, 1) < 0) goto unregister;
    my_class = class_create(THIS_MODULE, DEV_NAME);
    if (IS_ERR(my_class)) goto del_cdev;
    device_create(my_class, NULL, devt, NULL, DEV_NAME);
    kbuf = kmalloc(1024, GFP_KERNEL);
    if (!kbuf) goto destroy_class;
    return 0;
destroy_class:
    class_destroy(my_class);
    device_destroy(my_class, devt);
del_cdev:
    cdev_del(&my_cdev);
unregister:
    unregister_chrdev_region(devt, 1);
    return -ENOMEM;
}

static void __exit my_exit(void){
    kfree(kbuf);
    device_destroy(my_class, devt);
    class_destroy(my_class);
    cdev_del(&my_cdev);
    unregister_chrdev_region(devt, 1);
}

module_init(my_init);
module_exit(my_exit);
MODULE_LICENSE("GPL");

Key explanations & pitfalls:- Order matters: create device after cdev_add; on unload reverse order and handle partial failures in init.- Memory: always free kmalloc in exit and on init failure paths to avoid leaks; prefer kzalloc for zeroed memory.- Concurrency: protect shared state with mutex for sleeping contexts; use spinlock for IRQ context and be careful with copy_to/from_user (must be called in process context).- Blocking: do not sleep in atomic contexts; avoid calling copy_to_user while holding spinlocks.- User pointers: always validate and use copy_to_user/copy_from_user to avoid page faults.- Reference counts: use module_put/get if exporting symbols; ensure file->private_data cleaned on release.- Device numbers: consider dynamic alloc (alloc_chrdev_region) to avoid conflicts; store major/minor for logging.- Error handling: on init failure undo any partial setup to avoid orphan devices.

Unlock Full Question Bank

Get access to hundreds of Operating System Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.