Operating Systems

Start Lecture #5

Round Robbin (RR, RR, RR, RR)

• An important preemptive policy.
• Essentially the preemptive version of FCFS.
• The key parameter is the quantum size q.
• When a process is put into the running state a timer is set to q.
• If the timer goes off and the process is still running, the OS preempts the process.
  • This process is moved to the ready state (the preempt arc in the diagram), where it is placed at the rear of the ready list.
  • The process at the front of the ready list is removed from the ready list and run (i.e., moves to state running).
  • Note that the ready list is being treated as a queue. Indeed it is sometimes called the ready queue, but not by me since for other scheduling algorithms it is not accessed in a FIFO manner.
• When a process is created, it is placed at the rear of the ready list.
• Note that RR works well if you have a 1 hr job and then a 3 second job.
• As q gets large, RR approaches FCFS. Indeed if q is larger that the longest time any process will run before terminating or blocking, then RR IS FCFS. A good way to see this is to look at my favorite diagram and note the three arcs leaving running. They are triggered by three conditions: process terminating, process blocking, and process preempted. If the first trigger condition to arise is never preemption, we can erase that arc and then RR becomes FCFS.
• As q gets small, RR approaches PS (Processor Sharing, described next).
• What value of q should we choose?
  • A trade-off
  • A small q makes the system more responsive, a long compute-bound job cannot starve a short job.
  • A large q makes the system more efficient since there is less process switching.
  • A reasonable time for q is a few tens of milliseconds or perhaps a few milliseconds for a fast processor. (millisecond = 1/1000 second and is abbreviated ms). This means every other job can delay your job by at most q (plus the context switch time CS, which is normally less than 1ms). Also the overhead is CS/(CS+q), which is small.
• A student found the following reference for the name Round Robin. A similar, but less detailed, citation can be found in wikipedia.

  The round robin was originally a petition, its signatures arranged in a circular form to disguise the order of signing. Most probably it takes its name from the ruban rond, (round ribbon), in 17th-century France, where government officials devised a method of signing their petitions of grievances on ribbons that were attached to the documents in a circular form. In that way no signer could be accused of signing the document first and risk having his head chopped off for instigating trouble. Ruban rond later became round robin in English and the custom continued in the British navy, where petitions of grievances were signed as if the signatures were spokes of a wheel radiating from its hub. Today round robin usually means a sports tournament where all of the contestants play each other at least once and losing a match doesn't result in immediate elimination.
  
  Encyclopedia of Word and Phrase Origins by Robert Hendrickson (Facts on File, New York, 1997).

Homework: 20, 35.

Homework: Round-robin schedulers normally maintain a list of all runnable processes, with each process occurring exactly once in the list. What would happen if a process occurred more than once in the list? Can you think of any reason for allowing this?

Homework: Give an argument favoring a large quantum; give an argument favoring a small quantum.

Process	CPU Time	Creation Time
P1	20	0
P2	3	3
P3	2	5

Homework:

• Consider the set of processes in the table to the right.
• When does each process finish if RR scheduling is used with q=1, if q=2, if q=3, if q=100?
• First assume (unrealistically) that context switch time is zero.
• Then assume it is .1. Each process performs no I/O (i.e., no process ever blocks).
• All times are in milliseconds.
• The CPU time is the total time required for the process (excluding any context switch time).
• The creation time is the time when the process is created. So P1 is created when the problem begins and P3 is created 5 milliseconds later.
• If two processes have equal priority (in RR this means if they both enter the ready state at the same cycle), we give priority (in RR this means place first on the queue) to the process with the earliest creation time. If they also have the same creation time, then we give priority to the process with the lower number.
• Remind me to discuss this last one in class next time.

Homework: Redo the previous homework for q=2 with the following changes. After process P1 runs for 3ms (milliseconds), it blocks for 2ms. P1 never blocks again. P2 never blocks. After P3 runs for 1 ms it blocks for 1ms. Assume the context switch time is zero. Remind me to answer this one in class next lecture.

Processor Sharing (PS, **, PS, PS)

Merge the ready and running states and permit all ready jobs to be run at once. However, the processor slows down so that when n jobs are running at once, each progresses at a speed 1/n as fast as it would if it were running alone.

• Clearly impossible as stated due to the overhead of process switching.
• Of theoretical interest (easy to analyze).
• Approximated by RR when the quantum is small. Make sure you understand this last point. For example, consider the last homework assignment (with zero context switch time and no blocking) and consider q=1, q=.1, q=.01, etc.
• Show what happens for 3 processes, A, B, C, each requiring 3 seconds of CPU time. A starts at time 0, B at 1 second, C at 2.
• Consider three processes all starting at time 0. One requires 1ms, the second 100ms, the third 10sec (seconds). Compute the total/average waiting time for RR q=1ms, PS, SJF, SRTN, and FCFS. Note that this depends on the order the processes happen to be processed in. The effect is huge for FCFS, modest for RR with modest quantum, and non-existent for PS and SRTN.

Homework: 32.

Variants of Round Robin

1. State dependent RR
   • Same as RR but q is varied dynamically depending on the state of the system.
   • Favor processes holding important resources, for example, non-swappable memory.
   • Perhaps this should be considered medium term scheduling since you probably do not recalculate q each time.
2. External priorities: RR but a user can pay more and get bigger q. That is, one process can be given a higher priority than another. But this is not an absolute priority: the lower priority (i.e., less important) process does get to run, but not as much as the higher priority process.

Priority Scheduling

Each job is assigned a priority (externally, perhaps by charging more for higher priority) and the highest priority ready job is run.

• Similar to External priorities above
• If many processes have the highest priority, use RR among them. Indeed one often groups several priorities into a priority class and employs RR within a class.
• Can easily starve processes, which can be fixed by the standard technique.
• Can have the priorities changed dynamically to favor processes holding important resources (similar to state dependent RR).
• Sometimes a large priority means an important job; sometimes a small priority means an important job.
• Many policies can be thought of as priority scheduling in which we run the job with the highest priority. The different scheduling policies have different notions of priority. For example:
  • FCFS and RR are priority scheduling where the priority is the time last inserted on the ready list.
  • SJF and SRTN are priority scheduling, where the priority of the job is the time it needs to run in order to complete (or complete its current CPU burst).

Priority aging

As a job is waiting, increase its priority; hence it will eventually have the highest priority.

• Starvation means that some process is never run, because it never has the highest priority. It is also called starvation, if process runs for a while, but then is never able to run again, even though it is ready. The formal way to say this is that a system is free of starvation if, No job can remain in the ready state forever.
• Priority aging is the standard technique used to prevent starvation (assuming all jobs terminate or the policy is preemptive).
• There may be many processes with the maximum priority.
• If so, can use FIFO among those with max priority (risks starvation if a job doesn't terminate) or can use RR.
• Can apply priority aging to many policies, in particular to priority scheduling described above.

Homework: 36, 37. Note that when the book says RR with each process getting its fair share, it means Processor Sharing.

Selfish RR (SRR, **, SRR, **)

SRR is a preemptive policy in which unblocked (i.e. ready and running) processes are divided into two classes the Accepted processes, which run RR and the others (perhaps SRR really stands for snobbish RR).

• Accepted process have their priority increase at rate a≥0.
• A new process starts at priority 0; its priority increases at rate b≥0.
• An unaccepted process becomes an accepted process when its priority reaches that of the accepted processes (or when there are no accepted processes).
• Hence, once a process is accepted, it remains accepted until it terminates (or blocks, see below) and all accepted processes have same priority.
• Note that, when the only accepted process terminates (or blocks, see below), all the process with the next highest priority become accepted.

The behavior of SRR depends on the relationship between a and b (and zero).

• If a=0, get RR.
• If a≥b>0, get FCFS.
• If b>a>0, it is interesting.
• If a>b=0, you get RR in batches. This is similar to n-step scan for disk I/O.

It is not clear what is supposed to happen when a process blocks. Should its priority get reset to zero and have unblock act like create? Should the priority continue to grow (at rate a or b)? Should its priority be frozen during the blockage. Let us assume the first case (reset to zero) since it seems the simplest.

Approximating the Behavior of SFJ and PSJF

Recall that SFJ/PSFJ do a good job of minimizing the average waiting time. The problem with them is the difficulty in finding the job whose next CPU burst is minimal. We now learn three scheduling algorithms that attempt to do this. The first algorithm does it statically, presumably with some manual help; the other two are dynamic and fully automatic.

Multilevel Queues (**, **, MLQ, **)

Put different classes of processs in different queues

• Processes do not move from one queue to another.
• Can have different policies on the different queues.
  For example, might have a background (batch) queue that is FCFS and one or more foreground queues that are RR (possibly with different quanta).
• Must also have a policy among the queues.
  For example, might have two queues, foreground and background, and give the first absolute priority over the second
  • Might apply priority aging to prevent background starvation.
  • But might not, i.e., no guarantee of service for background processes. View a background process as a cycle soaker.
  • Might have 3 queues, foreground, background, cycle soaker.
• Another possible inter-queue policy would be have 2 queues, apply RR to each but cycle through the higher priority twice and then cycle through the lower priority queue once.

Multiple Queues (FB, MFQ, MLFBQ, MQ)

As with multilevel queues above we have many queues, but now processes move from queue to queue in an attempt to dynamically separate batch-like from interactive processs so that we can favor the latter.

• Remember that low average waiting time is achieved by SJF and this is an attempt to determine dynamically those processes that are interactive, which means have a very short cpu burst.
• Run processs from the highest priority nonempty queue in a RR manner.
• When a process uses its full quanta (looks a like batch process), move it to a lower priority queue.
• When a process doesn't use a full quanta (looks like an interactive process), move it to a higher priority queue.
• A long process with frequent (perhaps spurious) I/O will remain in the upper queues.
• Might have the bottom queue FCFS.
• Many variants.
  For example, might let process stay in top queue 1 quantum, next queue 2 quanta, next queue 4 quanta (i.e., sometimes return a process to the rear of the same queue it was in if the quantum expires).
  Might move to a higher queue only if a keyboard interrupt occurred rather than if the quantum failed to expire for any reason (e.g., disk I/O).

Shortest Process Next

An attempt to apply sjf to interactive scheduling. What is needed is an estimate of how long the process will run until it blocks again. One method is to choose some initial estimate when the process starts and then, whenever the process blocks choose a new estimate via

    NewEstimate = A*OldEstimate + (1-A)*LastBurst
  

Highest Penalty Ratio Next (HPRN, HRN, **, **)

Run the process that has been hurt the most.

• For each process, let r = T/t; where T is the wall clock time this process has been in system and t is the running time of the process to date.
• If r=2.5, that means the job has been running 1/2.5 = 40% of the time it has been in the system.
• We call r the penalty ratio and run the process having the highest r value.
• We must worry about a process that just enters the system since t=0 and hence the ratio is undefined. Define t to be the max of 1 and the running time to date. Since now t is at least 1, the ratio is always defined.
• HPRN is normally defined to be non-preemptive (i.e., the system only checks r when a burst ends), but there is an preemptive analogue
  • When putting a process into the run state compute the time at which it will no longer have the highest ratio and set a timer.
  • When a process is moved into the ready state, compute its ratio and preempt if needed.
• HRN stands for highest response ratio next and means the same thing.
• This policy is yet another example of priority scheduling

Guaranteed Scheduling

A variation on HPRN. The penalty ratio is a little different. It is nearly the reciprocal of the above, namely
   t / (T/n)
where n is the multiprogramming level. So if n is constant, this ratio is a constant times 1/r.

Lottery Scheduling

Each process gets a fixed number of tickets and at each scheduling event a random ticket is drawn (with replacement) and the process holding that ticket runs for the next interval (probably a RR-like quantum q).

On the average a process with P percent of the tickets will get P percent of the CPU (assuming no blocking, i.e., full quanta).

Fair-Share Scheduling

If you treat processes fairly you may not be treating users fairly since users with many processes will get more service than users with few processes. The scheduler can group processes by user and only give one of a user's processes a time slice before moving to another user.

Fancier methods have been implemented that give some fairness to groups of users. Say one group paid 30% of the cost of the computer. That group would be entitled to 30% of the cpu cycles providing it had at least one process active. Furthermore a group earns some credit when it has no processes active.

Theoretical Issues

Considerable theory has been developed.

• NP completeness results abound.
• Much work in queuing theory to predict performance.
• Not covered in this course.

Medium-Term Scheduling

In addition to the short-term scheduling we have discussed, we add medium-term scheduling in which decisions are made at a coarser time scale.

Recall my favorite diagram, shown again on the right. Medium term scheduling determines the transitions from the top triangle to the bottom line. We suspend (swap out) some process if memory is over-committed dropping the (ready or blocked) process down. We also need resume transitions to return a process to the top triangle.

Criteria for choosing a victim to suspend include:

• How long since previously suspended.
• How much CPU time used recently.
• How much memory does it use.
• External priority (pay more, get swapped out less).

We will discuss medium term scheduling again when we study memory management.

Long Term Scheduling

This is sometimes called Job scheduling.

1. The system decides when to start jobs, i.e., it does not necessarily start them when submitted.
2. Used at many supercomputer sites.

A similar idea (but more drastic and not always so well coordinated) is to force some users to log out, kill processes, and/or block logins if over-committed.

• CTSS (an early time sharing system at MIT) did this to insure decent interactive response time.
• Unix does this if out of memory.
• LEM jobs during the day (Grumman).

Review Homework Assigned Last Time

Lab 2 (Scheduling) Discussion

Show the detailed output

1. In FCFS see the affect of A, B, C, and I/O
2. In RR see how the cpu burst is limited.
3. Note the intital sorting to ease finding the tie breaking process.
4. Note show random.
5. Comment on how to do it: (time-based) discrete-event simulation (DES).
   1. DoBlockedProcesses()
   2. DoRunningProcesses()
   3. DoCreatedProcesses()
   4. DoReadyProcesses()
6. For processor sharing need event-based DES.

2.3 Interprocess Communication (IPC) and Coordination/Synchronization

2.3.1 Race Conditions

A race condition occurs when two (or more) processes are about to perform some action. Depending on the exact timing, one or other goes first. If one of the processes goes first, everything works correctly, but if another one goes first, an error, possibly fatal, occurs.

Imagine two processes both accessing x, which is initially 10.

A1: LOAD  r1,x     B1: LOAD  r2,x
A2: ADD   r1,1     B2: SUB   r2,1
A3: STORE r1,x     B3: STORE r2,x

• One process is to execute x := x+1
• The other is to execute x := x-1
• When both are finished x should be 10
• But x := x+1 is not atomic; see the code on the right
• Show in class how we can get 9 or 11!
• Tanenbaum shows how this can lead to disaster for a printer spooler

2.3.2 Critical Regions (Sections)

We must prevent interleaving sections of code that need to be atomic with respect to each other. That is, the conflicting sections need mutual exclusion. If process A is executing its critical section, it excludes process B from executing its critical section. Conversely if process B is executing is critical section, it excludes process A from executing its critical section.

Requirements for a critical section implementation.

1. No two processes may be simultaneously inside their critical section.
   
   
2. No assumption may be made about the speeds or the number of concurrent threads/processes.
   
   
3. No process outside its critical section (including the entry and exit code) may block other processes.
   
   
4. No process should have to wait forever to enter its critical section.
   • I do NOT make this last requirement.
   • I just require that the system as a whole make progress (so not all processes are blocked).
   • I refer to solutions that do not satisfy Tanenbaum's last condition as unfair, but nonetheless correct, solutions.
   • Stronger fairness conditions have also been defined.

2.3.3 Mutual exclusion with busy waiting

We will study only solutions in this class. Note that higher level solutions, e.g., having one process block when it cannot enter its critical are implemented using busy waiting algorithms.

Disabling Interrupts

The operating system can choose not to preempt itself. That is, we could choose not to preempt system processes (if the OS is client server) or processes running in system mode (if the OS is self service). Forbidding preemption for system processes would prevent the problem above where x<--x+1 not being atomic crashed the printer spooler if the spooler is part of the OS.

The way to prevent preemption of kernel-mode code is to disable interrupts. Indeed, disabling (i.e., temporarily preventing) interrupts is often done for exactly this reason.

This is not, however, sufficient for all cases.

• It does not work for user-mode programs. So the Unix print spooler, which is a user-mode program would need another solution.
• We do not want to block interrupts for too long or the system will seem unresponsive.
• Disabling interrupts is insufficient if the system has several processors.
  • The main line can be executing on both processors simultaneously so interrupts are not involved.
  • One processor cannot block interrupts on the other.

Software solutions for two processes

Lock Variables

  Initially P1wants=P2wants=false

  Code for P1                             Code for P2

  Loop forever {                          Loop forever {
     P1wants <-- true         ENTRY          P2wants <-- true
     while (P2wants) {}       ENTRY          while (P1wants) {}
     critical-section                        critical-section
     P1wants <-- false        EXIT           P2wants <-- false
     non-critical-section }                  non-critical-section }

Explain why this works.

But it is wrong!
Why?

Let's try again. The trouble was that setting want before the loop permitted us to get stuck. We had them in the wrong order!

    Initially P1wants=P2wants=false

    Code for P1                             Code for P2

    Loop forever {                          Loop forever {
       while (P2wants) {}       ENTRY          while (P1wants) {}
       P1wants <-- true         ENTRY          P2wants <-- true
       critical-section                        critical-section
       P1wants <-- false        EXIT           P2wants <-- false
       non-critical-section }                  non-critical-section }
  

Explain why this works.

But it is wrong again!
Why?

Strict Alternation

Now let's try being polite and really take turns. None of this wanting stuff.

    Initially turn=1

    Code for P1                      Code for P2

    Loop forever {                   Loop forever {
       while (turn = 2) {}              while (turn = 1) {}
       critical-section                 critical-section
       turn <-- 2                       turn <-- 1
       non-critical-section }           non-critical-section }
  

This one forces alternation, so is not general enough. Specifically, it does not satisfy condition three, which requires that no process in its non-critical section can stop another process from entering its critical section. With alternation, if one process is in its non-critical section (NCS) then the other can enter the CS once but not again.

The first example violated rule 4 (the whole system blocked). The second example violated rule 1 (both in the critical section. The third example violated rule 3 (one process in the NCS stopped another from entering its CS).

In fact, it took years (way back when) to find a correct solution. Many earlier solutions were found and several were published, but all were wrong. The first correct solution was found by a mathematician named Dekker, who combined the ideas of turn and wants. The basic idea is that you take turns when there is contention, but when there is no contention, the requesting process can enter. It is very clever, but I am skipping it (I cover it when I teach distributed operating systems in V22.0480 or G22.2251). Subsequently, algorithms with better fairness properties were found (e.g., no task has to wait for another task to enter the CS twice).

What follows is Peterson's solution, which also combines wants and turn to force alternation only when there is contention. When Peterson's algorithm was published, it was a surprise to see such a simple solution. In fact Peterson gave a solution for any number of processes. A proof that the algorithm satisfies our properties (including a strong fairness condition) for any number of processes can be found in Operating Systems Review Jan 1990, pp. 18-22.

    Initially P1wants=P2wants=false  and  turn=1

    Code for P1                        Code for P2

    Loop forever {                     Loop forever {
       P1wants <-- true                   P2wants <-- true
       turn <-- 2                         turn <-- 1
       while (P2wants and turn=2) {}      while (P1wants and turn=1) {}
       critical-section                   critical-section
       P1wants <-- false                  P2wants <-- false
       non-critical-section }             non-critical-section }
  

The TSL Instruction (Hardware Assist test-and-set)

Tanenbaum calls this instruction test and set lock TSL.

I call it test and set (TAS) and define
TAS(b), where b is a binary variable,
to ATOMICALLY set b←true and return the OLD value of b.

Of course it would be silly to return the new value of b since we know the new value is true.

The word atomically means that the two actions performed by TAS(x), testing (i.e., returning the old value of x) and setting (i.e., assigning true to x) are inseparable. Specifically it is not possible for two concurrent TAS(x) operations to both return false (unless there is also another concurrent statement that sets x to false).

With TAS available implementing a critical section for any number of processes is trivial.

    loop forever {
        while (TAS(s)) {}  ENTRY
        CS
        s<--false          EXIT
        NCS }