Processes and Threads

1
Processes and Threads

• Chapter 2

2.1 Processes 2.2 Threads 2.3 Interprocess
communication 2.4 Classical IPC problems 2.5
Scheduling
2
ProcessesThe Process Model

• In the process model, all runnable software is
  organized as a collection of processes.

• Multiprogramming of four programs
• Conceptual model of 4 independent, sequential
  processes
• Only one program active at any instant

3
Process Creation

• Principal events that cause process creation
• System initialization
• Execution of a process creation system
• User request to create a new process
• Initiation of a batch job
• Foreground processes are those that interact with
  users and perform work for them.
• Background processes that handle some incoming
  request are called daemons.

4
Process Creation

• How to list the running processes?
• In UNIX, use the ps command.
• In Windows 95/98/Me, use Ctrl-Alt-Del.
• In Windows NT/2000/XP, use the task manager.
• In UNIX, a fork() system call is used to create a
  new process.
• Initially, the parent and the child have the same
  memory image, the same environment strings, and
  the same open files.
• The execve() system call can be used to load a
  new program.
• But the parent and child have their own distinct
  address space.
• In Windows, CreateProcess handles both creation
  and loading the correct program into the new
  process.

5
Process Termination

• Conditions which terminate processes
• Normal exit (voluntary)
• Exit in UNIX and ExitProcess in Windows.
• Error exit (voluntary)
• Example Compiling errors.
• Fatal error (involuntary)
• Example Core dump
• Killed by another process (involuntary)
• Kill in UNIX and TerminateProcess in Windows.

6
Process Hierarchies

• Parent creates a child process, child processes
  can create its own process
• Forms a hierarchy
• UNIX calls this a "process group
• In UNIX, init ? sshd ? sh ? ps
• Windows has no concept of process hierarchy
• all processes are created equal

7
Process Model - Example

• In UNIX, for example, a fork() system call is
  used to create child processes in such a
  hierarchy. A good example is a shell.
• Consider the menu-driven shell given in
  programs/c/Ex3.c.

8
Process Model - Example

• The algorithm (Ex3.c) is
• Display the menu and obtain the user's request
  (1ls,2ps,3exit).
• If the user wants to exit, then terminate the
  shell process.
• Otherwise
• Fork off a child process.
• The child process executes the option selected,
  while the parent waits for the child to complete.
• The child exits.
• The parent goes back to step 1.

9
Process States (1)

• Possible process states
• Running - using the CPU.
• Ready - runnable (in the ready queue).
• Blocked - unable to run until an external event
  occurs e.g., waiting for a key to be pressed.
• Transitions between states shown

10
Process States (2)

• Lowest layer of process-structured OS
• handles interrupts, scheduling
• Above that layer are sequential processes
• User processes, disk processes, terminal processes

11
Implementation of Processes

• The operating system maintains a process table
  with one entry (called a process control block
  (PCB)) for each process.
• When a context switch occurs between processes P1
  and P2, the current state of the RUNNING process,
  say P1, is saved in the PCB for process P1 and
  the state of a READY process, say P2, is restored
  from the PCB for process P2 to the CPU registers,
  etc. Then, process P2 begins RUNNING.
• Note This rapid switching between processes
  gives the illusion of true parallelism and is
  called pseudo- parallelism.

12
Implementation of Processes (1)

• Fields of a process table entry

13
Implementation of Processes (2)

• Skeleton of what lowest level of OS does when an
  interrupt occurs

14
Thread vs. Process

• A thread lightweight process (LWP) is a basic
  unit of CPU utilization.
• It comprises a thread ID, a program counter, a
  register set, and a stack.
• A traditional (heavyweight) process has a single
  thread of control.
• If the process has multiple threads of control,
  it can do more than one task at a time. This
  situation is called multithreading.

15
Single and Multithreaded Processes
16
ThreadsThe Thread Model (1)

• (a) Three processes each with one thread
• (b) One process with three threads

17
The Thread Model (2)

• Items shared by all threads in a process
• Items private to each thread

18
The Thread Model (3)

• Each thread has its own stack

19
Thread Usage

• Why do you use threads?
• Responsiveness Multiple activities can be done
  at same time. They can speed up the application.
• Resource Sharing Threads share the memory and
  the resources of the process to which they
  belong.
• Economy They are easy to create and destroy.
• Utilization of MP (multiprocessor) Architectures
  They are useful on multiple CUP systems.
• Example - Word Processor, Spreadsheet
• One thread interacts with the user.
• One formats the document (spreadsheet).
• One writes the file to disk periodically.

20
Thread Usage (1)

• A word processor with three threads

21
Thread Usage

• Example Web server
• One thread, the dispatcher, distributes the
  requests to a worker thread.
• A worker thread handles the requests.
• Example data processing
• An input thread
• A processing thread
• An output thread

22
Thread Usage (2)

• A multithreaded Web server

23
Thread Usage (3)

• Rough outline of code for previous slide
• (a) Dispatcher thread
• (b) Worker thread

24
Thread Usage (4)

• Three ways to construct a server

25
User Threads

• Thread management done by user-level threads
  library
• User-level threads are fast to create and manage.
• Problem If the kernel is single-threaded, then
  any user-level thread performing a blocking
  system call will cause the entire process to
  block.
• Examples
• - POSIX Pthreads
• - Mach C-threads
• - Solaris UI-threads

26
Implementing Threads in User Space

• A user-level threads package

27
Kernel Threads

• Supported by the Kernel The kernel performs
  thread creation, scheduling, and management in
  kernel space.
• Disadvantage high cost
• Examples
• - Windows 95/98/NT/2000/XP
• - Solaris
• - Tru64 UNIX
• - BeOS
• - OpenBSD
• - FreeBSD
• - Linux

28
Implementing Threads in the Kernel

• A threads package managed by the kernel

29
Hybrid Implementations

• Multiplexing user-level threads onto kernel-
  level threads

30
Scheduler Activations

• Goal mimic functionality of kernel threads
• gain performance of user space threads
• Avoids unnecessary user/kernel transitions
• Kernel assigns virtual processors to each process
• lets runtime system allocate threads to
  processors
• Makes an upcall to the run-time system to switch
  threads.
• Problem Fundamental reliance on kernel
  (lower layer)
• calling procedures in user space (higher
  layer)

31
Pop-Up Threads

• Creation of a new thread when message arrives
• (a) before message arrives
• (b) after message arrives

32
Making Single-Threaded Code Multithreaded

• Conflicts between threads over the use of a
  global variable

33
Making Single-Threaded Code Multithreaded

• Threads can have private global variables

34
Thread Programming

• Pthread - a POSIX standard (IEEE 1003.1c) API for
  thread creation and synchronization. ltpthread.hgt.
• Solaris 2 is a version of UNIX with support for
  threads at the kernel and user levels, SMP, and
  real-time scheduling.
• Solaris 2 implements the Pthread API and UI
  threads

35
Thread Programming

• Pthread - a POSIX standard (IEEE 1003.1c) API for
  thread creation and synchronization.
• Example thread-sum.c, pthread-ex.c,
  helloworld.cc
• Solaris 2 threads
• Solaris 2 is a version of UNIX with support for
  threads at the kernel and user levels, SMP, and
  real-time scheduling.
• Solaris 2 implements the Pthread API and UI
  threads.
• Example thread-ex.c, lwp.c

36
Thread Programming

• Java threads may be created by
• Extending Thread class
• Implementing the Runnable interface
• Calling the start method for the new object does
  two things
• It allocates memory and initializes a new thread
  in the JVM.
• It calls the run method, making the thread
  eligible to be run by JVM.
• Java threads are managed by the JVM.
• Example ThreadEx.java, ThreadSum.java

37
Interprocess Communication

• Three issues are involved in interprocess
  communication (IPC)
• How one process can pass information to another.
• How to make sure two or more processes do not get
  into each others way when engaging in critical
  activities.
• Proper sequencing when dependencies are present.
• Race conditions are situations in which several
  processes access shared data and the final result
  depends on the order of operations.

38
Interprocess CommunicationRace Conditions

• Two processes want to access shared memory at
  same time

39
Race Condition

• Assume there are two variables , out, which
  points to the next file to be printed, and in,
  which points to the next free slot in the
  directory.
• Assume in is currently 7. The following situation
  could happen
• Process A reads in and stores the value 7 in a
  local variable. A switch to process B happens.
• Process B reads in, stores the file name in
  slot 7 and updates in to be an 8.
• Process A stores the file name in slot 7 and
  updates in to be an 8.
• The file name in slot 7 was determined by who
  finished last. A race condition occurs.

40
Critical Regions

• The key to avoid race conditions is to prohibit
  more than one process from reading and writing
  the shared data at the same time.
• Four conditions to provide mutual exclusion
• No two processes simultaneously in critical
  region
• No assumptions made about speeds or numbers of
  CPUs
• No process running outside its critical region
  may block another process
• No process must wait forever to enter its
  critical region

41
Critical Regions (2)

• Mutual exclusion using critical regions

42
Mutual Exclusion Solution - Disabling Interrupts

• By disabling all interrupts, no context switching
  can occur.
• Thus, it is unwise to allow user processes to
  disable interrupts.
• However, it is convenient (and even necessary)
  for the kernel to disable interrupts while a
  context switch is being performed.

43
Mutual Exclusion Solution - Lock Variable

• shared int lock 0
• / entry_code execute before entering critical
  section /
• while (lock ! 0) / do nothing /
• lock 1
• - critical section -
• / exit_code execute after leaving critical
  section /
• lock 0
• This solution may violate property 1. If a
  context switch occurs after one process executes
  the while statement, but before setting lock 1,
  then two (or more) processes may be able to enter
  their critical sections at the same time.

44
Mutual Exclusion with Busy Waiting

• Proposed solution to critical region problem
• (a) Process 0. (b) Process 1.

45
Mutual Exclusion Solution Strict Alternation

• This solution may violate progress requirement.
  Since the processes must strictly alternate
  entering their critical sections, a process
  wanting to enter its critical section twice in a
  row will be blocked until the other process
  decides to enter (and leave) its critical section
  as shown in the the table below.
• The solution of strict alteration is shown in
  Ex5.c. Be sure to note the way shared memory is
  allocated using shmget and shmat.

turn P0 P1
0 CS while
1 RS CS
0 RS RS
0 RS while
46
Mutual Exclusion with Busy Waiting

• Peterson's solution for achieving mutual exclusion

47
Mutual Exclusion Solution Petersons

• This solution satisfies all 4 properties of a
  good solution. Unfortunately, this solution
  involves busy waiting in the while loop. Busy
  waiting can lead to problems we will discuss
  below.
• Challenge Write the code for Peterson's solution
  using Ex5.c (the strict alteration code) as a
  starting point.

48
Hardware solution Test-and-Set Locks (TSL)

• The hardware must support a special instruction,
  tsl, which does 2 things in a single atomic
  action
• tsl register, flag
• (a) copy a value in memory (flag) to a CPU
  register and
• (b) set flag to 1.

49
Mutual Exclusion with Busy Waiting

• Entering and leaving a critical region using the
• TSL instruction

50
Mutual Exclusion with Busy Waiting

• The last two solutions, 4 and 5, require
  BUSY-WAITING that is, a process executing the
  entry code will sit in a tight loop using up CPU
  cycles, testing some condition over and over,
  until it becomes true. For example, in 5, in the
  enter_region code, a process keeps checking over
  and over to see if the flag has been set to 0.
• Busy-waiting may lead to the PRIORITY-INVERSION
  PROBLEM if simple priority scheduling is used to
  schedule the processes.

51
Mutual Exclusion with Busy Waiting

• Example Test-and-set Locks
• P0 (low) - in cs -x
• context
• switch
• P1 (high) -----tsl-cmp-jnz-tsl...
  x-tsl-cmp... x-... forever.
• Note, since priority scheduling is used, P1 will
  keep getting scheduled and waste time doing
  busy-waiting. -(
• Thus, we have a situation in which a low-priority
  process is blocking a high-priority process, and
  this is called PRIORITY-INVERSION.

52
Semaphores E.W. Dijkstra, 1965.

• A SEMAPHORE, S, is a structure consisting of two
  parts
• (a) an integer counter, COUNT
• (b) a queue of pids of blocked processes, Q
• That is,
• struct sem_struct
• int count
• queue Q
• semaphore
• semaphore S

53
Semaphores E.W. Dijkstra, 1965.

• There are 2 operations on semaphores, UP and
  DOWN. These operations must be executed
  atomically (that is in mutual exclusion). Suppose
  that P is the process making the system call.
  The operations are defined as follows
• DOWN(S)
• if (S.count gt 0)
• S.count S.count - 1
• else
• block(P) that is,
• (a) enqueue the pid of P
  in S.Q,
• (b) block process P
  (remove the pid from
• the ready queue), and
• (c) pass control to the
  scheduler.

54
Semaphores E.W. Dijkstra, 1965.

• UP(S)
• if (S.Q is nonempty)
• wakeup(P) for some process P in S.Q that is,
• (a) remove a pid from S.Q
  (the pid of P),
• (b) put the pid in the
  ready queue, and
• (c) pass control to the
  scheduler.
• else
• S.count S.count 1

55
Mutual Exclusion Problem

• semaphore mutex 1 / set mutex.count 1 /
• DOWN(mutex)
• - critical section -
• UP(mutex)
• To see how semaphores are used to eliminate race
  conditions in Ex4.c, see Ex6.c and sem.h. The
  library sem.h contains a version of UP(semid) and
  DOWN(semid) that correspond with UP and DOWN
  given above.
• Semaphores do not require busy-waiting, instead
  they involve BLOCKING.

56
Producer-Consumer Problem Bounded Buffer Problem

• Consider a circular buffer that can hold N items.
• Producers add items to the buffer and Consumers
  remove items from the buffer.
• The Producer-Consumer Problem is to restrict
  access to the buffer so correct executions result.

57
Sleep and Wakeup

• Producer-consumer problem with fatal race
  condition

58
Semaphores

• The producer-consumer problem using semaphores

59
Mutexes

• A mutex is a semaphore that can be in one of two
  states unlocked or locked.

• Implementation of mutex_lock and mutex_unlock

60
Using Semaphores

• Process Synchronization Order process execution
  
• Suppose we have 4 processes A, B, C, and D.
  A must finish executing before B and C start. B
  and C must finish executing before D starts.
• S1 S2
• A ----gt B ----gt D
• S1 S3
• -----gt C ------
• Then, the processes may be synchronized
  using semaphores
• semaphore S1, S2, S3 0,0,0

61
Using Semaphores

• Process Synchronization Order process execution
• Process A
• ----------
• - do work of A
• UP(S1) / Let B or C start
  /
• Process B
• ----------
• DOWN(S1) / Block until A is
  finished /
• - do work of B
• UP(S2)
• Process C
• ----------
• DOWN(S1)
• - do work of C
• UP(S3)

62
Using Semaphores

• Process D
• ----------
• DOWN(S2)
• DOWN(S3)
• - do work of D
• In conclusion, we use semaphores in two different
  ways mutual exclusion (mutex) and process
  synchronization (full, empty).
• Is it easy to use semaphores?

63
Monitors

• A monitor is a collection of procedures,
  variables, and data structures that can only be
  accessed by one process at a time (for the
  purpose of mutual exclusion).
• To allow a process to wait within the monitor, a
  condition variable must be declared, as condition
  x, y
• Condition variable can only be used with the
  operations wait and signal (for the purpose of
  synchronization).
• The operation
• x.wait()means that the process invoking this
  operation is suspended until another process
  invokes
• x.signal()
• The x.signal operation resumes exactly one
  suspended process. If no process is suspended,
  then the signal operation has no effect.

64
Monitors

• Example of a monitor

65
Monitors

• Outline of producer-consumer problem with
  monitors
• only one monitor procedure active at one time
• buffer has N slots

66
Monitors

• Monitors in Java
• supports user-level threads and methods
  (procedures) to be grouped together into classes.
• By adding the keyword synchronized to a method,
  Java guarantees that once any thread has started
  executing that method, no other thread can
  execute that method.
• Advantages Ease of programming. (?)
• Disadvantages
• Monitors are a programming language concept, so
  they are difficult to add to an existing
  language e.g., how can a compiler determine
  which procedures are inside a monitor if they can
  be nested?
• Monitors are too expensive to implement and they
  are overly restrictive (shared memory is
  required).

67
Monitors

• Solution to producer-consumer problem in Java
  (part 1)

68
Monitors
static class our_monitor //this is a
monitor private int buffer new intN
private int count 0, lo 0, hi 0 //
counters and indices public synchronized
void insert(int val) if (count N)
go_to_sleep() // if the buffer is full. go to
sleep buffer hi val //
insert an item into the buffer hi (hi
1) N // slot to place next Item
in count count 1 //one
more item in the buffer now if (count
1) notify() //if consumer was sleeping,
wake it up public synchronized int
remove() int val if (count 0)
go_to_sleep() // if the buffer is empty, go to
sleep val buffer lo //
fetch an item from the buffer lo (lo 1)
N //slot to fetch next item from
count count - 1 // one few
items in the buffer if (count N -1)
notify() //if producer was sleeping, wake it
up return val private void
go_to_sleep() try wait()
catch(InterruptedException exc)

• Solution to producer-consumer problem in Java
  (part 2)

69
Message Passing

• Possible Approaches
• Assign each process a unique address such as
  addr. Then, send messages directly to the
  process blocking receive.
• send(addr, msg)
• recv(addr, msg)
• Example signals in UNIX.
• Use mailboxes blocking receive.
• send(mailbox, msg)
• recv(mailbox, msg)
• Example pipes in UNIX.
• Rendezvous blocking send and receive.
• Example Ada tasks.
• Message passing is commonly used in parallel
  programming systems. For example, MPI
  (Message-Passing Interface).

70
Pipe Implementation

• Pipe description
• pipe is a unidirectional data structure.
• One end is for reading and one end is for
  writing.
• Use pipe function to create a pipe.
• int mbox2
  
• pipe(mbox)
• In our implementation, mbox0 is for reading and
  mbox1 is for writing.
• First End
  Second End
• mbox0 lt-oooooooooooooooooooolt- mbox1
• Where o stands for token.
• Each pipe is used like a semaphore.
• If the initial value of a semaphore is 0,
  then no token is required to store in the pipe
  initially.

71
Pipe Implementation

• Pipe description
• If the initial value of a semaphore is more than
  0, for example, the initial value is 3, then
  it can be initialized in this way
• int msg 0
  
• for (i 1 i lt 3 i)
  
• write(mbox11,msg,sizeof(msg))
• DOWN(S) is equivalent to
  read(mbox0,msg,sizeof(msg))
  
• UP(S) is equivalent to
  write(mbox1,msg,sizeof(msg))

72
Message Passing

• The producer-consumer problem with N messages

73
Barriers

• Use of a barrier
• processes approaching a barrier
• all processes but one blocked at barrier
• last process arrives, all are let through
• Example Parallel matrix multiplication

74
Classical IPC Problems

• These problems are used for testing every newly
  proposed synchronization scheme
• Bounded-Buffer (Producer-Consumer) Problem
• Dining-Philosophers Problem
• Readers and Writers Problem
• Sleeping Barber Problem

75
Dining Philosophers

• Dining Philosophers Problem Dijkstra, 1965
• Problem Five philosophers are seated around a
  table. There is one fork between each pair of
  philosophers. Each philosopher needs to grab the
  two adjacent forks in order to eat. Philosophers
  alternate between eating and thinking. They only
  eat for finite periods of time.

76
Dining Philosophers

• Philosophers eat/think
• Eating needs 2 forks
• Pick one fork at a time
• How to prevent deadlock

77
Dining Philosophers

• A nonsolution to the dining philosophers problem

78
Dining Philosophers

• Problem Suppose all philosophers execute the
  first DOWN operation, before any have a chance to
  execute the second DOWN operation that is, they
  all grab one fork. Then, deadlock will occur and
  no philosophers will be able to proceed. This is
  called a CIRCULAR WAIT.
• Other Solutions
• Only allow up to four philosophers to try
  grabbing their forks.
• Asymmetric solution Odd numbered philosophers
  grab their left fork first, whereas even numbered
  philosophers grab their right fork first.
• Pick-up the forks only if both are available. See
  Fig. 2-33 (page 127). Note this solution may
  lead to starvation.

79
Dining Philosophers

• Solution to dining philosophers problem (part 1)

80
Dining Philosophers

• Solution to dining philosophers problem (part 2)

81
Readers and Writers Problem

• The readers and writers problem models access to
  a shared database. Only one writer may write at a
  time. Any number of readers may read at the same
  time, but not when a writer is writing.
• One variation of the problem, called weak readers
  reference, is to suspend the incoming readers as
  long as a writer is waiting.

82
The Readers and Writers Problem

• A solution to the readers and writers problem

83
The Sleeping Barber Problem

• Problem The barber shop has one barber, one
  barber chair, and n chairs for waiting customers.
  
• If there are no customers present, the barber
  sits down in the barber chair and falls asleep.
• When a customer arrives, he has to wake up the
  sleeping barber.
• If additional customers arrive while the barber
  is cutting a customers hair, they either sit
  down or leave the shop.
• Program the barber and the customers without
  getting into race conditions.

84
The Sleeping Barber Problem
85
The Sleeping Barber Problem
Solution to sleeping barber problem.
86
Scheduling

• The SCHEDULER is the part of the operating system
  that decides (among the runnable processes) which
  process is to be run next.
• A SCHEDULING ALGORITHM is a policy used by the
  scheduler to make that decision.
• To make sure that no process runs too long, a
  clock is used to cause a periodic interrupt
  (usually around 50-60 Hz (times/second)) that
  is, about every 20 msec. PREEMPTIVE SCHEDULING
  allows processes that are runnable to be
  temporarily suspended so that other processes can
  have a chance to use the CPU.

87
Properties of a GOOD Scheduling Algorithm

1. Fairness - each process gets its fair share of
   time with the CPU.
2. Efficiency - keep the CPU busy doing productive
   work.
3. Response Time - minimize the response time for
   interactive users.
4. Turnaround Time - minimize the turnaround time on
   batch jobs.
5. Throughput - maximize the number of jobs
   processed per hour.

88
Scheduling(Process Behavior)

• Bursts of CPU usage alternate with periods of I/O
  wait
• a CPU-bound process
• an I/O bound process

89
Introduction to Scheduling

• Scheduling Algorithm Goals

90
First-Come, First-Served (FCFS) Scheduling

• Process Burst Time
• P1 24
• P2 3
• P3 3
• Suppose that the processes arrive in the order
  P1 , P2 , P3 The Gantt Chart for the schedule
  is
• Waiting time for P1 0 P2 24 P3 27
• Average waiting time (0 24 27)/3 17

91
FCFS Scheduling (Cont.)

• Suppose that the processes arrive in the order
• P2 , P3 , P1 .
• The Gantt chart for the schedule is
• Waiting time for P1 6 P2 0 P3 3
• Average waiting time (6 0 3)/3 3
• Much better than previous case.
• Convoy effect short process wait behind long
  process

92
Shortest-Job-First (SJR) Scheduling

• Associate with each process the length of its
  next CPU burst. Use these lengths to schedule
  the process with the shortest time.
• The real difficulty with the SJF algorithm is
  knowing the length of the next CPU request.
• SJF scheduling is used frequently in long-term
  scheduling.
• The next CPU burst is generally predicated as an
  exponential average of the measured lengths of
  previous CPU bursts.

93
Scheduling in Batch Systems

• An example of shortest job first scheduling

94
Shortest-Job-First (SJR) Scheduling

• Two schemes
• nonpreemptive once CPU given to the process it
  cannot be preempted until it completes its CPU
  burst.
• preemptive if a new process arrives with CPU
  burst length less than remaining time of current
  executing process, preempt. This scheme is know
  as the Shortest-Remaining-Time-First (SRTF).
• SJF is optimal gives minimum average waiting
  time for a given set of processes.

95
Example of Non-Preemptive SJF

• Process Arrival Time Burst Time
• P1 0.0 7
• P2 2.0 4
• P3 4.0 1
• P4 5.0 4
• SJF (non-preemptive)
• Average waiting time (0 6 3 7)/4 4

96
Example of Preemptive SJF

• Process Arrival Time Burst Time
• P1 0.0 7
• P2 2.0 4
• P3 4.0 1
• P4 5.0 4
• SJF (preemptive)
• Average waiting time (9 1 0 2)/4 3

97
Three-Level Scheduling

• The admission scheduler decides which jobs to
  admit to the system.
• The memory scheduler decides which processes
  should be kept in memory and which one kept on
  disk.
• It can also decide how many processes it wants in
  memory, called the degree of multiprogramming.
• The CPU scheduler is actually picking one of the
  ready processes in main memory to run next.

98
Scheduling in Batch Systems

• Three level scheduling

99
Scheduling in Interactive Systems

• Round Robin Scheduling
• list of runnable processes
• list of runnable processes after B uses up its
  quantum

100
Round Robin (RR)

• Each process gets a small unit of CPU time (time
  quantum), usually 10-100 milliseconds. After
  this time has elapsed, the process is preempted
  and added to the end of the ready queue.
• If there are n processes in the ready queue and
  the time quantum is q, then each process gets 1/n
  of the CPU time in chunks of at most q time units
  at once. No process waits more than (n-1)q time
  units.
• Performance
• q large ? FIFO
• q small ? q must be large with respect to context
  switch, otherwise overhead is too high.

101
Example of RR with Time Quantum 20

• Process Burst Time
• P1 53
• P2 17
• P3 68
• P4 24
• The Gantt chart is
• Typically, higher average turnaround than SJF,
  but better response.

102
Time Quantum and Context Switch Time
103
Priority Scheduling

• A priority number (integer) is associated with
  each process
• The CPU is allocated to the process with the
  highest priority (smallest integer ? highest
  priority).
• Preemptive
• nonpreemptive
• SJF is a priority scheduling where priority is
  the predicted next CPU burst time.
• Problem ? Starvation low priority processes may
  never execute.
• Solution ? Aging as time progresses increase
  the priority of the process.

104
Example of Priority Scheduling

• Process Burst Time Priority
• P1 5.0 6
• P2 2.0 1
• P3 1.0 3
• P4 4.0 5
• P5 2.0 2
• P6 2.0 4
• Priority
• Average waiting time (2 4 5 7 11 2) /
  6 4.83

105
Multilevel Queue Scheduling

• Each ready queue is assigned a different priority
  class CTSS - Corbato, 1962.
• Ready queue is partitioned into separate
  queuesforeground (interactive)background
  (batch)
• Each queue has its own scheduling algorithm,
  foreground RRbackground FCFS
• Scheduling must be done between the queues.
• Fixed priority scheduling (i.e., serve all from
  foreground then from background). Possibility of
  starvation.
• Time slice each queue gets a certain amount of
  CPU time which it can schedule amongst its
  processes i.e., 80 to foreground in RR and 20
  to background in FCFS

106
Scheduling in Interactive Systems

• A scheduling algorithm with four priority classes

107
More Scheduling

• Shortest Process Next
• SJF can be used in an interactive environment by
  estimating the runtime based on past behavior.
  Aging is a method used to estimate runtime by
  taking a weighted average of the current runtime
  and the previous estimate.
• Example Let a estimate weight, then the
  current estimate is a x T0 (1-a) x T1
• where T0 is the previous estimate and T1 is
  the current runtime.
• Guaranteed Scheduling
• Suppose 1/n of the CPU cycles.
• Compute ratio actual CPU time consumed / CPU
  time entitled
• Run the process with the lowest ratio

108
More Scheduling

• Lottery Scheduling
• Give processes lottery tickets for various system
  resources
• When a scheduling decision is made, a lottery
  ticket is chosen, and the process holding that
  ticket gets the resource.
• Fair-Share Scheduling
• Take into account how many processes a user owns.
• Example User 1 A, B, C, D and Use 2 E
• Round-robin AEBECEDE...
• Fair-Share if use 1 is entitled to twice as much
  CPU time as user 2
• ABECDEABECDE.

109
Scheduling in Real-Time Systems

• The scheduler makes real promises to the user in
  terms of deadlines or CPU utilization.
• Schedulable real-time system
• Given
• m periodic events
• event i occurs within period Pi and requires Ci
  seconds
• Then the load can only be handled if

110
Policy versus Mechanism

• Separate what is allowed to be done with how it
  is done
• a process knows which of its children threads are
  important and need priority
• Scheduling algorithm parameterized
• mechanism in the kernel
• Parameters filled in by user processes
• policy set by user process

111
Thread Scheduling

• The process scheduling algorithm can be used in
  thread scheduling. In practice, round-robin and
  priority scheduling are used.
• The only constraint is the absence of a clock to
  interrupt a user-level thread.
• User-level and kernel-level threads
• A major difference between user-level threads and
  kernel-level threads is the performance.
• User-level threads can employ an
  application-specific thread scheduler.

112
Thread Scheduling

• Possible scheduling of user-level threads
• 50-msec process quantum
• threads run 5 msec/CPU burst

113
Thread Scheduling

• Possible scheduling of kernel-level threads
• 50-msec process quantum
• threads run 5 msec/CPU burst