Loading page…
Master the fundamental concepts of process management through this focused micro-challenge.
You have read the whole brief, and the concepts above stay free on every task. Writing and running the code needs a plan.
Three hints are available for this task, revealed one at a time inside the code workspace so you can struggle productively before seeing them.
Every task includes starter code, theory, and hidden tests so you can implement and verify locally in the browser.
How it worksCPU affinity restricts which hardware threads may run a process. The scheduler still picks order, but the allowed set shrinks. Database engines pin worker threads to reduce cache migration; container runtimes expose affinity through cgroup cpuset.
Linux exposes masks and syscalls:
Cpus_allowed_list shows effective maskFor example, pinning PID 9000 to CPUs {2,3} means the run queue for that task never dispatches on CPU 0 even if it is idle.
This is the exact mechanism behind Linux's taskset and sched_setaffinity(2), which production systems use to pin latency-sensitive workloads like Redis or DPDK packet processors away from cores handling interrupts, avoiding cache-line bouncing across NUMA nodes. Getting affinity-aware load balancing wrong is a real operational trap: pinning too many processes to one core creates the exact imbalance this task asks you to demonstrate.
Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.
Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.
You will maintain an affinity mask per PCB and filter runnable tasks during dispatch. The exercise requires measuring migration counts before and after pinning to show fewer cross-core context switches.
Model CPU affinity with per-CPU run queues. Each task carries a CPU bitmask, as with sched_setaffinity(2). It may only be placed on, migrated to, or balanced onto a CPU whose bit is set. Pinning is useful for cache locality and isolation, but it can also defeat the load balancer, and this simulation shows both effects.
cLoading…
EINVAL, and an unknown task gives ESRCH.balance: nothing on cpuN may move (affinity) and stop. A task counts as placed when it is spawned, migrated or moved.cLoading…
The mask shown is the effective one, after offline CPUs are dropped. show lists each CPU's tasks in spawn order. Other messages: spawn NAME: EINVAL (no online CPU in mask 0xM), spawn NAME: name in use or table full, getaffinity NAME: ESRCH, exit NAME: ESRCH, cpus: tasks already exist.
Input:
cLoading…
Output:
cLoading…
mask >> c & 1, and always AND a mask with the online mask before storing it.Hidden tests cover migration when affinity excludes the current CPU, masks with offline bits, EINVAL and ESRCH, a balancer that moves several tasks, a balancer stuck behind pinned tasks, a balancer that skips the lightest CPU for one the task is allowed on, exits that change the loads, and changing the CPU count too late.