Download Week 9

2P13
Week 9
Page 1
Table 9.2 Scheduling Criteria
User Oriented, Performance Related
Turnaround time This is the interval of time between the submission of a process and its
completion. Includes actual execution time plus time spent waiting for resources, including the
processor. This is an appropriate measure for a batch job.
Response time For an interactive process, this is the time from the submission of a request
until the response begins to be received. Often a process can begin producing some output to the
user while continuing to process the request. Thus, this is a better measure than turnaround time
from the user's point of view. The scheduling discipline should attempt to achieve low response
time and to maximize the number of interactive users receiving acceptable response time.
Deadlines When process completion deadlines can be specified, the scheduling discipline
should subordinate other goals to that of maximizing the percentage of deadlines met.
User Oriented, Other
Predictability A given job should run in about the same amount of time and at about the same
cost regardless of the load on the system. A wide variation in response time or turnaround time is
distracting to users. It may signal a wide swing in system workloads or the need for system tuning
to cure instabilities.
System Oriented, Performance Related
Throughput The scheduling policy should attempt to maximize the number of processes
completed per unit of time. This is a measure of how much work is being performed. This clearly
depends on the average length of a process but is also influenced by the scheduling policy, which
may affect utilization.
Processor utilization This is the percentage of time that the processor is busy. For an
expensive shared system, this is a significant criterion. In single-user systems and in some other
systems, such as real-time systems, this criterion is less important than some of the others.
System Oriented, Other
Fairness In the absence of guidance from the user or other system-supplied guidance,
processes should be treated the same, and no process should suffer starvation.
Enforcing priorities When processes are assigned priorities, the scheduling policy should favor
higher-priority processes.
Balancing resources The scheduling policy should keep the resources of the system busy.
Processes that will underutilize stressed resources should be favored. This criterion also involves
medium-term and long-term scheduling.
Page 2
Page 3
Table 9.4 Process Scheduling Example
Process
Arrival Time
Service Time
A
0
3
B
2
6
C
4
4
D
6
5
E
8
2
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Table 10.1 Synchronization Granularity and Processes
Grain Size
Description
Synchronization Interval
(Instructions)
Fine
Parallelism inherent in a single
instruction stream.
<20
Medium
Parallel processing or multitasking
within a single application
20-200
Coarse
Multiprocessing of concurrent
processes in a multiprogramming
environment
200-2000
Very Coarse
Distributed processing across network
nodes to form a single computing
environment
2000-1M
Independent
Multiple unrelated processes
not applicable
Page 10
Page 11
Features of Real-Time OS
•
•
•
•
•
•
•
•
•
Fast process or thread switch
Small size
Ability to respond to external interrupts quickly
MultiTasking with inter-process communication tools,
semaphores, signals, and events.
Use of special sequential files that can accumulate data
at a fast rate
Pre-emptive scheduling based on priority
Minimize duration interval when interrupts are disabled
Primitives to delay tasks for a fixed amount of time and
to pause/resume tasks
Special alarms and timeouts.
Page 12
Page 13
Static table-driven approaches
• performs a static analysis of feasible schedules of dispatching
• result is a schedule that determines, at run time, when a task must begin execution
Static priority-driven preemptive approaches
• a static analysis is performed but no schedule is drawn up
• analysis is used to assign priorities to tasks so that a traditional priority-driven
preemptive scheduler can be used
Dynamic planning-based approaches
• feasibility is determined at run time rather than offline prior to the start of execution
• one result of the analysis is a schedule or plan that is used to decide when to dispatch
this task
Dynamic best effort approaches
• no feasibility analysis is performed
• system tries to meet all deadlines and aborts any started process whose deadline is
missed
Page 14
• Real-time operating systems are designed with the
objective of starting real-time tasks as rapidly as
possible and emphasize rapid interrupt handling and
task dispatching
• Real-time applications are generally not concerned
with sheer speed but rather with completing (or
starting) tasks at the most valuable times
• Priorities provide a crude tool and do not capture the
requirement of completion (or initiation) at the most
valuable time
Page 15
Ready time
Starting
deadline
Completion
deadline
Processing
time
• time task becomes
ready for execution
Resource
requirements
• resources required by
the task while it is
executing
Priority
• measures relative
importance of the task
• time task must begin
• time task must be
completed
• time required to execute
the task to completion
Subtask
scheduler
• a task may be
decomposed into a
mandatory subtask and
an optional subtask
Page 16
Table 10.2
Execution Profile of Two Periodic Tasks
Process
Arrival Time
Execution Time
Ending Deadline
A(1)
0
10
20
A(2)
20
10
40
A(3)
40
10
60
A(4)
60
10
80
A(5)
80
10
100
•
•
•
•
•
•
•
•
•
•
•
•
B(1)
0
25
50
B(2)
50
25
100
•
•
•
•
•
•
•
•
•
•
•
•
Page 17
Figure 10.5 Scheduling of Periodic Real-Time Tasks With Completion Deadlines (Based on
Table 10.2)
Page 18
Figure 10.6 Scheduling of Aperiodic Real-Time Tasks With Starting Deadlines
Page 19
Table 10.3
Execution Profile of Five Aperiodic Tasks
Process
Arrival Time
Execution Time
Starting Deadline
A
10
20
110
B
20
20
20
C
40
20
50
D
50
20
90
E
60
20
70
Page 20
Rate
Monotonic
Schedulin
g
Figure 10.7
Page 21
Periodic Task
Timing Diagram
Figure 10.8
Page 22
The End
Page 23