CPU
↓
I/O
↓
CPU
↓
I/O
↓
CPU

Or the execution time of the program depends on user input

So it is not always possible to know in advance exactly how much CPU each job will need

This is where Scheduling becomes much more complex than a simple queue

9. Why is this important to us?

At first you might think what does this have to do with Reverse Engineering

But when a program has multiple threads, the actual execution of the program does not depend only on the order of the instructions in the binary

For example:

Thread A
↓
Running
↓
Preempted

Simultaneously:

Thread B
↓
Running
↓
Blocked

Then again:

Thread A
↓
Running

That is, the execution of the program can be switched between different threads

This becomes more important when we are dealing with things like:

Multi-threading

Race Condition

Deadlock

Timing Bug

Synchronization

For example, a bug may only occur when two threads reach a specific part of the program almost simultaneously

So we should not just ask:

What does this instruction do

We should ask:

When did this thread run? What thread ran before it? Why did this thread stop and then start again?

This view will be very important later for analyzing concurrency-related bugs

For now, learn these three metrics well:

Turnaround Time

Arrival → Completion

The total time the Job spent in the system from entry to completion

Waiting Time

The waiting time for CPU

How much time the Process spent in the Ready Queue waiting for the CPU

Response Time

Arrival → First Run

How long it took for the Process to get the CPU for the first time.

In summary:

Arrival
│
├─── Waiting ─────┐
│ │
▼ ▼
First Run Running
│ │
│ │
└── Response │
│
▼
Completion

Turnaround = Arrival → Completion

So when we want to compare two scheduling algorithms, we don't just say:

Which one is faster?

We need to see:

How long did we wait?

How fast did we get the first response?

How long did it take to complete the task?

These are the metrics that help us understand how well a Scheduler really performs

@reverseengine