1. Preemptive Minithreads Tom Roeder CS415 2005sp

2. Multi-level Feedback Queues Quantum = 2 Quantum = 4 Quantum = 8 Quantum = 16 Lowest priority Highest priority Borrowed from 414 notes

3. 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

4. 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

5. 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

6. 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

7. 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  Network packets will later cause interrupts Happen on the current stack  Control is wrenched from the current thread  Given to clock handler Don’t waste time in the clock handler!

8. Clock Handler and Alarms When you receive a clock tick:  Don’t use system functions (too slow)  Just count the ticks in a variable Need a structure to keep track of alarms  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!

9. 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

10. 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!

11. 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

12. Grading Correctness  avoid race conditions (eg. in alarm code)  nested interrupt level changes Efficiency  handlers must be fast  idle thread runs only when idle  don’t overdo interrupt disabling Good software engineering  clean design, good comments

13. Questions?