Transcript Project 2 Tutorial

Preemptive Minithreads
Tom Roeder
CS415 2005sp
Multi-level Feedback Queues
Highest priority
Quantum = 2
Quantum = 4
Quantum = 8
Quantum = 16
Lowest priority
Borrowed from
414 notes
Multi-level Queues

Just like a regular queue, except



4 levels: can insert into any one
If a dequeue is requested and there’s no element
on this level, try the next. Return which level.
returns NULL and -1 if the are no elements



Note: errors inside the queues should cause an exit
We will use this data structure for scheduling
You will want to reuse your queue impl
Our Scheduling Algorithm

Feedback Queues:


4 levels with quantum doubling at each
demotion: if thread overruns its quantum



ie. thread has not yielded before preemption
will happen frequently for CPU-bound procs
promotion: by age



assign points upon queue entry
points accumulate over time
we add a promotion threshold
Algorithm Comparisons


Our alg: starvation elimination
Tries to get SRTF scheduling



current level: function of age and past CPU bursts
thus we are averaging CPU bursts over age
other options

no promotions



many jobs float to the bottom
very predictable
poor waiting time and latency
Algorithm Comparisons

other options (cont’d)

weighted levels




always work with all levels, but visit lower ones rarely
assign weights to each level: 50%, 25%, 15%, 10%
still no promotion, so all past history matters!
burst measurements for promotions

little real history


need to add a weighted averaging to be realistic
otherwise very unpredictable, jittery
Interrupts


On minithread_clock_init, you will
start receiving interrupts
Right now just clock interrupts, but a general
interrupt mechanism is present in the code


Happen on the current stack



Network packets will later cause interrupts
Control is wrenched from the current thread
Given to clock handler
Don’t waste time in the clock handler!
Clock Handler and Alarms

When you receive a clock tick:



Need a structure to keep track of alarms




Don’t use system functions (too slow)
Just count the ticks in a variable
Hint: you probably have already implemented one
A queue normally doesn’t provide fast search
This is OK, if you assume cancel infrequent
Your clock handler will need to run the alarms

alarm functions must be short and not block!
Low-level synchronization

Cannot block at interrupt time:


interrupts may interrupt our synch code
for short synchronization: disable interrupts
interrupt_level_t intlevel =
set_interrupt_level(DISABLED);
/* your code here */
set_interrupt_level(intlevel);

Don’t do this too much: hurts performance

will be penalized in grading
Warnings




Do not block while interrupts are disabled
Do not call system functions in a handler
Interrupts may be called in any context
Avoid disabling interrupts wherever possible



make any disabled period as short as possible
Beware of nested disable/enable blocks
Synchronize all global data!
How to get started

First implement and test the multi-level Q




dequeue should always return a value if possible
Then experiment with clock interrupts

slow them down (modify “interrupts.h”)

make sure a simple handler works
Add alarms
Change the scheduler



make sure round-robin works on a simple queue
add points and a multi-level queue
do demotion and promotion
Grading

Correctness



Efficiency




avoid race conditions (eg. in alarm code)
nested interrupt level changes
handlers must be fast
idle thread runs only when idle
don’t overdo interrupt disabling
Good software engineering

clean design, good comments
Questions?