Short term Scheduler Functions

1
Short term Scheduler Functions

• Creates maintains Ready Queue employing
  Enqueuer Module.
• Makes the time grained decision of which process
  / thread from the ready queue will be executed
  next.
• Involves in dispatching of selected process from
  the Ready State to the Running state using
  Dispatcher Context switcher modules.
• Executes most frequently.
• Invoked when any one of the following events
  occur
• 1) The currently running process gets terminated
  thereby freeing the CPU.
• 2) The currently running process goes to wait /
  Blocked state after executing or alternatively
  scheduled for I/O operation after executing WAIT
  making the CPU idle
• 3) The currently running process comes
  back to ready state due to some pre-emption
  policy.
• 4) Some event is complete which causes a
  Device Interrupt which in turn may execute Signal
  causing some Waiting Processes to become Ready.
• Performs the primary functions of the process
  manager.

2
Short Term Scheduler Structure
Code
Ready Process
From Other States
Process / Thread Descriptors (Control Blocks)
Data
Resource
Ready queue of pointers to PCBs
Enqueuer
CPU
Dispatcher Module
Context Switcher
Pre- Empted/ Removed
3
Short term / CPU Scheduler components their
functions- I

• A. Enqueuer Function After process has been
  created.
• 1. Update Process Descriptor / Process
  Control Block (PCB)
• entries. (Resource allocation / state
  etc.)
• 2. Create a pointer to that PCB.
• 3. Put the pointer to the PCB in the
  Relevant Queue / List in accordance with the
  adopted Short term Scheduling Policy.
• N.B. This Enqueuer happens to be a System /
  O.S. / Kernel Process that needs to be executed
  by the same CPU in order to accomplish the
  aforesaid tasks. It is however possesses some
  prefixed priority which is higher than any user
  process that forms the Ready Queue.

4
The Context Switcher

• Meaning of the Context The context of any
  process implies its current execution status
  which includes the following
• 1. All the CPU Registers.
• 2. The current user Stack
  contents.
• 3. The Local variables and
  parameters.
• In short its current thread of execution.
• Possible Causes of Context switch
• 1.Voluntary Sharing of CPU Each running
  process yields the CPU by executing an explicit
  system call periodically. Unlikely real life
  scenario.
• 2.Involuntary sharing of the CPU Enforced on
  each every running process due to one of the
  following reasons
• The process asks for I/O and consequently goes
  to WAIT/Blocked state.
• Arrival of a higher priority process pre-empts
  it.
• Caused by a timer generated interrupt OR Device
  generated Interrupt.

5
Timer generated Interrupt ( an essential feature
of Pre-empted Scheduling Policy / Multitasking - 1

• Implemented by an interrupt timer device The
  code outline
• A. Setting the Time Interval by the user / O.S
• Set Interval ( lt programmable value gt )
• / begin set interval done as a part of
  Context Switch /
• k lt programmable value gt / Global variable
  /
• Interrupt_count k / Global variable /
• / end set interval /

6
Timer generated Interrupt ( an essential feature
of Pre-empted Scheduling Policy / Multitasking - 2

• Interval-Timer ( ) / will cause the
  Programmable Interrupt Timer Device to issue on
  interrupt once on every k clock ticks /
• / begin repeatedly invoked within the
  running process/
• Interrupt_count Interrupt_count 1
• if (Interrupt_count lt 0)
• / begin then /
• Int_Request TRUE / Issue Interrupt
  /
• Interrupt_count k
• / end then /
• / end / In actual terms one can have a
  hardware support available in a programmable
  interrupt controller (like APSC in Pentium)

7
Short Term Scheduling Steps

• 1.The current process goes to wait state after
  generating a Sys. Call followed by executing WAIT
  , A higher priority process arrives in Ready
  Queue (including any O.S. / Kernel Modules) OR
  Timer interrupt is generated OR a Device
  Interrupt is generated.
• 2. CPU switches to kernel mode.
• 3. Saves the current process / thread
  context in memory (Faster for thread switching)
  employing Context Switcher which in turn loads
  dispatcher context .
• 4. Dispatcher executes , while executing it
  selects a process/ thread from Ready Queue in
  accordance with scheduling policy OR schedules
  the Kernel / O.S. process Enqueuer / Context
  Switcher .
• 5. Switches context by terminating the
  dispatcher process and loading the context of the
  scheduled process.

8
Short Term Scheduling Policy / Strategy Vs.
Short Term Scheduler Structure

• Scheduling Policy Determines the following
• Time of removal of the currently running process
  / Pre Emption
• CPU De- allocation Policy
• Selection policy of the next process to run
  from the Ready Queue.
• Scheduling Mechanism / Scheduler structure
  concerns with the following issues
• How does the short term scheduler/process manager
  know it is time to switch context (Multiplex the
  CPU time) ? Already discussed.
• What are the existing scheduling policies ?
• How to implement any prefixed scheduling policy ?

9
Short Term Scheduling Policies - 1

• 1) First Come First Served FIFO based
  on the arrival time of the process in the Ready
  Queue.
• 2) Shortest Job First SJF based on
  estimated CPU time needed by the processes done
  either by noting the Code Length together with
  average time/instruction of the code or estimated
  from prior execution history .
• 3) Deadline based Each process is
  associated with a prefixed deadline.
• 4) Pre- Assigned priority Based Single
  Ready Queue
• 5) Multiple Ready Queues. Feedback / non
  feedback

10
Short Term Scheduling Policies - 2

• Each of the aforesaid scheduling policies may
  have following two versions
• a) Non Pre-emptive The currently scheduled
  process is allowed to run (occupy the CPU) till
• a.1. It gets terminated (normally/
  abnormally) .
• a.2 It goes to BLOCKED / WAIT state due
  to system call.
• b) Pre-emptive The currently scheduled
  process is allowed to run (occupy the CPU) till
• b.1. Its allocated time slice gets
  exhausted.
• b.2. A higher priority process arrives.

11
Short Term Scheduling Policies 3( The
Scheduled Process Quantum)

• Consider any typical program / process
  structure

Pure Code Block 1 ( P A1 ) Takes CPU Time T A1

Sys Call 1 Do I/O
The System Library Call Pure Code Block 2 ( P
A2 ) Takes CPU Time T A2
Sys Call 2 Create a Child
And So ON
12
Short Term Scheduling Policies 4( The
Scheduled Process Quantum Contd.)

• Hence one can roll out the different processes
  competing for the CPU in the following way

P A1CPU Time ( T A1) BLOCKED P A2 CPU
Time (T A2)
P A
P i1 CPU Time ( T i1) BLOCKED P i2
CPU Time (T i2)
P i
P n1 CPU Time ( T n1) BLOCKED P n2
CPU Time (T n2)
P n
13
Short Term Scheduling Policies 5( The Common
Assumptions)

• In order to study the performance of any Short
  Term Scheduling Policy, one need to consider only
  the CPU Bound portions of the concerned processes
  competing for the CPU.
• It is reasonable to assume that only the CPU
  bound portions of the concerned processes are put
  in the Ready Queue and they compete with each
  other for the CPU based on predefined scheduling
  policies.
• Each of the Kernel Processes like Enqueuer ,
  Dispatcher, Context Switcher happens to be purely
  CPU bound processes each is sharing the same
  priority which is higher than any user process.
  However on arrival of any new process Enqueuer
  gets priority over Dispatcher.
• None of these Kernel Processes can be pre-empted.