CPU Scheduling & Parallelism Simulator

From poker turns to process scheduling

Texas Hold’em supplied the initial interest: several participants take turns while sharing a limited resource. I abstracted that idea into operating-system tasks and CPU scheduling. The delivered project is a CPU scheduling and parallelism simulator. Its experimental workload is random-number-based Monte Carlo sampling, rather than poker dealing or hand-strength evaluation.

The work has two distinct parts. A discrete simulator calculates scheduling timelines and waiting metrics. Separate Python experiments measure real execution time with threads and processes. Keeping them separate helps explain why an abstract scheduling result and a runtime benchmark answer different questions.

Scheduling policies and metrics

I implemented First Come First Serve, Round Robin with a two-unit time quantum, and non-preemptive Priority scheduling. Each task stores its burst duration, remaining work, priority, and completion time. The simulator exports Gantt-style charts and computes average waiting and turnaround time for a fixed four-task example.

In this implementation all four tasks are available initially. There is no explicit context-switch cost or later arrival stream. Consequently, differences in the simulated waiting metrics come from execution order and time slicing, not measured operating-system switching overhead. A result on these four tasks is not a general ranking of scheduling algorithms.

Threads versus processes

The runtime experiment submits eight Monte Carlo tasks and varies the worker count across 1, 2, 4, and 8. Each task performs a CPU-bound loop using Python random sampling. Threads share a process, whereas multiprocessing uses separate processes.

In the classroom experiment, adding threads did not yield the expected CPU-bound speedup. The presentation also compared local Windows execution with a Google Cloud Linux environment and discussed process overhead and limited VM resources. These observations are specific to that workload, Python setup, and hardware. I do not present a universal speedup factor or treat the archived plots as repeated-trial statistical estimates.

What I learned

The most useful outcome was connecting scheduling concepts to observable behavior while learning to state what each measurement actually represents. The project gave me practice with Python concurrency, experimental comparison, charting, and technical explanation. A stronger benchmark would repeat trials, record CPU allocation and software versions, and distinguish startup cost from steady-state work.

Code and the original classroom presentation are available on request: contact me.