I built Process Mind because I wanted a better way to practice Operating System algorithms.
When preparing for exams, I often found myself solving the same types of scheduling, page replacement, disk scheduling, and memory allocation problems repeatedly. The problem wasn't finding explanations of these algorithms. There are plenty of them.
The problem was verification.
For a manually solved problem, it is easy to make a small mistake somewhere in the calculation and only realize it much later. I wanted something where I could enter the same problem, run the algorithm, and immediately compare my result with a deterministic implementation.
That idea became Process Mind.
What is Process Mind?
Process Mind is an interactive web platform for practicing Operating System algorithms.
The current implementation covers four major areas:
- CPU Scheduling — FCFS, SJF, SRTF, Priority, Preemptive Priority, Round Robin
- Page Replacement — FIFO, LRU, Optimal, Second Chance, LRU Counter
- Disk Scheduling — FCFS, SSTF, SCAN, C-SCAN, LOOK, C-LOOK
- Memory Allocation — First Fit, Best Fit, Worst Fit, Next Fit
The goal isn't to simply display the final answer.
The application takes the user's input, validates it, runs the corresponding algorithm, and produces structured results such as calculated metrics, process details, Gantt blocks, and execution steps.
The basic flow is:
User Input
↓
Validation
↓
Algorithm
↓
Structured Result
↓
Metrics + Gantt + Process Details + Execution Steps
↓
UI
This separation became one of the most important design decisions in the project.
The Core Idea: Deterministic Results
There are already many tools that can explain Operating System concepts using AI or generate solutions dynamically.
I wanted Process Mind to solve a different problem.
If I enter a problem, I should get the same result every time.
For algorithm practice, determinism is useful. The application isn't trying to interpret what I meant or generate a plausible explanation. The algorithm implementation processes the input according to its defined rules.
That makes it useful for checking manually solved questions.
For example, with a CPU scheduling problem, Process Mind can calculate:
| Process | Arrival | Burst | Completion | Turnaround | Waiting | Response |
|---|---|---|---|---|---|---|
| P1 | 0 | 7 | 7 | 7 | 0 | 0 |
| P2 | 1 | 1 | 8 | 7 | 6 | 6 |
| P3 | 2 | 7 | 15 | 13 | 6 | 6 |
It can also calculate average turnaround, waiting, and response times and represent execution using a Gantt chart.
The exact numbers depend on the input, but the important part is that the result comes directly from the algorithm.
The Difficult Part Wasn't Writing the Algorithms
Implementing FCFS or SJF isn't particularly difficult once the algorithm is understood.
The harder question was:
What information should the algorithm return?
Initially, it would have been easy to return something like:
completionTime
waitingTime
turnaroundTime
But that isn't enough for an educational tool.
If the purpose is practice and verification, users may also want to understand why a process was selected.
So the result structure evolved to contain more information:
ScheduledResult
├── processes
├── metrics
├── blocks
└── steps
The steps data became particularly useful.
Each execution step can contain information such as:
- current time
- ready processes
- selected process
- waiting queue
- processes that arrived during execution
- queue after execution
- execution window
- whether the CPU was idle
- reason for selecting the process
This allows the UI to show not only what happened, but also some of the state behind the decision.
Handling Preemptive Scheduling
Preemptive algorithms introduced another layer of complexity.
For algorithms such as SRTF and Preemptive Priority Scheduling, a process can be interrupted when another process becomes eligible.
Instead of treating a process as simply "running" or "finished", the implementation needs to maintain its remaining execution time.
For example:
Process
├── arrivalTime
├── burstTime
└── remainingTime
At each relevant point, the algorithm can determine which process should run based on the current state.
Round Robin has a different challenge because execution is controlled by a time quantum. Processes that don't finish within their allocated quantum need to be placed back into the ready queue.
These differences meant that I couldn't force every scheduling algorithm into exactly the same internal implementation.
Instead, I kept the implementations independent while giving them a consistent output structure.
That gave me a useful balance:
different algorithms internally, consistent results externally.
Validation Matters More Than It Looks
Since users can enter arbitrary values, validation is an important part of the application.
I'm using React Hook Form with Zod for form handling and validation.
Inputs such as arrival time, burst time, priority, and quantum have appropriate constraints. Duplicate process IDs are also rejected.
Random input generation is included as well.
Instead of manually creating a new set of processes every time, users can generate random inputs and immediately practice with them.
This fits the original reason I started building the project: generate a problem, solve it yourself, and verify the result.
Building the Interface Around the Algorithm
One thing I learned while building Process Mind is that an algorithm implementation and an educational interface are two different problems.
The algorithm knows what happened.
The UI needs to decide how that information should be understood by a human.
For CPU scheduling, I currently use a combination of:
- input forms
- result metrics
- process tables
- Gantt charts
- expandable execution steps
The Gantt chart gives a quick overview of execution, while the execution-step section exposes more detailed information when needed.
I deliberately kept the current visualization relatively simple. The larger goal is to eventually make Process Mind feel more like a simulation, but I don't want to add visual complexity just for the sake of having animations.
What I Learned
The biggest lesson from Process Mind wasn't about Next.js or TypeScript.
It was about designing data around the problem domain.
When building a normal CRUD application, the data model is often fairly obvious.
With algorithms, it isn't.
You have to decide what intermediate state matters, what information helps explain a decision, which metrics are useful, and how that information can be represented consistently across different algorithms.
I also learned that implementing an algorithm in code forces you to understand it differently.
Writing SRTF, for example, isn't the same as memorizing that "the process with the shortest remaining time executes." You have to think about arrivals, remaining time, preemption, completion, ties, queues, and every state transition.
That was one of the reasons I wanted to build Process Mind in the first place.
What's Next?
Process Mind is still evolving.
The current focus is making the existing algorithms reliable and useful for practice rather than continuously adding features.
The longer-term direction is to make the experience more simulation-oriented, with better visualization and interaction around algorithm execution.
But the core idea remains the same:
Practice the problem yourself. Run it through the algorithm. Verify your result. Understand where the execution came from.
That's what Process Mind is trying to become—a practical bridge between studying an algorithm and actually understanding how it executes.
Top comments (0)