0% found this document useful (0 votes)
2 views11 pages

CPU Scheduling: Preemptive Priority Explained

Uploaded by

waniatoor16
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views11 pages

CPU Scheduling: Preemptive Priority Explained

Uploaded by

waniatoor16
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Perfect — yes, you’re absolutely right �

Let’s now redo the full question properly, step by step — this time strictly following the
scheduling rules:

✅Preemptive Priority Scheduling (smaller number = higher priority)


✅Aging: if a process waits 5 time units, its priority decreases by 1 (i.e., becomes higher).
✅Context switch: +1 unit each time CPU switches processes.
✅Compare priorities on every arrival and after every aging adjustment.

�Given Data

Process Arrival Burst Initial Priority


P1 0 8 3
P2 2 4 2
P3 4 9 5
P4 6 5 4

�Step 1: Start at time 0

At t = 0, only P1 has arrived → it starts execution.

Running: P1
Ready queue: —
Gantt: starts P1

�Step 2: At time = 2 → P2 arrives

Now:

 P1 (running, priority 3)
 P2 (new, priority 2 → higher priority)

✅Since P2’s priority is smaller (2 < 3), P2 preempts P1.

Add context switch = 1 unit (from 2–3).

Gantt so far:
0–2 : P1
2–3 : CS
3–7 : P2 (it runs fully, since burst = 4)

At t=7: P2 finishes. ✅

�Step 3: What happens during P2’s execution (t=3–7)

 P1 was waiting from t=2–7 → waiting = 5 units


→ Aging: P1’s priority = 3 → 2 (higher)
 New arrivals:
o P3 arrived at t=4 (priority 5)
o P4 arrived at t=6 (priority 4)

So at t=7, ready queue:

 P1 (burst left = 6, priority now 2)


 P3 (burst = 9, priority 5)
 P4 (burst = 5, priority 4)

Highest priority = P1 (2)

�Step 4: At time 7 → switch to P1

Context switch = 7–8


Then P1 runs.

Gantt:
7–8 : CS
8– ? : P1 runs

We must check if anyone with a higher priority arrives (none, all have arrived).
But we also apply aging every 5 waiting units.

�Step 5: Track waiting times and aging while P1 runs

Let’s see how long P1 runs before any waiting process crosses 5 units of waiting.

At start (t=8):

 P3 waiting since 4 → waiting = 4 units


 P4 waiting since 6 → waiting = 2 units

At t=9, P3 waiting = 5 → ages: priority 5 → 4


At t=11, P4 waiting = 5 → ages: priority 4 → 3

Now ready queue priorities:

 P3: 4
 P4: 3
 P1 (running): 2

No process has priority < 2, so P1 keeps running.

P1 finishes at t = 8 + 6 = 14.

�Step 6: At t = 14 → P1 finishes �

Now processes left:

 P3 (priority 4)
 P4 (priority 3)

So P4 (priority 3) is next.

Add context switch: 14–15


Then run P4 from 15–20 (burst 5).

P4 finishes at t=20 ✅

�Step 7: Remaining process P3

Only P3 left (priority 4).

Add context switch: 20–21


Run P3 from 21–30 (burst 9)

P3 finishes at t=30 ✅

�Gantt Chart
0 – 2 : P1
2 – 3 : CS
3 – 7 : P2
7 – 8 : CS
8 – 14 : P1
14 –15 : CS
15 –20 : P4
20 –21 : CS
21 –30 : P3

�Completion, Turnaround, Waiting, Response

Turnaround (CT– Waiting (TAT– Response (first


Process Arrival Burst Completion
AT) BT) start–AT)
P1 0 8 14 14 6 0
P2 2 4 7 5 1 1
P3 4 9 30 26 17 17
P4 6 5 20 14 9 9

�Average Values

 Average Turnaround Time = (14 + 5 + 26 + 14) / 4 = 14.75


 Average Waiting Time = (6 + 1 + 17 + 9) / 4 = 8.25
 Average Response Time = (0 + 1 + 17 + 9) / 4 = 6.75

�Priority Changes (due to aging)

Process Original After Aging Time of Change


P1 3 → 2 After waiting 5 units (t=2–7)
P3 5→4 t=9
P4 4 → 3 t = 11

�Summary

 Aging helped P1 get priority 2 again after waiting 5 units.


 P2 had the highest priority initially, so it ran early.
 P3 and P4 aged later, but P1 still finished before them.
 Context switching added small overheads (4 total).
 Final Gantt order: P1 → P2 → P1 → P4 → P3
 Aging prevented starvation (P3 eventually ran).
Would you like me to draw the Gantt chart visually (colored) with arrows showing priority
changes over time? It’ll make it easy to include in your assignment.

Perfect ��— these are all classic CPU scheduling questions that test your deep understanding
of how scheduling works in operating systems.

I’ll explain each question (Q7–Q13) in super easy English — step-by-step, with examples and
comparisons — so you can write them in exams confidently and also actually understand
what’s happening behind the scenes.

�Q7. How Multilevel Queue (MLQ) and Multilevel Feedback Queue (MLFQ)
scheduling differ in efficiency?

�1�⃣ First, understand what they are:

Multilevel Queue (MLQ):

 Ready queue is divided into separate queues, each for a type of process.
e.g.:
o Queue 1: System (high priority)
o Queue 2: Interactive (medium)
o Queue 3: Batch (low)

Each queue has its own scheduling algorithm (e.g., Round Robin for interactive, FCFS for
batch).

BUT:
Processes are fixed in their queues — they don’t move.

Multilevel Feedback Queue (MLFQ):


 Similar structure (multiple queues)
but processes can move between queues based on their behavior.
 If a process uses too much CPU time → moved to a lower-priority queue.
 If a process waits too long → moved up (aging).

✅This gives feedback — the system ―learns‖ how CPU- or I/O-bound a process is.

�Difference in Efficiency

Feature MLQ MLFQ

Movement between queues ✅Fixed ✅Dynamic (feedback)

Flexibility Low High

CPU utilization May be poor (some queues idle) Better (processes move where needed)

Starvation Possible Less likely (due to aging & movement)

Example Fixed queues for system/user jobs Windows & Linux use MLFQ-type

�In simple words:

MLFQ is more efficient because it adapts to process behavior and reduces waiting/starvation.
MLQ is simpler but less flexible.

�Q8. Why can Round Robin cause poor performance if quantum is too small
or too large?

�Quick recall:

Round Robin (RR) → each process gets CPU for a fixed time quantum.

Case Effect

Quantum too Too many context switches → CPU spends more time switching than working →
small overhead ↑, performance ↓
Case Effect

Quantum too
Processes wait too long → system behaves like FCFS → poor responsiveness
large

✅Ideal: Quantum should be large enough to minimize context switches but small enough to
keep system responsive.

✅Example:
If each switch takes 1 ms and quantum = 2 ms, half the time is wasted switching!

�Q9. Explain Starvation and how Aging helps prevent it in Priority


Scheduling.

�What is Starvation?

Starvation = when a process waits forever because it never gets CPU time.

✅Example:

 High priority processes keep arriving.


 A low-priority process never runs.

→ That low-priority process starves.

�What is Aging?

Aging = gradually increasing the priority of a process that has been waiting for a long time.

✅Example:

 A process starts with priority 5.


 After waiting 10 seconds, its priority becomes 4, then 3, etc.
 Eventually it becomes high enough to run.

✅Prevents starvation because no process waits forever — everyone gets a turn.

✍�In short:
Starvation happens when low-priority processes never execute.
Aging increases their priority over time, ensuring fairness.

�Q10. How do user-level threads differ from kernel-level threads in


performance?

�Difference between them:

Feature User-Level Threads (ULT) Kernel-Level Threads (KLT)

Managed by User library (not OS) OS kernel

Context
Fast (no kernel involvement) Slower (needs system call)
switch

If one thread blocks → all block (because kernel sees


Blocking Only that thread blocks
one process)

POSIX threads (pthreads), Windows


Example Java Green Threads
threads

�Performance Difference

 ULT: Faster creation, switching, and management (no system calls).


✅But poor concurrency — if one thread waits (e.g., for I/O), all are blocked.
 KLT: Slower to create and switch (kernel overhead).
✅But true parallelism — OS can schedule different threads on different CPUs.

✅ In summary:

ULT = fast but limited concurrency.


KLT = slower but better CPU utilization and true parallelism.

�Q11. Which scheduling algorithm is suitable for:


System Type Suitable Algorithm Justification

a) Real-time Priority Scheduling Real-time tasks have strict deadlines; higher-priority


System Type Suitable Algorithm Justification

systems (Preemptive) (urgent) tasks must run immediately.

b) Interactive Fair CPU sharing between users; fast response time for
Round Robin (RR)
systems interactive tasks.

No user interaction; aim is to maximize throughput (finish


c) Batch systems FCFS or SJF
jobs quickly).

✅Example:

 Real-time: Airbag control system


 Interactive: Operating system terminal
 Batch: Payroll processing at night

�Q12. How do user-level threads map to kernel threads in each model?

There are 3 main models for mapping threads:

Model Mapping Description Example

Many-to- Many user threads → One


Fast, but if one blocks, all block Old Java green threads
One kernel thread

Each user thread → One kernel True parallelism, but high Windows, Linux
One-to-One
thread overhead (pthreads)

Many-to- Many user threads → Many Balance between flexibility & Windows ThreadPool,
Many kernel threads performance Solaris

✅ In short:

Many-to-One = fast but limited


One-to-One = slow but powerful
Many-to-Many = best balance
�Q13. Why is Round Robin suitable for time-sharing systems?

�Time-sharing systems:

Designed so that multiple users feel their programs run simultaneously (like multitasking).

�Why RR works well:

 Each process gets equal time quantum → fairness.


 Processes run in turns, so all users see regular CPU response.
 Preemptive → CPU switches between processes automatically.
 Responsive even when many users are active.

✅Example:
If there are 5 users, each gets 20% of CPU time per cycle. Everyone sees progress → no one
―feels‖ ignored.

✅So:

Round Robin ensures fairness and quick response, which is ideal for time-sharing systems where
multiple users share the CPU.

�Summary Table (for revision)


Q# Concept Key Idea

Q7 MLQ vs MLFQ MLFQ allows movement between queues → more efficient

Q8 Round Robin Quantum Too small → overhead ↑; Too large → poor response

Q9 Starvation & Aging Aging raises waiting process’s priority

Q10 User vs Kernel Threads ULT = faster, KLT = better concurrency

Q11 Suitable Algorithms Real-time → Priority; Interactive → RR; Batch → FCFS/SJF

Q12 Thread Mapping Many-1, 1-1, Many-Many

Q13 RR in Time-Sharing Fairness + responsiveness for all users


Would you like me to make this into a one-page visual summary sheet (like a colorful exam
cheat sheet with boxes and arrows)? It’s great for last-minute revision.

Scheduling Main Method / Strategy


Type Preemption Key Idea / Example
Algorithm Used
Simple ―first in, first
FCFS (First
Non- CPU given to process that out‖; e.g., P1 → P2
Come First ✅
preemptive arrives first (like a queue) → P3 in order of
Serve)
arrival
Choose shortest CPU
SJF (Shortest Non- Process with the smallest
✅ burst next; can cause
Job First) preemptive burst time runs first
starvation of long jobs
SRTF (Shortest Process with least
New short job can
Remaining Preemptive remaining CPU time ✅
preempt longer one
Time First) always runs
Both (can be CPU given to process with If two have same
Priority
preemptive or highest priority (smallest ✅/ ✅ priority → FCFS tie-
Scheduling
not) number) breaker
Each process runs for a
Round Robin Fair sharing; used in
Preemptive fixed time quantum in a ✅
(RR) time-sharing systems
cycle
Processes divided into
Multilevel multiple queues (e.g., No movement
Both ✅/ ✅
Queue (MLQ) system, user); each queue between queues
has its own algorithm
Prevents starvation by
Multilevel Similar to MLQ but
moving long-waiting
Feedback Preemptive allows movement between ✅
processes to higher
Queue (MLFQ) queues (aging built-in)
queues
Priority Priority increases (number Prevents starvation by
Scheduling with Preemptive decreases) as a process ✅ dynamic priority
Aging waits longer change

You might also like