Operating system fundamentals

#Optional: processes, threads and tasksBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

A CPU executes instructions. A logical CPU is an execution lane visible to the OS and may be a physical core or a logical processor. The scheduler assigns execution time to runnable threads. “Runnable” means a thread can continue when scheduled, unlike one waiting for I/O or a lock. This distinction will help explain async later.

The OS isolates programs and distributes CPU time. A process owns resources and a virtual address space. A thread is an execution path with registers and a stack; threads within a process share memory and resources, requiring synchronization. A .NET Task represents an operation and its completion rather than a new OS thread.

CPU-bound Tasks commonly run on the ThreadPool; I/O Tasks depend on the underlying APIs and OS. Separate processes help isolation or external execution but are not cheap substitutes for method calls.

#Optional: process memory layoutBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Before the map: a virtual address is an address used by a program; the OS maps it to a physical memory page or backing storage when needed. The .NET GC manages managed memory; libraries or system calls allocate native memory outside the GC's object tracking. The JIT compiler turns IL into processor instructions at runtime, and ASLR changes memory addresses between runs for security. The following layout is a teaching approximation.

To understand memory growth, distinguish process regions rather than calling everything one heap. This is a teaching model; actual address ordering varies with the OS, runtime and ASLR.

A value type does not always live on the stack: object fields are inline, boxing creates a managed object, and async state can live on the heap. This .NET console example needs using System.Diagnostics;; its snapshots are approximate, not a substitute for profiling.

using System.Diagnostics;

using var process = Process.GetCurrentProcess();
process.Refresh();
Console.WriteLine($"Resident bytes: {process.WorkingSet64}"); // (1)
Console.WriteLine($"Managed estimate: {GC.GetTotalMemory(false)}"); // (2)

If managed memory stays stable while working set grows, inspect native allocations, stacks and mappings, accounting for platform-specific metric definitions.

#Optional: scheduling and context switchingBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Runnable threads commonly outnumber logical CPUs. The scheduler chooses which runs and can preempt it to let others execute. Time slices and priorities depend on the OS and scheduling class; they do not promise a fixed execution order or perfect fairness.

1. A thread runs until it blocks, yields or is preempted.
2. The OS saves execution state such as registers and instruction position.
3. Another thread runs; cache and TLB locality may suffer. Switching processes can add address-space handling costs.
4. The original thread later resumes from its saved state rather than restarting the method.

Context switches have direct costs and indirect cache effects, but no universal fixed duration. More threads can increase contention, memory and switching instead of throughput. Raising priority may starve other work or encounter priority inversion; it does not fix a slow query.

#Optional: mutexes, semaphores and spinlocksBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Shared resources need admission rules, but the wrong primitive can turn an application into one queue. A mutex has one owner; a semaphore admits a configured number of participants. A spinlock consumes CPU while waiting instead of sleeping, so it belongs only around extremely short waits justified by measurement, never I/O.

This class fragment bounds concurrency. Dispose the semaphore when the service lifetime ends and no users remain.

private readonly SemaphoreSlim slots = new(4, 4);

public async Task RunLimitedAsync(Func<Task> work, CancellationToken ct)
{
    await slots.WaitAsync(ct); // (1)
    try
    {
        await work(); // (2)
    }
    finally
    {
        slots.Release(); // (3)
    }
}

Do not await inside lock. Choose a primitive appropriate to the context, and do not hold a thread-owned mutex across continuations that may resume on another thread.

#Optional: deadlock and the Coffman conditionsBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

A deadlock occurs when participants wait for resources held by one another and none can progress. In the classical model, all four Coffman conditions must hold; their presence alone does not prove a deadlock has occurred.

If a transfer requires two account locks, acquire them by account ID in every code path. A timeout permits failure or retry but does not automatically repair the design: release held resources and handle partial work. Starvation means work gets insufficient opportunity; livelock means participants remain active without useful progress.

#Optional: virtual memory, paging and page faultsBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Each process sees a virtual address space. Hardware and the OS translate its pages to physical frames or backing storage. Reserving address space does not mean consuming that amount of RAM. Paging supports protection, sharing and demand loading, not only compensation for insufficient RAM.

1. A program accesses a virtual address, with translation checked through the TLB or page tables.
2. An absent page or disallowed access triggers a page fault handled by the OS.
3. A valid demand page may be supplied through zero-fill or an existing mapping without disk I/O; a minor fault is not necessarily an application error.
4. If storage must be read, the wait is more expensive; Linux commonly calls this a major fault.
5. Invalid access may fail the process rather than load a page.

The working set or resident set represents pages currently in RAM for a process, with platform-specific definitions. Resident pages are not necessarily unique or private. Memory pressure and excessive paging can cause thrashing, where page movement displaces useful work.

Compare process and container metrics: file cache may be charged to a cgroup, and swap can be disabled or limited. Virtual-memory growth alone is not proof of a leak, and not every page fault reads a disk.

#Optional: the GC, the OS and Server GCBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

The GC manages managed-object lifetimes above virtual memory. The OS manages mappings, pages and process-level resources. Collecting an object does not necessarily reduce working set immediately: the runtime may retain capacity for reuse, and the OS controls residency.

The ASP.NET Core web SDK requests Server GC by default, but inspect the actual mode through GCSettings.IsServerGC. Runtime behavior can adapt to CPU and memory limits and evolves over time; “one fixed heap per CPU” is not a universal rule.

The managed heap is only part of process footprint; native buffers, thread stacks and JIT code also consume memory. A GC heap hard limit is not a whole-process memory cap. Leave native and accounting headroom: a container can be killed before a managed OutOfMemoryException appears. See Workstation and Server GC.

#Optional: I/O models, epoll, kqueue and IOCPBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

If every waiting socket occupies a thread, large connection counts consume stacks and scheduling capacity. Blocking I/O suspends a thread until a result. Nonblocking I/O returns promptly when no data is available. Multiplexing monitors many sockets without one waiting thread per socket.

.NET socket async APIs hide many differences. await observes operation completion; it does not itself implement epoll. Not every async API guarantees zero blocked threads internally: file I/O, providers and OS behavior can differ.

This fragment belongs in an async method with using System.Net.Sockets;, a connected socket and an available ct. It performs one read, not complete protocol framing.

byte[] buffer = new byte[4096];
int read = await socket.ReceiveAsync(buffer.AsMemory(), SocketFlags.None, ct); // (1)
if (read == 0) // (2)
    return;
Console.WriteLine($"Received {read} bytes"); // (3)

Edge-triggered epoll requires correct nonblocking reads until EAGAIN. Ordinary applications should use .NET APIs rather than rebuild an event loop. See the epoll reference.

#Optional: file descriptors, handles and limitsBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

An open file or socket is more than a managed object: it owns an OS resource. On Unix, a file descriptor indexes a process resource table. Windows uses handles with access rights and platform-specific behavior. A handle is neither an ordinary pointer nor a permanent identity; values can be reused after closure.

Missing disposal can exhaust limits even with a small managed heap. Some wrappers eventually finalize resources, but timing is unpredictable and not every resource has a finalizer. Use using or await using, and appropriate SafeHandle wrappers for native interop.

This complete console example writes a file with explicit UTF-8 and line endings for predictable cross-platform output.

using System.Text;

var path = Path.Combine(Path.GetTempPath(), $"invoice-{Guid.NewGuid():N}.txt");
await using (var file = new FileStream(path, FileMode.CreateNew,
    FileAccess.Write, FileShare.None, 4096, FileOptions.Asynchronous)) // (1)
{
    var bytes = Encoding.UTF8.GetBytes("Invoice total: 100 EGP\n");
    await file.WriteAsync(bytes); // (2)
} // (3)
Console.WriteLine(path);

For “too many open files,” inspect descriptor counts, owners, limits and leaks before raising limits. Sockets, pipes and epoll instances also consume descriptors. Diagnostic tools may be absent from minimal containers, so plan host-side or debug-image inspection.

#Optional: signals and graceful container shutdownBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Deployment can stop a process while it handles work. A Linux container runtime typically sends SIGTERM and may send SIGKILL after a grace period. Generic Host with ConsoleLifetime initiates shutdown on SIGTERM; SIGKILL cannot be caught and does not guarantee finally blocks. A shell wrapper can obstruct signals unless it forwards them or uses exec correctly.

This complete ASP.NET Core 10 Program.cs keeps the notification callback short. Put real async cleanup in a hosted service's StopAsync or disposal with a deadline.

var builder = WebApplication.CreateBuilder(args);
builder.Services.Configure<HostOptions>(options =>
    options.ShutdownTimeout = TimeSpan.FromSeconds(20)); // (1)
var app = builder.Build();

app.Lifetime.ApplicationStopping.Register(() => // (2)
    app.Logger.LogInformation("Shutdown requested; draining work"));

app.MapGet("/", () => "Ready");
await app.RunAsync(); // (3)

Remove the instance from routing and make processing idempotent because crashes can occur at any time. Graceful shutdown does not replace durable queues and transactions. See Generic Host lifecycle.

#Optional: cgroups, namespaces, Windows and LinuxBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Linux containers use kernel mechanisms rather than a full guest OS per container. Namespaces alter the visible view of resources such as process IDs, networking and mounts. Cgroups group processes for resource accounting and limits such as CPU and memory. Namespaces do not provide resource quotas, and cgroups do not provide network isolation.

A CPU quota can cause throttling even when the host has spare capacity outside that allocation. Memory limits can lead to OOM killing depending on conditions. Monitor cgroup usage rather than only the managed heap, and do not hardcode cgroup file paths without understanding version and mount layout. See the cgroup v2 reference.

Do not assume every Windows filesystem has identical case rules or every Linux filesystem identical capabilities. Test on the deployment target in CI and avoid drive letters, registry dependencies and Windows-only libraries in cross-platform code. Containers share a kernel rather than providing VM isolation; reduce privileges and capabilities accordingly.