CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
THE UNIX PROCESS SCHEDULER: A COMPUTER ASSISTED LESSON
A graduate project submitted in partial satisfaction
of the requirements for the degree of
Master of Science in
Computer Science
by
Sharon Kilpatrick Adler
May 1988
The graduate
approved:
project
of
Sharon
Kilpatrick
P~Baikataki
California State University, Northridge
ii
Adler
is
ACKNOWLEDGEMENTS
I would like to thank the two men who have had the
greatest influence on my life in computer science:
Steven Stepanek and David Adler.
Steven Stepanek, the chair of my Advisory Committee,
introduced me to operating systems in general and
to the UNIX operating system in particular.
He suggested the topic for this graduate project, and he has
been unfailingly generous in offering facilities and
equipment,
as well as in giving his time.
He has provided me with many opportunities to
increase
my
knowledge of the UNIX system.
David Adler, my schoolmate, friend, and son, is the
person who first introduced me to computers, and he was
my first Computer Science teacher.
He has shared my
enthusiasm for computers and put up with countless questions.
iii
TABLE OF CONTENTS
Page
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
L i s t o f F i gu r e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi i
Ab s t r a c t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v i i i
Chapter
0.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.
CAI, Andrew, and CMU Tutor . . . . . . . . . . . . . . . . . . . . 3
2.
1.
CAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.
Andrew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.
CMU Tutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Process Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.
Scheduling Objectives . . . . . . . . . . . . . . . . . . . . . 8
2.
Scheduling Algorithms . . . . . . . . . . . . . . . . . . . . . 9
2.1.
3.
3.
Preemptive Algorithms . . . . . . . . . . . . . . . 9
2.1.1.
Preemptive Priority
Scheduling . . . . . . . . . . . . . . . . 9
2.1.2.
Shortest-Remaining-Time .... 11
2.1.3.
Round Robin . . . . . . . . . . . . . . . . 12
2.1.4.
Multi-Level Queues . . . . . . . . . 13
2.1.5.
Multi-Level Feedback
Queues . . . . . . . . . . . . . . . . . . . 13
Size of Time Quantum . . . . . . • . . . . . . . . . . . . . . 14
The UNIX Process Scheduler . . . . . . . . . . . . . . . . . . . 16
1.
The Standard UNIX Process Scheduler ...... 16
2.
Other UNIX Process Schedulers .......•.... 19
2.1.
The Fair Share Scheduler ....•...... 19
iv
J
2.2.
Multiprocessor Variations .......... 20
2.3.
Variations for Real-Time Systems ... 21
4.
User's View of the Lesson .................... 22
5.
Programmer's View of the Lesson .............. 52
1.
Data Structures .......................... 54
1.1.
The Process Table .................. 55
1.2.
The Run Queue ...................... 55
1.3.
The inqueue Array .................. S6
2.
Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.
Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.1.
Main Module and Driver Routines .... S8
3.2.
Initialization and Initial
Process Generation Routines ...... S9
3.3.
Process Management Routines ........ 59
3.4.
3.5.
4.
3.3.1.
Menu Routines to Add a
Process .................. 60
3.3.2.
Menu Routines to Remove a
Process .................. 60
Lesson Text Routines ............... 60
3.4.1.
Help Routine ............... 61
3.4.2.
Routines to Give
Additional Information ... 61
Graphics Routines .................. 61
Some Challenges of Writing This
Program . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . 62
5.
6.
Additional Features ...................... 63
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
1.
What Did I Learn from This Project? ...... 66
1.1.
Schedulers ..•...................... 65
1.2.
UNIX Process Schedulers ............ 66
v
1.3.
Writing CAI Lessons . . . . . . . . . . . . . . . . 66
1.4.
The CMU Tutor Language . . . . . . . . . . . . . 67
1.5.
Using the troff/nroff Language
for Text Formatting . . . . . . . . . . . . . . 67
1.6.
Documenting . . . . . . . . . . . . . . . . . . . . . . . . 68
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . 69
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Appendix A: User's Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
1.
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.
Using the Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.1.
Available Menu Selections . . . . . . . . . . 75
2.2.
Adding and Killing Processes . . . . . . . 76
3.
Quitting the Lesson . . . . . . . . . . . . . . . . . . . . . . 76
4.
A Final Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix B: Source Code Listing . . . . . . . . . . . . . . . . . . . . . . . 78
vi
LIST OF FIGURES
Figure
Page
1.
Initial screen- "Make screen bigger" ........ 24
2.
How to run the lesson . . . . . . • . . . . . . . . . . . . . . . . . 26
3.
What is a scheduler? . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.
The UNIX Process Scheduler . . . . . . . . . . . . . . . . . . . 28
5.
The process table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.
The process table, filled in . . . . . . . . . . . . . . . . . 30
7.
Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.
Run queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.
Run queues, filled in . . . . . . . . . . . . . . . . . . . . . . . . 34
10.
Priorities per user-level queue . . . . . . . . . . . . . . 35
11.
Kernel-level queues . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.
Adding processes to system . . . . . . . . . . . . . . . . . . . 37
13.
Scheduler will begin to execute . . . . . . . . . . . . . . 38
14.
Can add or kill processes . . . . . . . . . . . . . . . . . . . . 39
15.
Processes complete I/0 . . . . . . . • . . . . . . . . . . . . . . . 40
16.
Current process runs . . . . . . . . . . . . . . . . . . . . . . . . . 41
17.
Recalculating CPU and priority values ........ 42
18.
Showing new values . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
19.
Current process terminates . . . . . . . . . . . . . . . . . . . 44
20.
Recalculating CPU and priority values ........ 45
21.
Showing new values . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
22.
Five processes have been added ...•..•........ 48
23.
Processes 12 and 20 have been killed . . . . . . . . . 49
24.
No ready process to schedule . . . . . . . . . . . . . . . . . 50
vii
ABSTRACT
THE UNIX PROCESS SCHEDULER: A COMPUTER ASSISTED LESSON
by
Sharon Kilpatrick Adler
Master of Science in Computer Science
The UNIX*
round
robin
process
scheduler
scheduling
algorithm.
adjusted periodically: priorities of
in
the
ready
queue
are
processes that just used
according
back
to
ensures
uses
a
Priorities
processes
incremented;
CPU
prioritized
resources
the amount of resources used.
good
response
time
waiting
priorities
are
for
are
of
decreased
This feedinteractive
processes and prevents starvation for processes with low
initial priorities.
This computer-assisted lesson graphically simulates
the scheduling of processes by the standard UNIX process
scheduler.
system.
A number of processes are initially
icted.
the
A partial process table shows the process iden-
tification number, priority, and CPU
each
in
process.
The
usage
factor
for
logical ready queues are also dep-
Each time the scheduler runs, the
priority
CPU usage values in the process table and the graphic
* UNIX is a registered trademark of AT&T.
viii
and
representation of the logical ready queues are
Lesson
updated.
text accompanies each step of the simulation.
The user can add processes, specifying the priority
of
each, or kill processes by selecting the option from
a menu.
the
On-screen help and additional information about
simulation
can
also
appropriate menu option.
the
simulated
much of the
each
be obtained by selecting the
Important
occurrences
during
runs are pointed out to the user.
is determined by random
simulatio~
Since
numbers,
running of the lesson is subtly different from the
next.
The lesson is written in the
language.
It
runs
on
CMU
workstations,
IBM
authoring
advanced-function workstations
running the UNIX operating system and
Sun
Tutor
RT
MicroVAX workstations.
ix
Andrew,
such
as
Personal Computers, and DEC
Chapter 0
Introduction
Perhaps paradoxically, the success of the UNIX
system is largely due to the fact that it was
not designed to meet any predefined objectives.
D. M. Ritchie and K. Thompson (9:1926).
This paper
that
describes
graphically
scheduler.
lectures
a
presents
computer-assisted
the
standard
lesson
UNIX process
This lesson is intended to supplement
on
class
schedulers in an operating systems course.
The lesson is of the type of CAI known
as
adjunct
CAI
(3), and it is a simulation intended to demonstrate concepts.
One goal of the lesson is to teach the
facts
about
the
can
goal
in
operation.
check their understanding of the material
by trying to predict what
Another
is
will
happen
at
each
lower-level routines.
tion that ages
the
step.
to enable students to "play" with the
code, modifying parameters or perhaps changing
the
basic
UNIX process scheduler, and to illus-
trate the facts by showing the scheduler
Students
user
CPU
some
of
For example, the decay functime
for
a
process
can
be
changed, and the effects of the change can be observed.
Creating the lesson required learning the CMU Tutor
1
2
authoring
language
in
which
the
program is written.
Early in the design process for the
apparent
lesson,
it
became
that a knowledge of the UNIX process scheduler
and of computer programming is not enough to permit
writing
of a good lesson.
principles of
the
A basic understanding of the
computer-assisted
instruction
(CAI)
is
also needed.
Chapter 1 starts with a brief introduction to
Next,
the
which the
chapter
UNIX
CAI.
describes the Andrew environment in
processor
scheduler
lesson
executes.
Finally, it discusses the CMU Tutor language.
Chapter 2 looks at process
and
Chapter
of
the
lesson
general
from
the
user's
is given in Chapter 4, with some screen dumps
of the actual lesson in execution.
the
in
3 talks about the UNIX process schedulers.
A brief walk-through
viewpoint
schedulers
Chapter 5
looks
at
lesson from the programmer's point of view; it cov-
ers the design and analysis of the program.
The conclu-
sion of the project report appears in Chapter 6.
This paper concludes with two appendices.
A
Appendix
is the user's manual, and Appendix B lists the source
code.
Chapter 1
CAI, Andrew, and CMU Tutor
He that teaches us anything which we knew not
before is undoubtedly to be revered as a master.
Samuel Johnson, The Idler.
1.
CAI
CAI - computer-assisted instruction - began in
late 1950s and early 1960s (3).
the
In spite of predictions
in the early 1970s that CAI would be in
widespread
use
by 1980, this is not yet the situation in 1988.
One major
actively
advantage
involve
the
of
CAI
student
is
its
ability
in the learning process
(3).
Another plus for CAI is the ability for
dent
to
important
control
to
the
stu-
the pace of the lesson, an especially
consideration
for
the
exceptionally
fast
learner as well as the slow one.
Three types of CAI are most common: drill and practice, simulations, and tutorial (6:19).
Drill and prac-
tice asks the student for a response, then
back
to
the
response.
feed-
This type of CAI is most often
used to give practice in skills
that
already
are
learned.
gives
Simulations
teach a student to identify
and
3
the
student
generally
control
has
used to
relationships
4
between
components
of
components may permit
relationships.
The
a
system.
Manipulation of the
the
student
to
determine
such
tutorial is the most comprehensive
type of CAI of the three.
It usually presents
informa-
'
tion,
questions
presented,
student's
and
the
gives
answers.
student
about
feedback
in
the
material
regards
to
This type of CAI is generally used
as primary, rather than adjunct, instruction (6).
mary
CAI
substitutes
while adjunct
CAI
the
for
other
supplements
Pri-
form of instruction,
the
other
methods
of
instruction (3).
Some guidelines for designing CAI lessons include:*
1.
Let the student control the pace of the lesson,
2.
Restrict the amount of text on
the
screen
at
one
time, and
3.
Give clear instructions regarding what to do next.
Special languages have been developed
CAI
lessons.
These
languages,
for
called
writing
authoring
languages, usually provide graphics commands, as well as.
the
capability
of
carrying
out
calculations.
authoring languages are machine dependent.
al
(3)
cite
the
following
as
a
major
Many
Chambers
et
hurdle
to
widespread use of CAI:
* Gagne (6) suggests a different set of guidelines
designing lessons.
for
5
"There is no standard, high-level, complex CAI
language
which
is
machine
which combines authoring
independent, and
aids,
calculational
modes, and graphics capabilities."
2.
Andrew
Andrew is a "prototype computing and
system
for
universities"
(9:184),
Information Technology Center (ITC)
University.
but
at
product
of the
Carnegie-Mellon
ITC is a joint effort of IBM and Carnegie-
Mellon University.
tions,
a
communication
Andrew was developed on Sun worksta-
also runs on other UNIX based workstations,
such as DEC VAXstations and IBM RT
Personal
Computers.
Andrew includes facilities for network communication and
shared file systems.
The user interface allows full use
of the graphics capabilities of advanced-function workstations.
the
A window manager allows many tiled windows
on
workstation display screen at one time, each a vir-
tual screen in itself.
Users can run many
applications
simultaneously, each in its own window.
3.
CMU Tutor
CMU Tutor is "an
ment"
(13:2)
developed
It "exploits the
interactive
(9:198).
integrated
programming
environ-
at Carnegie-Mellon University.
facilities
graphics-oriented
of
Andrew
to
create
an
programming environment"
The UNIX process scheduler lesson
is
written
I
•
6
in
the CMU Tutor language.
Does the CMU Tutor language
qualify as the language that
seeking?
Chambers
et
al
(3)
CMU Tutor programs run on UNIX-based worksta-
tions from several manufacturers, giving some degree
machine
are
independence.
of
In addition, according to Sher-
wood (12),
"CMU Tutor enables those with limited programming
experience to develop interactive graph-
ics
applications,
applications,
especially
without
having
educational
to depend com-
pletely on the assistance of professional programmers."
While one may question
whether
CMU
Tutor
really
meets this goal, CMU Tutor does unquestionably provide a
very convenient
CMU
Tutor
is
environment
compiled
into
for
program
pseudocode,
interpreted, and therefore is able to give
tion speed.
execu-
leaving
the
To further
ease
development, CMU Tutor provides a graphics edi-
tor, an on-line reference manual,
tion,
fast
Compile-time errors put the developer back into
the code at the location of the error.
program
rather than
Rapid program development is facilitated by
the ability to run the new program without
editor.
development.
helpful
incremental
compila-
error messages, automatic menu building,
and other convenient features, including automatic scaling
to
changes
in
window
size (if desired) within a
7
program (13).
Ease
resulting
of
programming
lessons
are
not
amounts
used.
to
that can execute them.
if
the
In order to benefit
from the lessons, potential users must
machines
little
have
access
to
Player software to run
CMU Tutor lessons on widely-available IBM PC
and
Apple
Macintosh computers enables those who do not have workstations to use the lessons.
This gives a great deal
of
machine independence to CMU Tutor lessons.
CMU Tutor does seem to provide most of the features
that Chambers et al (3) say are needed in a CAI language
before CAI will come into widespread use.
Chapter 2
Process Schedulers
The general objective of a scheduling algorithm is to arrange the pattern of work performed by the computing system so as to maximise some measure of user satisfaction.
A.M. Lister (8:104).
On a multiprogramming system, the process scheduler
is
the
portion of the operating system that determines
which n processes run on the n CPUs at a given time. The
process
scheduler
is
also
known
scheduler or the CPU scheduler.
as
the
short-term
The scheduler is called
when the running process' time quantum is up or whenever
the process cannot
minates
or
continue,
because
either
because
it
ter-
it voluntarily gives up the CPU to
wait for I/O completion or some other event.
1.
Scheduling Objectives
Scheduling objectives
include
assuring
fairness,
maximizing CPU utilization, minimizing ·response time for
interactive users, minimizing turnaround time for
jobs,
maximizing throughput, minimizing waiting time in
the ready queue, favoring high-priority
processes,
preventing
Some
indefinite
postponement.
objectives are incompatible with others.
best
batch
scheduling
algorithm
for
8
of
Selecting
and
these
the
a particular situation
9
requires determination of which goal (or set
of
goals)
in
common
is the most important for that situation.
2.
Scheduling Algorithms
A number of scheduling
use.
Some
are
it
voluntarily
preemptive:
appears,
are
of these are non-preemptive: i.e., the run-
ning process is always
unless
algorithms
the
allowed
run
to
completion
gives up the processor.
whenever
scheduler
to
a
more
eligible
Others
process
causes a context-switch to the
new process.
In interactive systems, users
trivial
typically
run
many
jobs: listing the files in a directory, looking
at the contents of a file, etc.
algorithms
Preemptive
scheduling
that favor short jobs give the best response
times for interactive users.
2.1.
Preemptive Algorithms
Some of the more common preemptive scheduling algo-
rithms
include
preemptive
priority
scheduling,
robin,
multi-level
and multi-level feedback queues.
Each of these
shortest-remaining-time,
queues,
round
is described below.
2.1.1.
Preemptive Priority Scheduling
With the preemptive priority scheduling
algorithm,
10
each
process is given a priority.
The algorithm always
selects the process with the highest
If
a
higher-priority
process
current process is preempted.
priority
becomes
The
to
run.
runnable,
running
the
process
is
eligible for preemption when its time slice is up.
If there are several processes with the same priority,
the
one
that has been waiting in the ready queue
the longest will be
selected
first
(first-come-first-
served).
The priority of a process entering the
be
defined
either
by
external
or
can
internal factors.
External factors include the user class
or
system
(e.g.,
faculty
student), the rate paid for computing services, etc.
Internally defined
priorities
are
based
on
criteria
internal to the system, such as resource needs of a process.
Once in the system,
either
static
or
a
process'
priority
can
dynamic, depending on the system.
be
A
static priority remains the same throughout the life
of
the
is
process.
In
contrast,
adjusted within the system.
of
a
dynamic
priority
For instance, the
priority
process can be increased periodically as it waits
in the ready queue, a strategy
the
a
called
"aging".
Also,
priority of a process that has recently used system
resources (e.g., CPU time) can be lowered in
proportion
11
to the amount of such resource used.
One problem with priority scheduling algorithms
the
possibility
tion: keeping a
ready
queue
is
of indefinite postponement, or starvalow-priority
indefinitely.
process
waiting
in
the
Aging can be used to avoid
this problem.
2.1.2.
Shortest-Remaining-Time
The shortest-remaining-time (SRT)
special
algorithm
is
a
case of priority scheduling, the priority being
inversely proportional to the estimated run time to completion
for
a process.*
The process with the shortest
estimated run time to completion is selected to execute.
No
time
slice
preempted
only
estimated
run
is
if
involved;
a
new
a
running
process
process
arrives
with
is
an
time shorter than the remaining run time
of the current process.
One problem with this scheduling algorithm
is
the
difficulty of accurately predicting the run time to completion for a process. Another problem is the
ity
of
possibil-
indefinite postponement for processes with long
estimated remaining times.
Because
of
the
relatively
high
overhead
of
* Peterson and silberschatz (10:121) define SRT in
terms of predicted next CPU burst time rather~than estimated run time to completion.
a
).
12
context switch, some versions of SRT preempt the current
process
only
if the remaining time of the running pro-
cess exceeds the estimated run time of
a
newly-arrived
process by a specified amount; for the same reason, some
versions let the running process complete regardless
of
the estimated run time of new processes once the current
process' remaining run
time
reaches
a
certain
value
( 4:258).
2.1.3.
Round Robin
The round robin (RR) algorithm is specifically
time-sharing
systems.
and easy
implement.
assumes
to
that
The
It
for
algorithm is simple, fair,
is
very
democratic:
it
all processes are created equal in impor-
tance.
The round robin ready queue is logically a circular
queue.
The first process on the ready queue is selected
to run; if it needs more CPU time when its quantum is up
and it is preempted, it goes to the tail of the queue to
wait for another turn.
With RR, there is no need to search the ready queue
for
the
most eligible process to run: it is always the
one at the head of the run queue.
Since
there
are
no
priorities, there is no overhead due to updating dynamic
priorities.
to
Round robin gives reasonable response times
interactive
users.
However,
under
heavy
loads,
(l
'
13
performance can degrade due to the overhead
switching
if
of
the time quantum is too small.
context
(See sec-
tion 3 for a discussion of quantum sizes.) To avoid this
problem, one variation of RR increases the time slice as
the load increases.
2.1.4.
Multi-Level Queues
The multi-level
where
processes
fall
queues
algorithm
into
~
for
processes
to
2).
Processes
queues based on this group,
and always remain in that same
algorithm
appropriate
n distinct groups, such as
batch and interactive (with n equal
are assigned to one of the
is
queue.
within
The
scheduling
one queue may be dif-
ferent from that for another queue.
In some versions of multi-level
queues,
processes
in one queue run before any job in the next queue (absolute priority); in other versions,
certain
( 10)
portion
of
queue
gets
a
the CPU time in time-slice fashion
0
2.1.5.
Multi-Level Feedback Queues
The multi-level feedback
from
each
the
preceding
queues
algorithm
algorithm in that processes do not
remain permanently in the queues to which they are
ginally assigned.
varies
ori-
New processes always enter at the end
of the highest queue, but processes move
between
adja-
14
cent queues based on past history.
The size of the time quantum is typically different
for
each queue.
For example, if there are five queues,
A, B, C, D, and E, and A has the highest
time
slice
While
the
queues,
priority,
B's
may be twice that of A, C's twice B's, etc.
time
slice
size
increases
the priority decreases.
lowest queue, E, run
longest
processes
queues
in
lower
but
in
subsequent
Thus, processes in the
least
often,
since
are run only if the higher
queues are empty.
If a job uses its full time slice, it is moved to a
lower
queue.
If it is in a lower queue and it does not
use its full quantum, it is moved
Processes
move up.
that
wait
Within
first-served,
a
except
too
a
higher
queue.
long in a low queue may also
queue,
in
to
scheduling
is
first-come-
the lowest queue, where it is
round robin.
3.
Size of Time Quantum
In many preemptive algorithms, such as round
robin
and preemptive priority scheduling, the size of the time
quantum is a factor that can greatly affect system
formance.
If
the
time
slice is large,
will not be reasonable for interactive
other
hand,
since
the
per-
response time
users.
On
the
overhead involved in a context
switch is significant, if the time quantum is too small,
15
too
much
CPU
time
will be lost to useful work.
again the interactive user will find
the
system
Once
slug-
gish.
One rule of thumb is that the time slice should
just
large enough for processes to voluntarily relinqu-
ish the CPU 80 percent of the time (10:125).
will
be
This
size
vary from system to system, and may vary from time
to time on a given system,
teristics.
Another
depending
on
load
heuristic is that the time quantum
should be 100 times as long as the time required
context switch (5:31).
charac-
for
a
Chapter 3
The UNIX Process Scheduler
The scheduling algorithm has a very desirable
negative feedback character.
If a process
uses its high priority to hog the computer,
its priority will drop. At the same time, if
a low-priority process is ignored for a long
time, its priority will rise.
Ken Thompson (15:1937).
1.
The Standard UNIX Process Scheduler
The
main
scheduler
users.
goal
of
the
standard
UNIX
is to give good response times to interactive
To achieve this goal, the scheduler uses dynamic
priorities
to
schedule processes. The UNIX system dif-
ferentiates between processes that are in
nel)
process
mode and those in user mode.
of a process depends on whether
system
(ker-
The initial priority
the
nice
command
has
system,
its
been issued to alter the default priority.
Once a user-mode process
priority
is
adjusted
is
in
periodically
the
(usually once each
second), based on its CPU usage profile:
the
amount
of
the
ratio
of
CPU time used to the real time elapsed.
Therefore, since in the UNIX
system,
a
high
priority
value indicates a low priority, a process that just used
the CPU has its priority lowered, while a
spends
time
waiting
to
use
increased.
16
process
that
the CPU has its priority
17
Once scheduled, a user-mode process can run for
most
one
V**·
If the process then requires
must
reenter
time quantum, typically one second for System
more
UNIX
CPU
time,
it
the ready queue to wait for rescheduling.
(The ready queue is usually called the
the
at
system.)
"run
queue"
in
A long user-level job must, there-
fore, cycle through the run queue many times, reentering
at
a low level and working its way back up; a short job
completes in a single time slice.
The standard UNIX process scheduler
algorithm
has
been characterized as being of the type known as "prioritized round robin" (7:268) or "round
tilevel
feedback"
(1:248).
robin
with
If all processes have the
same priority, the UNIX scheduling algorithm
same
results
as
round robin.
and
therefore
gives
the
System processes always
have a higher priority than the best
ity,
mul-
user-level
prior-
are always selected first.
System
processes are not preempted at the end of a
time
quan-
tum; they are allowed to run until they voluntarily give
up the CPU.
The higher-priority system-level
processes
are uninterruptible.
The boundary between interruptible and
tible
system
processes
constant, PZERO.
** On BSD
(10:535).
4.2
In
is represented by the symbolic
System
versions,
uninterrup-
the
V
versions
quantum
is
of
0.1
the
UNIX
second
18
system, PZERO is generally
uninterruptible
20;
system-mode
on
BSD
processes
4.2
versions,
have
negative
priorities.
The highest user-level priority
is
given
by
the
symbolic constant, PUSER, generally 60 for System V versions.
Another symbolic constant, NZERO,
default
nice
value
for
processes.
represents the
The priority of a
user-mode process in System V is updated by the formula
priority
= (CPU usage 1 2) + PUSER - NZERO + nice value
after the CPU value is update by the decay function,
decay(CPU usage) = CPU usage I
2
With each clock tick, the CPU usage value of the running
process
is
incremented.
Thus,
the absolute priority
value for the running process increases, giving a
priority,
the
lower
degree of change depending on the amount
of CPU time used.
The decay function
causes
aging
of
processes in the run queue, giving them increased priorities the longer they wait, and thereby preventing starvation.
Up to now, this paper has discussed the
cess
scheduler
from a logical view.
pro-
The actual imple-
mentation varies with different UNIX systems.
a
UNIX
some
use
single run queue; others utilize a separate queue for
each
priority.
The
run
queue
or
queues
may
be
19
implemented as linked lists, or they may take some other
form, such as a heap.
2.
Other UNIX Process Schedulers
In addition to the standard UNIX process scheduler,
other
UNIX
schedulers
have been developed.
These are
designed to meet certain special requirements.
A
brief
discussion of some of these follows.
2.1.
The Fair Share Scheduler
The Fair Share Scheduler
permit
"giving
(FSS)
was
developed
to
a prespecified rate of system resources
at a fixed cost to a
related
set
of
users"
(7:261).
Each such related set of users is known as a "fair share
group."
With FSS, a fair share
percent
of the CPU time, giving it a "virtual UNIX sys-
tem."
group
buys
a
certain
Processes within a fair share group compete
with
each other for resources, but the activities of users in
other fair share groups have no effect
on
them.
This
protects a group from the possibility that another group
might monopolize system services.
As an example of
how
FSS works, suppose that there are two fair share groups,
A and B, and group A buys 2/3
group
B
buying the other 1/3.
of
the
CPU
time,
with
Then the total CPU time
allocated to all group A processes totals twice that for
all
group
B
processes.
A process belongs to the fair
share group of its originator.
Q
•
20
Each group has its
processes.
Within
own
each
run
run
queue
queue,
scheduling philosophy is followed.
culating
the
of
user-level
the regular UNIX
The formula for cal-
scheduling priority of a process is modi-
fied to include a group resource usage factor, which
normalized
to
reflect
the
which the group is entitled.
group
usage
percentage
At each
is
of CPU time to
clock
tick,
the
factor is incremented for the running pro-
cess' fair share
group.
The
group
usage
factor
is
decayed (aged) in the same manner as the CPU usage.
Unused CPU time of one group is
the
other
groups
resource rate.
in
proportion
distributed
to
among
their contracted
Thus, if there are four groups, A, B,
c,
and D, with rates of 50%, 20%, 15%, and 15%, and group A
does not use all of its time, 40%
of
the
unused
time
goes to group B and groups C and D each get 30% of it.
As shown above, FSS allows a set of users to gain a
certain level of service by buying a fixed percentage of
the system resources.
2.2.
Multiprocessor Variations
Other variations
include
tems.
there
adaptations
on
for
the
UNIX
process
multiprocessor (MP) UNIX sys-
Since there are many different MP
are
many
MP
scheduler
scheduler
machines are homogeneous (all
architectures,
variations.
processors
are
Some
of
MP
they
21
same
type),
while
others are heterogeneous.
symmetric: the processors are equals.
Some are
Other MP
systems
use master/slave implementations: one processor is "more
important" than the others; this processor is called the
master
processor.
The
other
processors
are
called
slaves in this type of configuration.
Following is an example of
required
for
MP
systems.
the
kinds
of
changes
In masterjslave MP systems,
only the master processor can carry out
certain
opera-
tions, such as handling I/0 requests (in Associated Processor
configurations)
or
scheduling.
There
are
separate run queues for each type of processor: a master
run queue and a slave run queue, with a somewhat
time
slice
longer
for processes running on a slave processor.
The master processor runs processes from the
slave
run
queue if the master run queue is empty.
2.3.
Variations for Real-Time Systems
Real-time UNIX systems are being
developed.
They
require a variation on the scheduling algorithm to favor
time-critical processes.
Chapter 4
User's View of the Lesson
To learn is a natural pleasure,
not confined
to philosophers, but common to all men.
Aristotle, Poetics.
This chapter presents a walk-through of part
typical
run.
In
or
or
pressing
the
return
selecting "(Proceed)" on the menu to proceed to
the next step of the lesson.
gram
step
single step mode, the user controls the
rate of progress of the lesson by
key
a
session with the UNIX process scheduler lesson.
The lesson runs in either of two modes: single
auto
of
advances
at
a
intervention required.
In auto run mode, the pro-
predetermined rate, with no human
The lesson begins in single step
mode, but the mode can be switched back and forth at any
time.
Once the Andrew window manager is executing*,
when
a request is made to run a CMU Tutor program, the system
fetches a copy of CMU Tutor and of
the
program
to
be
executed (the lesson).
This takes some time; typically,
one or both
must
machines
of
across
these
an
be
Ethernet
retrieved
network.
from
other
A white window
* See User's Manual in Appendix A for instructions on
how to run Andrew and CMU Tutor, as well as how to run
the lesson.
22
23
will appear at the right of the screen and
about
half-way
down
the
display.
will
When the scheduler
lesson begins, it checks the size of the window.
size
is
not
reasonable,
dimension
depending
or dimensions are too small.
shows this initial screen.
If the
the program asks the user to
make the window bigger, taller, or wider,
which
extend
on
Figure 1
f54U!i§
10
chcscska
.,
lsched
lu,.lusrrSlgrdicbcscshtsk..IO/coOsche
... _joj
21 . xsdwcl.t
·eMU Tu1or· <nomt belna chonJtd 10 "CT' in 1988'>
PLEASE HAtE THE '-Aiiii[;("}\'J BI<;GER
•< • Cop)'Tith• CametJ<-Mtlon Univtrsll)'. 1985
Mov be used end copied freely !w tdutt~onol purposes,
bur mo)" no< bt sold wl!hout the wmten tOnJ<nl
of ComeJjc-M.Uon Universl<y .
.....
Oerunr CMU Tutor ...
IOUIIC. . . . .
>IItl
I
•.:(;
..
. I " .. . . • • •
..
~.
.
.. :.'.:: :: ~~·:·L. '·:-·:::·~ :
l
,, h .... ,....,: I;_.. •• W. ' l/
.'':-:·:·.~-~··.;·
... ·~
·~ <'
-~r
,,
Ic
..·:l
~
........~-
: .·. ;t:,c.:]~::!':·~~I : ;;[5~~, · -· :
II.
_
!:
,.:·.;~-~-~~~·;: ~~~:i·~"~l ;l i ;·_~ ;?:;; _ :: . : -~ ~ :-~:.!
·-~·>·I' ·'·' ·'
........
••
-~
.
• J .• •
•:
.;
.:_.:'j~:~~-:~ ~·~;~~r~~~~~:,~~:H;~~\*_:,_ ~
1-
:-
Figure 1.
Initial screen
...!;:..;,;.
'. l~,. •.
"
~
•
\ .
r"
•
r
.
.;. '--
.,-
..
r ,. '·
. ~. .lt~~-)~..;::·.,! :
"Make screen bigger"
N
~
25
Once the window is an acceptable size, the lesson
draws
some graphic forms on the screen, as well as a text box.
The lesson initially presents guidelines on how
the
to
run
lesson, then writes information about the UNIX pro-
cess scheduler in the text box, which is
left
portion
of
the window.
After
lower
this
intro-
text, the lesson shows some process data in the
process table at the right of the screen,
Figure
the
Figures 2 through 5 show
the first four steps of the lesson.
ductory
in
6.
as
shown
in
If the program is running in Auto run mode,
the "Proceed when ready" message does not appear.
.
.....
/usrtusers/qrd/cbcscska/ska.lolcallsc oe
sched
---.
IO:!l,.asdwd.l
10
"C'MU Tu,orM (name
bW>&
th>n~<d
THE UNIX* PROCESS SCHEDULER
to "CT In
1~66,
Process Table ( partial )
Run Queues
it) CopynV>r
tz.mttit· MrUon
Uru··c-r,:,r:-;.
1~8~
Ml)' be used ~nd c OJntd
freely for cdUtilrioni.'l
Previous
to)
no• be sold
\.lllt.holl' t.hc •.vnncn
consrnr
of ClltlltJi<· MtUon
.....
Uni'ICUif)'
-~~
--· -----
fltU'pO~U
bu~ m~ty
(:unent
t 1
Gt'1lnt CMU Tuoor ..
.....
,.
('MU Tu,or' •ni'me
btUlf chr.ns.c-d ro
in
lo36•
~C'T"
PF',I
~.-unenr
(:PI_I
PF',I
CPI.I
D
·-
Previous
1.01
-
D
I.IJ
x •chcd•
Previous
PI[)
1)1)
!)~
IOU) II
Runmng
--····· I
---·--··
-.
~
1_15
f----
---------
----
. ·-
-
·C • ('op::n~hr
C'<"mtflr" MtUon
Unr·rrsir:;. 1965
Nbr be uu:d
~nd
c.op1ed
freelr for rduc 11tion11J
purposes.
bur mc-y not be sold
·m•hou• rht 'Nri"en
conscnr
of C'Z~mes,ie· Mellon
Unl·,ersit:y
.....
Ue'Un~
•
n1ode
-·--·
I
To get lhe n,enu. hold r10'·'-Tl lhe center button. H you have 11
three·butlon n.ou;e. hold dO'·'.,, bol.h buUons. rf )'OUr mou.;e
has only tv-u butlons.
C'MU Tutor
10 ~= Knbnp
~
Ta run thr; le s·:.on
Ench lime you are oencti oo proceed oo the ne:-l slep of 1he
le-s:;on. p1e;,s r.ETI.IP.r~ 01 s.elecl. -,P10ceedr" fromlhe n.enu
if yoU! are rn :.wrgle srep n•ode. The le~:.on :.tar1s up rn this
> fl&l
II,
You may select. ·ALrto run" from the rnenu The program 1•.;!1
then proceed by rt;ettat a predetern,ined rale.
Proceed ;•.>hen ready
--·
_____ ..
_-··-
U~ll"l'~ ~''9'~1eor~t1bHI~m~rt ofAT.~.T
L...
-- ·-
Figure 2.
How to run the lesson
N
0"1
obcsnka
10
2.1' 1
10
/u•r/userslgrillclicscsko/ska.Jolcal/sche
lsched
lo
tl"twd.l
"C'MU Tutor" iname
bt:ltll th11ns.c:d to ·cr~ in
THE UNIX* PROCESS SCHEDULER
19881
Process Table ( partial )
Run Queues
• <) C'Op)'t1Jhf
C'emt£1t· MeUon
Uru·-·euirv. 1~8~
Moy b• usrd ond topird
freely for cdut lltlont-1
pwpos.e-s.
but: m1y no• be sold
without rJue wntten
Cu11ent
Previou;
•n
.1
I
tonstnr
of C'otntJ!t·MtUon
Uru~:euiry
,:.,,
~
Ot"lnf C'MU Tutor
10
IIQ
22•11
1)3
X tlhtd r
----··-
r--------------+--------------~
Running
1
Pr e··/IOU ~
PJo
I Pr.J
D I I
l
J
I
-~
Previous
D
---j
I
1----t----+---
II
C'MU Turor· •name
btU11. th~nr.td fQ • ('T" in
j;
~::wr enr
,:P•_,-, r·F,--;y;·;--
j
j
r--------------+--------------~
'-''L_______ _________
_~
198(;,
•c , ('op~.Tlth'
C~<mtt;lt
Mrllon
U1U~'t>t$JT}'. l~E:'
MII)" be used Md t opaed
flttl)' h>r rdut >~onol
In a hme;hanng ~y5tem. lhe process s.cheduler i5 the part
ol the ope,aung sy5tent l.hat. detetuline:; i 1,htch of the
runnable proceBe; \•~II be allocat.ed rhe CPU
purposes.
but m11y not be sold
widtour t.he •mir:tcn
Uw"tni')'
J
- I
-i
Pres; P.ETtrr.rJ or ;.elect ''IProceedr" Iron, the ruenu ro
continue rlrn ·:.rnyle :.tep mode.
Ot>"ti!>l C'MU Turor
io 2: •ocnbap > llal
io 24i "'l .. l
nrdwnp ;. 1!1,3
""
·i
____ j
The scheduler r:. called \1:hen the current proce:.:. canner
conlinue. ll;hen it;, time quantum i;, up. ··•·hen rt rern•rnate :;. or
11 ·hen a pr·oce :.s \•lllh
a higher pnorrt)· rua;.· hav·e br.corue
el•g•ble to 1un.
tonsenr
of C'omtJ!t·M•Uon
ur 11
-- -----j
--------· i
To run automelicoi!J·. select·· Auto run" frorn the menu
~--+-----~-
Proceed ·-•tten ready
I
: r:.
a 'E'~' .ter~(l 11 :.•J~>ru.:.rl
I
~
I
(•f ..... r.;: T
1--
Figure 3.
What is a scheduler?
N
-.J
,.
cbcscska
-
10
21!
.....
sc 1e'
· CMU Tmor" i.nnnr
beut' c.hMs.cd to ~cr· 1n
THE UNIX* PROCESS SCHEDULER
1~66'1
<0
10
·-·-·-·
X St'twd.l
Unh•ersiry,
1~85
Moy bt llltd ond <opitd
freely fur educ.•tionlll
Process Table
Run Queues
C'Op\1'1Jhl
CameJ.it:· MeDon
Pre·-:rou·;
CLUrent
Running
til
wMOUI <ht wrifltn
c.onsent
ol C'om<pt·MtUon
.....
Un~versity.
Gt"Ul~ C'MU
10
I II
:.!
.....
<:u"~'~
Pr.l
i'PI I
I
J
~
Previous
'-'
~
j
D
I
·j
I _I
C"MU Turor· 1n11me
btm~
t I
'.I~
x sc.hc:d t
~ .PI.I
IJO
1_1~
Turor
P~l
D
PW'JJOIC:S
bur mty nor be sold
Pre~:iou:.
P!D
1par1ial)
ch•n(.<d •o TT" in
-I
1_15
1
1988·
C';:~rnrtJt' ·Mellon
Uru·.·rrslfi'. 1~6~
Mll)' be u,:cd find topitd
fret I)' for educ. <•tJonlll
·---
The IJtJIX proce;') scheduler use;. a prraritced round·robrn
schedulinR algonthru
tr all proc.e:.:-e·; ha>e the ;au•e
~norit{.. t.1e. ;.chedullng r;, round robrn: ot.her·.•,r:.e. the
ighes -pnortt; react, .Proce:.s run:. fir:.t
In the t_IIJIX
o;yo;.tem the lllyhe:.t prrontt proces:. hn:. tile la·.•,e:.t prrorrty
value
purposes.
bur mlli. 1101 bt sold
v.rithou' rhe ·.vntttn
c. omen•
of C'llimtJ)t· MtUon
-·
Uru·'tnlry
-----·--
Gt~\'- C'MU Tutor
ro 2~ ~ unlump >
f'IJ
.
.. J .. .a
mcnunp .. fi~~
to2~1
Proceed "~·'hen read"/
I
.....
l_ltU
1
~lf'<JJ:II!"tl!"f11t):i.l'!'n•;,rl
-.
- ----·- •
··---~
10 :!~·
Figure 4.
i
·-
ltttt
ro!•• .. l"'l
mdwnp • fit:
I'
I
!
• c.'> C'op~Tt~h'
OfAT.?.T
The UNIX Process Scheduler
N
(X)
sched
~
-
.....
10 Zl) •Ktwd.t
"C'MU Tutor" ~·nMnt
brlnt chonr.<d •o
·rr· In
pwposes.
bul m•y nor be sold
v.1T.hour the writ?en
c.onsenr
.....
of C'orntJ!t· M.Uon
a,.,.~
Uni,,etsky
userstgr<Vcl>cscskat~~c~sc
Run Queues
C'MU Tu•or ...
Pn!v1ou~
Current
tu
.....
Running
Pre··JIOUS
PI[)
PRI
CPt.i
Cwrenr
PF:I
CPII
D
tl
Previous
1_11
D
~
1_1-.1
"C'MU Tutor·
~nNnt
b<Ul' <hon~rd to 'C'T' "'
----1
IJ~
-·1
l~oa,
- -- I
~ t) C'op;Tl~h'
I
--·i
C'lllmrfJC Mellon
-·-·-· ·- _j
UIU''thl')', l!lS~
Pwby be uu:d and c.opied
freely for e:duc.ttrjont~J
purposes.
bur
mi.\~-
A part of the proces. table Is ~hou,n In the nght portion of
the screen
The CPtJ value Is based on the amount of
system 1e:.owces that a process ha:, use_d in the recent
past. A u ;ea-le·Jel process prrortty (PP.I ~ 1·5 related to 115
nor bt sold
'.'JJthour the wnNtn
CPt I i.:alue 1he proces~ ID number tPI H 13 not actualty
stored tn the process table. 1t. is an mde:: into the table.
(Onsrnr
.....
ot C~mttlc: Mc-Uon
Un~vrrsir;
t. ~you proceed. \'/Btch while the values are filled in
ar"'"t C'MU TU'or
io 23 ·, U'nlwnp > IIIJZ
102•1 "2"l
st rdump :.o rit.~
io 2~)
io 2~> "l"ol
nrdump ... fit4
io :'.0\ "oi"S
scrdwnp :- ftl~
lo
l_h)
1_1.~
X Slhtd ~
-- . ---
Process Table ( partial )
1).":
io 2:!.lll
te
THE UNIX* PROCESS SCHEDULER
!9CSo
\C) C'opyri&h•
('lltn<J!<·MrUon
Univrrsity. 198~
Moy be used and copied
lrrdy lor rdu<&tion>l
tusr
II.
I
~
1--·
---- - - - - - 1-· --·----·-· -·------- -· -----
-1
·- 1
j
I
~
Proceed 1•A1en ready.
IJI~t ..
t'> 1 reghh!•red
hadent~rt
or ATJ. T
f-
Figure 5.
·--
The process table
N
1.0
usr u.. rstsrdlcbcscsko/ska.lolcallsche
sched
------·
.....
10 :! 1) • s..•twd.l
10
...
TMU Tuoor"
THE UNIX" PROCESS SCHEDULER
(RIInt btini:
<.hanttd to • C'T" m
1968•
Process Table ( partial )
Run Queues
I<) C'opyngh•
C'arntS.It· MeUon
Ul'llvtrmy. I~S~
tQ
tdUt t'fJOIUIJ
PW'JlOS:U
t I
bur may nor be :Jold
\Whour rhe ·...,tten
I_IQ
(011St'Jll
.....
of C'amtpt M.Uon
U!'uversl')'
Curre"nl
Pre viOl IS
hhy bt used l'nd
up1ed fre()y fo1
G
Previous
1.11
D
u::.
l.n
Otn:int C'MU
Tu'or
io l~) KI,.D'Ilp >
1116
~
Running
10
11
1Z
13
14
15
r--lli
17
I)
f---.18
1.15
19
A pa~ of the proce» lftble is ;hll'''" in ohe right por11on of
the screen
The CPI.I value i:. ba:.ed on the an,ount of
5't5tem re,ource~ that a p1ocess ha:. u:.ed in the recent
pft-:.t A u:.er-le~.,el process pnor~ty 1Pf.l1 1;. related to its
(:P•.• value Til~ p•oce:-'3- l[i mnnbe1 tPit!l 1; not actual~;
')lOied Ill !he prate~~ lfthle, rlt:. 81111lde .. tntD I he 18flle
C:llrre"nf
Pre·-liOU<;
PID
PF:I
CPI.I
PF:I
CPI_I
if-u···77
35
8Z
8Z
25
34
.n.~
4L~
~:'L~
26
8~ __58 :.:
2!i__ L_
79
38 ____
8
25
-j
j
t. ~ ).-Ou proceect " . atch 1•.-hile the ... ntue:. ftre fillectur
~
Proceed when oeady
Utll .. ,,
!ol~:>ghle<re>dtr~·lem31t
OfATtT
~
Figure 6.
The process table, filled in
w
0
31
The next steps of the
priorities
and
the
these screens.
displayed
at
lesson
run
talk
queues.
about
process
Figures 7 and 8 show
The process identifiers (PIDs) are
the
logical
processes in the run queues.
next
positions of the associated
See the upper left portion
of Figure 9.
Figures 10 through 13 show
screens
in the lesson.
son gives
the
processes.
user
an
the
next
sequence
As shown in Figure 14, the lesopportunity
to
add
or
kill
At this point in the lesson, the program has
entered a loop that continues until the user chooses
quit
the lesson.
portion of the
several
cycles
algorithm
to
This is the real scheduler simulation
lesson.
through
Figures
the
15
loop.
through
The
updated each time, showing the results of
decay
of
to
21
show
displays are
applying
the
the CPU value and of recalculating
the process priority (PRI), and indicating the new locations
values
of the processes in the run queues.
and
Occurrences
run
queue
during
in the text box.
locations
are
The previous
also
shown.
the particular time slice are noted
H¥1Ji I.,~~~~!.'!______
~10 ~I'. ,,•twd.l
____ _
!tiSr/u~!.':~.<!'~~~~csk""~~~~o/c!Usc!_•e____________ . _ ·--· ___ _
10
CMU Tu1or
THE UNIX* PROCESS SCHEDULER
·n~mt btUlf
tht'"~ed
ro . cr in
l~BS•
Run Queues
' ( ·, rop•:nfhl
C'~mtf.l~
MtUon
Univeua"··
1~8~
M•r bt u:c('d ~ond
top•td frttlr for
educ:-I'Jorul
purposes
bur mll'r nor bt sold
without t.ht •J:n"tn
COilS tnt
of Ce.mtt.it· MeUon
UtU''ti'Uf}'
Gt""'t CMU
Turot
10 :U • k"nlwup >
io:!::· "6•7
st rchunJJ • fif.-
11&6
.,
J==
Process Table ( partial )
1--- •. :urre~-==
Prevtolr;
•n
l_ll)t:==--+-===--
'-''L-----------1r---------1
'-'~
1_1-;t
--
~
Previous
D
Pre·. . rou5
PI[)
'-'~·
--------·-----The unollt·, tPf~'-' anCI cP•.' ·v·alue:.to• allreacti proce:.;e~
zue adtu:.recl penod•cal~,.. t;·prcall; once each ;.ecor'ld Th•:.
recalcutarron at ..·alue:;
~--~J12
13
14
15
_]6
,u
:~~~~'i"v:l~;~c:,~; ,~,'~'rit~!J :'~ :~:~~~n,:~e ~~·;.~·~;~~~:.ci:'.!:?P~'_f ~~~~
u ;ed. 10\•·-errny the p1 oce-; ~ pdonty Th•:. en ~lll e:. that CPIJ
bound proce:,s.e:. .....,11 lUll les:. fr~quent~~· !han In bound
one:;, g1ving good 1e :;pon :;e titr•e to rnter active pr oce ~ :.e;
Proceed \1ihen 1eady
~r('r~t,l('1!2'dtla•:h!lrtl~l·
(:PI
Current
I
P~l
CPI_I
11
22
IL____J_4_
~L_f~_
~~~-
82
44
-~~-~li-
89_ _5_!:l __ _
17
25
5
19
~-
7~~-
r----+----t-----t----
··---- - ·--
c.au~e; proce~:-e~
to chang!!' to
tugher pno11t1e~ a~ they ;ta-1 '"the read·,. ;tate E·.:entuatt-1 .
~eP~~~;d':~oi~e~i,,~,,, ana1n the h•ghe;..r pno••':r· a,,d •. be
UIJI. t·;
P~l
b.!L _
~iii
I _I..),
....
Running
.--j
---]
I~
ofAT.!,T
La.
Figure 7.
Priorities
w
N
il·!¥1fiiM, !••!·~~-
l-lJo;! I • • st.'twd.t
__ --------- __ _
~':.!_5rlu!_ers~~~~_b~!_~~~~~-!-1o/~~!.(~~~!~ .. -·--------
IO
CMU Turof
1n11mt btmf.
THE UNIX· PROCESS SCHEDULER
t.hans.ed 'O • CT · in
1988·
Run Queues
Process Table ( p<111ial )
'<> C'opyr1Jhr
C'wntflt MeUon
UN"trsitr, 193~
Mt}" bt Ultd. N1d
tDpltd frttl? for
tdU(f'IIJon.:-J
P\lfl)OSC'J
bur m11r
no~
\\it.hOur
be sold
rJ1t \VTI"tn
(0hU'J1'
of C'Nntt.it· MtUon
Un•~·~rSII)'
Ge•'inr C'MU
Tutot
io :!:! • k"t*unp >
2:\ .. , .. 7
scrd1unp • fiC
10~4, .. 7•1
«rdwnp .• firS
10
'"'
j.
~
t
Pte~-~~~---·- --1-----··CwtP.I''
n
----
Running
r=riD
G ~H
---------+---------~
l_lit====-----1-------~==J
1_1~~---------+---D -~~
1_1')1~-------t--------i
w
~i!
___
t I
I_IOl•
Previous
~
1_1~.
j
~·
-Pi'!~·;~~,- r;~r"''I;~=J
-;;-~jt_j
~i -- ;:~-i
-!!=--:: ~-I
·~~~=:~ ~
r------------------------------------------,
In the uppe1 left pottion of the scteen ate the pnon•tecl1un
8
1 11
~~~:~u~L~el;:; ~~~~~ ~~~~~~~:~u~~r : Fa~ e 1 ~:c;'Y'~, ~:~~ ~~~~
tep•e:-entl emel·le·.,..et puorities.
The te•r~an1ulg ntn (llteue:, tlabelled t_t(l lluough 1,1~" contatn
u~et te~;elllln•lRble ptoce;ses.
The htghe:.t u:;et·le·.. el•un
quelte •s the one labelled 1.10
..:. ., iOU proceecl. ·''H'Ch ·.•,hile the tun queue; Pne flllecl in
...
1---+-----1--- ·----- ·1------+----~-----
t----
1---
+--
-----
i
-l
--j
-- I
Proceed -,•.1lenteacti
Llf41
r-----t--+--~~
1'!- 3-II!'I~IS.1E'I~·J ll~·l~lllifl. (If ~r.:. T
I·
Figure 8.
Run queues
w
w
/usr userstgrdlcbcscskatska. o cause te
sc ted
_ lo
·----·--·--.
.....
ro 21· • sdwd.l
"CMU Turor"
THE UNIX· PROCESS SCHEDULER
(hNnt btU1f.
thonJtd •o .CT m
19SS·
C'op)"rls,hr
C'1111rf,it Mtllon
Uni.·:enl""l'· 1~05M•J bf' und c-nd
top1ed frt-tl? tor
tduc.p'Jon.-.1
Process Table ( partial )
Run Queues
Jt.\
purposes.
bur 1nJty nor bt
~old
v..irhour rhe- Wll"'tn
con~tnr
.....
of C'lll1t(it MrUon
Uru··rrf.:rr,·
Or"llll C'MU
Turor
,..,
ao 22tscr*unp >
10 ~='
. ,. . 7
Previous
Cunent
Running
19 17 15
t 0
------------·
12
II
G
l)t)
Previous
'-''
1.1.:
1_1)
18-1l
1.1
1413
D
71
77
35
10
_11
-----
CPI.I
22
3!__
2~R_4~_!I~~-
~2
~13
14
,__)5
_J6
-----
10
fo
Current
Pr:l
(:PI.I
.~5--~L!l~Q.-
25
79
25
r-1~,_J9
nrdlunp · fig ...
~·· •7•1
Hrdump • fts,a
1025·····
strdl.unp • fit-0
Pf:l
r--E-
16
I _I';,
Pre··nOLI:.
Pl[l
5 __
3Q._
8
·------·
----· -----··-
-
·--
In the upper left por1ion of the screen rue the p11o11tt:ed run
~!~'guc~,;e,;~'; ~g~~~ ~~~:e,~r,~"~~r8lrag':,7:c:'~ ~~~ ~;:~ ~~~
1
reptesent I emel-le':'el pnonhe-s
The rernlllf11ng lllll queue~ rlabelled '-'0 through 1. 1":.r contatn
u:.er-le,.tel numahte proce::-:.e) The htghe:.rtr:.e,·le·~·el run
queue t:- the one labelled 1.10
---·
A:. ·;au proceed. ·.•:atch ··•ihile the run queue:. tue filled,,
II,.
---i
Proceed ~·then read·1
-111~1
I'
~l"'rtt·li!'IO:.•IIr~·l..-•n~l·
,-,11<\f.:.T
1....
..
----
Figure 9.
Run queues, filled in
w
"""
10
21• •
.....
.
usrtusorslsrdlcbcscsh/ska.IO/caUsc ••
schrc!
'CMU Tutor"
(nomt bting
chanted to • CT in
1988)
«)
... io
THE UNIX• PROCESS SCHEDULER
Process Table (partial)
Run Queues
Copyr1th•
('arntiJ<· MeUon
University. 198~.
May be wed and
tOpled frttly 1\>r
eduttlionN
putpoou.
but ma}• not bt: sold
without die wntten
connn'
ol C'omeste· Mdon
urove"i'Y
.....
Turor
22) Knbap >
"6"7
nrdwnp ·.• fta7
"'1 .. 1
sudtunp .• fit8
10 .:!~· ...... ,
oudtunp ·• fif9
ia :!,~1
10 241
Previou~
I
""
r::unent
19 17 15
12
(I
11
Running
~
1.'0
Previous
Ul
u:
18 11
14 13
16
U3
OetUngC'MU
10
·------- --·
~t.•twd.t
1.1-1
1.1~
D
Previou:.
PID
10
11
12
13
14
15
16
17
19
19
P81
CPt_l
Cwren:.
P81
71
CPI_I
···-z-z-
7]____1L_
35
92
92
25
99
25
79
25
2~~L_
4~-
2L_
59___
~-
3!!_
8
--
IOUi•"9"10
queue~ :.houn actually repre~enr~ i!:i
The Queues tor '5 PIIOIIIre-; have been
pictured as a -stngle queue lor :.1mpler repre:.entalion. but
l.he proces;es ;elected to run ate cho;en b'; lheu actual
Eftch ol the u'!oer-le·-..·el
'"dtunp .• figiO
j.
priont·; values
prionty value.
Select "Hare detail'!'" now trorn the menu II7'0U '· 1181\1 n•o•e
inlo1 11•ation about the scheduler siruu1a11on .
...
-
..
J
'
-~
l
Pt oceed 1onen ready.
I
• UtJIY. l'i a rl!'g•~tered hadttntatt of ATe T
-
~--
Figure 10.
Priorities per user-level queue
w
U1
1
1
§rl@ tMq Jschrd
···- __ ?
lusrlusenlgr(Ucbcscsklllska.IOicaUsche
.....
21.' • sdwd.l
10
·rMU Tu,ar·
!!UIInt
THE UNIX* PROCESS SCHEDULER
bttllf
thang<d <o • CT ••
1938·
Run Queues
Process Table (partial)
«) CopynJh<
Camtl)t· MtUon
Uni"tiSIT)', 198~
Moy bt uotd Md
tDpltd frttl)' for
eduun:ion.N
pwpo'ts
but moy not bt sold
wilhout lh• written
consent
.....
of CamtaJt· M.Uon
U111VtUity
Gt"lng CMU
Turor
io :!:!) IC'nlunp >
io ~:a "6"7
oudump >fig?
io 2•} "7"1
mdump :• figB
10
:!~I
rla6
Previou!>
I
Ctnrenr
19 17 15
r--------------+------------~
121
II
I0
~~
~
I
I
--1
r--------------+-----------18.111
l_l31~----------1f--------,413
'-'~'
14131
161
1_1~.
Running
Pl[i
f10l
L.:..:J
Previous
D
t
L
Previou;
PF:I
CPI)
10
11
12
13
14
15
~6
~~19
Current
PF:I
CPI)
71
22
34
35
23
82
44
82
44
25
26
8958
n
I
I~~~
25
8
••• ,
swllunp • fit-•
1026• . ,.... 0
mdwnp • fillO
The l ernel-level crueue-s c.ontain proces:.e3 welting for son•e
e\·ent The p1io•••.•~:. of I ernel-level p1ocesses ere based on
t.he rea:.on tor l 1..a1tang.
ao z;, . . 0 ... 1
sudtunp ·• figll
~
The hoghe ;t r eonel·level queue. labelled I o. contains
proce;.;e;. \':ai•rng at en unintenuplible priolity.. The;e
p1oce·;;es are ~·rattma for event.=- such as dtsJ 1,0
completion. the availabiliTy of a free inode or bulfer. or for
s\•:appu1g In tlli:. hupletnenta•io•l proce;;e:. in this queue
ha·.,.·e p1101il't ··lftlue:; hou• (Ito .:o:.
""
1----+------+----.;
The other leonel-level queue. labelled I I. contnin;
ptoce:;:.es \'Jl'liltng "' an mte11uptlllle pliolit·,. The;e
processe$ are ·•,a•11ng tor event;. hie rr,· 1nput 01 output or
a child e:-:11 P•ocesse·; in thts. queue ha·.. e p11orit;- values
110111 ~6 to 59 an th1;. trnpletuentatiOil.
Proceed \'·!len react;.
IJt'l : ts .J tt''J•'i-te•ed lli!llll?u•~•• of AT~ T
f--
Figure 11.
Kernel-level queues
w
0'\
scl>ia- · - - -
·--~ --~· --~-----rirsrll'!!rsi!Jrdlcbcscsk~k•.IOicaUs~•-e_ _ _ _~~----- .. ~---··--
.
10
to:!.l.•&sdwd.l
"CMU Tu,or
THE UNIX· PROCESS SCHEDULER
tn11mr btU1f
thongrd ro
·cr- rn
19&&,
Process Table ( pa11ial)
Run Queues
1t 1 C'op,'mJh'
I
C•meF,It· MeUon
UN"tUit",'. 19S~
hhy be used lind
Ptevlotr:.
:~I
loprrd !Jr<l)' lor
educ11rional
putpDIU
but m~;· not be sold
without the ·o~.ntttn
CO!HitiJ'
I
I
Cunent - - - -
~---![!
__ .!.'~ e '~\1~--h :Y~•·:•~-- I
P~l
~:I
I
I)O,r::::==----i-------===J
I
1917
U111vruiry
IX
____
.,_
Gr11ing C'MU
Tu,or
lo :!:!. 1 IC'nlump >
1).3
Ia 2:) •6•7
sc rdlunp > fi~":'
io :!-4> •7"1
1.1~
"-II
.r
lle6
I
I
~
16
10
2-C• "11"12
sudwnp .• fii-12
If at rtrrJ time the number of proce;.:.e:.
111 B queue e::ceed
the :.pace for clel>tcllng llleru. the acldlttonal proce:.se:. v.,u
not. be sh01•-n. alt1ough the-; are 111 the queue They ·. •,ill be
displayed a:; roou1 i;, heed tnthen queue.
?L
77
1
.... I
182
82
I 25
44
26.
~ I
I ;;
-B
-+
'w'ou can add a o• oce:.o;, to the schedule• :.m,ulahon once the
;.checlule• heg•n =- to Hill To do :.o :.elec• .. t.rld llroce:.;. ..
ho•n the 1uenu ··•Jhen you ~ue told thai 'iOU "'"'~ ad~l
g:g~:~;~s. ·wau can relltOve a ptoce~~ by :,electiny .. ~til
CPIII
I,.
34
2~--
scrdtunp • 6g6
io :!51 "1"9
H rdl'unp • fi(,!'
10 20· "9"10
mdump · ti(.lO
10 2:'. "0"1
nrdmnp- • flt.ll
+-~~·
I 35
18 11
------+----·------1413
CPI.I
I
L
...
lllrl---------r----
of C'amrgrr· MrUon
•v
~L
~~- 5~=:1
-
------
-+-- ....
r-----1-----t--·· ----
.
.I
--!
~Ir-- --=r=-~·--- ... j
I
----+-· ··----~--···-.
1----+
-- ... i
--f----t------+-------- .....
Ill.
Proceed ''men ready
UfU.'
J.-
I
I
I~·
dlr€-IJI",Ifred b 3:•1t-tltdllf of AT.!.T
II
Figure 12.
·---
Adding processes to system
w
-.J
sched
-~'
usrtu .. rslgr<llcbcscsklll'sko.lotcoUsc 1e
.....
10 2.11 ..... twd.t
"CMU Tmor"
rname btln'
thonaed 10
In
THE UNIX* PROCESS SCHEDULER
·cr·
1988~
Process Table (partial)
Run Queues
«) CopvnJhr
Camtalt· MeDon
tcfu(lf10n~
purposes.
bill moy nor bt sold
wl<h0111 rht wrmtn
consenr
.....
of Cornell•· MtUon
Unlvtrsi'Y
Tutor
roZ2)te....... >
lO
2•) 1"1
1111
19 17 15
12
fO
'1
uo
'"'
Running
G
Previous
1.11
1.1:
18 11
1413
16
1_13
OtrnnaCMU
io 2'Z) .,.,
"'dump' 6&7
Currenl
PreviOlt:,
Uni·~Vrity. l~B~
May bt uotd ond
topitd fretly fur
1.1
1.15
D
PF:I
CPI.I
beJt"
The scheduler "fill now
to run and schedule
processes lmpot1Rnl events uring the proce:.s e:.;ecut.10n
10 271 .. 0'"'1
and scheduling vnll be poin•ed out as lhe-; occur.
scrdwnp ,. Ball
io
22
77
34
~L.....n-
_ _44 __ .
-~2
fl?___AL_
25
89
25
79
25
26
ti!5
39
8
-· -----
20· ., .. 10
nrdump > figlO
:.a, ·u·u
--
-·-·
·-·-
--- .. ·I
··-
Watch the rl~t t-Ho columns of the process table as they
are updated. hen the newr un queues "·'" be sho··•l
nrdwn1, · fitl!
10 29,1
PF:I
71
10
11
12
13
14
15
16
17
18
19
sudtunp , 6&8
io 2~' •a•t
n rdtunp • 6&9
10
Cur tent
CPl.!
Ptevious
PID
•l•J
sudwnp , figl:
I
I
I
-··-
j.
. .......j
Proceed v4•en ready.
II,
Llt.,l ..
IS~
t@'gtstered ttartemarl of AT.! T
,_
Figure 13.
Scheduler will begin to execute
w
CD
1-
usr usofilgr<llcl)c scikalifiTofcalTscne
·~·<I
.....
10 21) IIL'fwd.l
"C'MU Tutor"
(nome belnJ
dlanaed to "C'T" ••
1988)
10
THE UNIX* PROCESS SCHEDULER
Process Table ( partial )
Run Queues
(<) C'opyr181K
C'•m•&l•· MeDon
Untvemty.
Previous
196~
Mt)l'bo u,.d 1nd
topled freely fat
I 0
educ.ttlonaJ
11
pwposes.
but may not be sold
Wit:hout Yhe wnrren
c.onscnf
.....
of Camel)•· McUon
Uwvt"rsity.
Tutor
lo 221 ..,......,., >
1116
:!:) "6"7
19 17 15
1Z
Running
~
1_1(1
Previous
1)1
t.t:
18 11
1413
16
1.13
Oe'lln& C'MU
10
Current
I)
1)5
D
Previous
PID
f--10
r--11
1Z
13
14
15
16
17
18
19
PRI
(.PI)
Current
PP.I
CPI)
71
zz
7~-
35
92
z.~-
'!L
9~_4.4_
zs
89
zs
79
zs
2~-
58
5
38
8
sud1unp ·• 6J7
ia 2•) "'7 111 1
sudump •• 6gB
10
2~1
.. ,,.,
t:c. rdtunp -.
6~
1o :!til •t•Jo
urd<unp .• 0&10
102:"•
"'0"1
sudwnp • o,ll
io 261 "ll"U
oudump :.• 0&12
lo 29: "'2"3
sttdwnp ;. o,t:
•a :m "3"4
sudump " 6&14
If you l'l<luld Hie •o 8dd a process no"'. you may seleci"Add
process .. from the menu
~
You may remove a process by selecting "I ill proce·;s··
-.
Proceed when 1eady
'UtU::
IS
--
a fE'91SieiE'd ll3d~m~l· of AT~T
Figure 14.
Can add or kill processes
w
1.0
sCii~
usr usersl~c~aJOlcallsC:he
--
.....
10 ~I' 1 ~t.•twcU
lol
I
"C'MU TU1or"
THE UNIX* PROCESS SCHEDULER
(nom• btDl~
thenaed •• TT" In
19881
Process Table ( partial )
Run Queues
(<) Copyril)lt
('amept· Mdon
Untvctsrr/. l!l8~
Moy be ustd and
copied fr••t; for
tduCtfJOnt'J
purposts.
but moy nor bt sold
withou( the v.n"en
consenr
of ComtJjt- McUon
.....
Una''ttsi')'
Turor
I021)k"'*'mp>
.,.7
Current
to
t
I
11&6
1_10
Previous
1.11
D
1):
18 11
1413
16
1_1~
I _II)
Pre··. iOu3
Cune"'
1
Running
19 17 15
12 <.. ~
1_1':
Ot!Un~ CMU
10 ~:;;)
Previous
PID
PP.I
CPI.I
10
11
12
13
14
f---l5
16
17
18
19
PP.I
(;PI _I
71
-~
77
~L
n_
35
82
82
25
89
25
79
25
nrdump ·.• fig7
ia
•7•1
sudump :· naB
44
44
26
5Q_
~-
38
8
z•·•
io 2S) .,.,
sud\unp ·• ftt9
io:!6)
•J•to
strd1unp .• ftglO
io :! ..... "O•t
sud\onp . fig 11
1o2e.
:.. pr ace'S ~e:; contplete 1/0 and ,.,,11 reenter the tun queue
·u·u
lI
--
--
I
nrdlunp .• 6tl:!.
io29· •l"l
mdump · fig!:>
•J••
_-_j
1o:H1 •4•5
--
10 :;o,
strdlunp • n,_u
sud\onp > fig I~
J..
P10ceed oo!hen I eady
II,
Utll ..
La.
f - ' - - - - ----
r·~ ~lf:'(~I~·II!IE.odll.:.•Jem~rt
OfAT8T
-
Figure 15.
-
----
----
Process completes I/O
~
C>
usr usorSIQrdlcl>cscskilska.io/callsc ••
' sch•'!
10 ~ 1.~ I ~t.•fwd,,,
.....
10
"C'MU Tutor·
m&mt
thons•d ••
tt)
THE UNIX* PROCESS SCHEDULER
beu1~
-cr· m
1988>
Copyn~ho
Carnttlt· Mdon
fO
edut trionol
11
PUOJ>O•ts.
but may nor be sold
v.ithout the \1,:nn:en
(Dnstnr
.....
ol Camtglt· MtUon
Unlvwlry
Gtrtin&CMU
Turor.
io:!2)K........,>
~::I
.,.7
fla6
Cunenl
P1evtous
UN\'tUI'"l· l~S~
Mty bt ustd ond
topotd lrttly lvr
10
Process Table ( partial )
Run Queues
Running
19 17 15
12 <..
G
1.10
Previous
IJl
IX
1_1')
IJ~
1_1')
"rdtunp :,. fig7
io 241 •7•1
scrdwnp > ftg8
10 2~, ..... ,
nrdtUnp • ft¢'
10 20, "t•to
"rdtunp · figiO
··--·---
Process 10
cornplete~
18 11
1413
16
------
D
Current
Pre··nOtJ.;
Pl[l
10
11
12
13
14
15
16
17
18
19
P"l
,;p;:;- -pr:J"-;:;;;:;-71
22
77__H ___
35
~~
44
82
82
44
25
~~
89__:;L_
25
5
79
38
8
25
rts time quantum
·o·t
mdtunp ·• tigll
io 28_, •u•u
10
2-)
n rdlunp .•
11~:,12
lo:!~h"l"J
""j
Hrd\unp :• fitlZ
IQ ::01
·-
AJA ..
I
mdtunp • 6gl4
10 :I' "4"5
mdtunp ·• ftg!S
io :2~ jlls . . ,
JtrdtUnp :- 6gl6
I
----1
Proceed when ready
~
Utll:: IS
are-gr<;1E>r~dlr.)1~rn~U
OfATtT
f.-
1- -·
Figure 16.
Current process runs
,0.
......
' sc 1!<1
.....
:!.1 • I "twd .•
10
/UU
userstgr<I/CilCSCSki/Skii.IO/C~USC
I!
10
"C'MU Turor··
(name bru11.
<.honsed to
THE UNIX* PROCESS SCHEDULER
-cr· 111
1988)
Run Queues
Process Table ( partial )
1<) Copyrif)lt
C"tmts,ie- MeDon
Ura•ersit;·. 1!'8~.
May be used ond
topiod freel7lor
tducttian~
pw-poses.
but
m~y
not be sold
'41iliour the wnntn
canstn(
.....
of Carneal<· Mellon
Univtuil:}'
I
Prev1ou$
Current
19 17 15
t 0
12 <.. ~
t I
1_10
Previous
IJI
IJ~
GeT1lnaC'MU
Tutor ..
io !2lknbnp ,.
IJ3
18 11
1_1
14 13
•6"7
• 6C
io~•~ "1 ... 1
"'d•unp • 6J8
1)5
10 ~:I
...
Running
16
D
(:PI .I
PP.I
io
:!~·
~-2
13
14
15
16
17
18
19
"u·u
1a :!B\
Htd10n1J •
Hs.l:!
10 :!~' .. 2"'3
sudwnp > ftgl:
10 :;o, "3"4
JC rdwnp
;:s
;:~_
89
Z5
79
25
58
5
38
8
...
"1"9
io:!'7• "O"'J
!t<rdlunp • fitll
CPI_I
3:?_?L_
82
44
44_
BZ
~----
--!
(udurnp ·, fif.,O
"9"10
:ntdlunp •. 6t.10
PF:I
__ .JQ__ f - - - - - · - Z.1 ___?? .
_11_ ·------- _?]__~~-
st rd•unp
10 ~0 ·,
CUI rent
Prevtou:.
PID
Th~ Oe"l''
1
CPIJ and priority 1PP,I) value-;. are celculnted for all
read'/ ~toce:;.,;e:. The -=-chedulet then e::ecute' the
schedu•ng alg011lhrn. ·>elecring the ne:·:t proces~ to run
.I
·==J
------
A~
it update> the p1oce:.:.rable and queues.. this. -:.imulat1on
;.aves the pre···•ous values. so that you can contpiue them
I
..•.;lh the ne-.•: one'3- to ;ee ~~.nat ct,anged
i
I
-------
:. ftt14
io :1.1 •4•5
----··--
rudwnp • fiJH
'"'5'"'6
nrdwnp ·, fig16
10 ::! "6"7
10 3~J
sudwnp .• firP
.....
~
·---·
Proceed ''then ready
IJI41 .. ., <t
~~~·)1-:-r~l..l hddt'llt~l•
uf .... r.;. T
I-
Figure 17.
Recalculating CPU and priority values
.e.
tv
sc 1ed
____ lo
/usr usrrslljrdlcbcscnatSki.IOIUI/sc ••
.....
10
21,1 ll('twd.l
"C'MU Turor'
(name beln~
<hlllt<d to 'C'T" "'
1988)
(t) C'opyrill)lt
C'ornt&le-M.Uon
Unlvenl!y, 198~.
Moy be used ond
t._dfreely!ar
educ•tionaJ
purposu.
but may nor be sold
Without the written
consenr
of C'~me¢e· M.Uon
.....
UJUVUIII}'
Tutor
iol2J~nbhp>
2.:n .,. . 7
s<rclump • ftg7
10 24) ., ••
sudump .• 8g8
io
:!.~I
Previous
""
Process Table ( partial )
Current
19 17 15
12
I0
II
1915
Running
~
1.10
12 18 11
16 1413
1.11
IX
18 11
14 13
16
I.f.)
Oerting C'MU
10
THE UNIX* PROCESS SCHEDULER
Run Queues
1.14
1.15
10
Previou•
~
Pre·. . iou3
PID
PI" I
10
11
12
13
14
15
16
17
18
19
71
77
35
92
82
25
89
25
79
25
(:Pl.!
Current
PI" I
CPl.!
22 __ BQ_4L_
34 --~9_11 __
23 65
11_
44 71
22
44 71
22
26_ ~!!-~L_
58 74
29 -5 61
2
38 (:j~~-8 25
8
"1"9
s<rdlunp • 6g9
10 261
"9"10
Strdlunp ...
io:! ...,.
•o•t
The new CPl.! and ptior~y tPRil values ate calculated for all
8~10
ready ~roces·:.e'5
•u•u
10
:!.9· "l"l
nrd1unp • 6~1:
The :.cheduler !hen e:-:ecute 3 t.he
schedu tng algonlhm, selecting lhe ne:·:t ptocess t.o run.
mdlunp · figll
lo28.•
s<rdlunp · 8~12
A.s it u~dates the process table and queues. Uw:, ~tmulation
:.aves t e prevtou:. values so that you can con.pare theu•
1qth the ne-..•1 ones to see \•A'l&t changed
to:O··J·~
Hrdlunp ·,
10:1\
fi~14
'"4"!
If you "iOuld Iii e to add a process now, you may select" Add
proces~ "from
n rdlunp , Otl ~
IQ ::!1
"!'"6
the menu
Hrdlunp • Oglci
io ::.1 "6"7
sudUmp > 6gl7
'v'au may remove~ process by selecting "t ill process"
Ia ~~
P1 oceed 1•.11en ready
:~)
~
--~
-- -j
J
I
"7"1
sudwnp :.- OgiC
10
'
I
........
u.rdump ~· ~Sa
UUI ..
I~
dlll.!'qi'IIE'IE'd lla•l1.!'1na1t uf Jo\T,::. T
1--
Figure 18.
Showing new values
ol:>o
w
sched
. !o
/usr userslgrdlcbcscskalska.lo/caUsc 1e
.....
10 21 • 1 sdwd.l
TMU Turor
THE UNIX· PROCESS SCHEDULER
IOIJnt btlnf,
thona•d •• "CT "'
19881
Process Table (partial)
Run Queues
(<) C'opynB)>r
Ctmtl)t·MtUon
tllpitd frttly for
tduCIIIlOnlll
pwposu
bu• mey no~ be sold
wM1out rht wnntn
constnr
of C'omet)t· M•llon
Unr,erslf)'
t1
G<ttln&C'MU
Turor.
io22)..,.-_>
U::.:t
st rdwnp
:··
11&6
··-
19 15
Running
~
..
1.10
1.11
•••1
19 17 15
12
t0
.....
io 23)
Curren•
Prevlou~
Univ<rsl!y. 196;
May bt usrd •nd
12 18 11
16 14 13
u;
18 11
1413
16
1.>~
1.>5
Previous
G
10
Pl(l
)
10
11
12
13
__1_4
15
16
17
18
19
Previous
PF:I
<.:P>.>
71
77
35
82
82
25
89
25
79
25
22
34
23
---~-tnre~~
PF:I
CP>.>
80
68
65
41 __
17
,
"!L _L1~l44
26
58
5
38
8
71
25
74
22
69
25
19
8
2~-
29
6~7
io :!4) •7"'1
mmimp • ftt8
lo 2~J •t"t
s:trdwnp • fi,.o
ao :!0• "t"'IO
nrdlunp · fitiO
10 27, "0""1
strdwnp .. fi&ll
io 2a·, ... ll .. ll
strdwnp ·· figl~
io 29~ "'2"l
strdwnp :.• fiJI:
lo :0• •J••
md\unp • fttl•
1o :n ~ •.J"!
Strdwnp .• ft&l;
io~·, "'!•6
sudwnp > ftrl6
oon)•6•7
strdwnp > 6&17
lo 3-l) •7•1
strd\unp > fi&IB
io :s) •a•aa
strdump :> ft&l a.
lo:l6)•1a•'
scrdwnp > Dtl9
c.lo
The running process. 17,
e~:lts
~
I
"i
Proceed v.4lenleftd)t
Llt~l::
rs a u•gr:.lltl'r~Prtlr~•JII!'ru.a.r• of AT.! T
...
Figure 19.
Current process terminates
,ro..
,ro..
ulrfuseiilllril/cl)cscslii/Sh. ofcallsc le
sched
u.rd,unp • tis.io :!_4; "'7"'1
sudwnp, 6~8
ia '~' .. 1"9
IC rcklmp . • fiJ,.O
lo 20\ •t•to
sudump , BgJO
THE UNIX* PROCESS SCHEDULER
Process Table ( partial )
Run Queues
ioFl •o•t
scrdump ·' Htll
1o Z81 ·u•u
scrd\mp ,,
a,u
io 291
-·-~~
C:unenl
Ptevious
•.z•J
19 17 15
12
HJ
nrdump :• HgJ:
lo30l"J"C
scrd\unp • figl4
io:n•c·s
sudwnp • Btl!
f. I
19 15
Running
[~}·>
uo
""5 .. 6
sudwnp • Bgl<i
lo ::, "6"7
sudwnp • Btl?
io ~' "7"1
scrdwnp • fitl8
lo ';! 1"I" I•
I - sud\unp · fitl8t
lo :;6) "lo"9
nrdwnp • 8~19
10 ~:.
12 18 11
16 14 13
1)1
u:
18 11
1413
16
1.1.3
'-'~
1.15
10
Previous
G
Pre·Jiou ~
CPI.I
PID
PP.I
10
11
12
13
14
15
16
71
e---lL
1?
35
82
82
C:unent
22
34
23
44
44
CPI_I
80
68
65
41
17
11
22
22
71
71
-~~L _1~§_
74
-~~~8
~5
25
29
5
1--H!_ .1~~~
19
P~l
8
_§~-
25
8
lo ::-:-·, "'Jt•lO
.
S[ldump
·a
Hr20
The nex•.r CPIJ and priority (PF:I! values ate calculaled for all
r·eadf ~race:- 3-e:, The :.cheduler then e::ecute:, the
schedu1ng algonthrn. -:.electing the ne::t process to run
A·; 1t
u~date~
Ihe p10ce·:,s table Blld queue-;. this shnuiHtion
S.iwes t e pre·...-ious value:. ·~o ll1at ·;au can compare thern
.,,,,,h the nev.1 ones t.o see 'Hhal changed,
-·---
-·-
l
--·
-Proceed v.-tlen r eHctl
II,
·'-··-··---·--·--
• UHt;: 1$ .J
I~IJISIE'If!'ri tf~·l~rn ~~·
0, AT.! T
Figure 20.
Recalculating CPU and priority values
""'
Ul
chcscska
ntd\unp • fit"?
10 ~~~~
10
sc 1e
usr user
10
.7 . . 1
sudtunp ·
6~8
10 ~~, ..... ,
st rdlunp
THE UNIX. PROCESS SCHEDULER
• G¢1
Ia :!6• "9"10
"rdump ,. ftglO
to:!"') ..... ,
nrdwnp ·• ftgll
1om ·u·u
sudump > D&l2
Ia 29) "l"l
J<rdump > ftt13
to 30) •J•4
nrdump > ft&l~
to 31) •••s
strdwnp > Btl~
to 32) •s•'
sudwnp ··• ftglo
io :r.:;) ... , .. 7
sud\unp ·• ftgF
to 341 "7"1
J<rdump ' 6gl8
io 3~·, •t•ta
mdtunp · figl8o
io :Ol "'ta•9
sudwnp ,. Hll9
10 :··, •JP•lO
Process Table (partial)
Run Queues
Current
Previol•"S-
1915
1(1
t
19 15
1
1_1(1
12 18 11
16 14 13
1.11
IX.
18 11
16 14 13
10
1_1"3
10
II
I_I~
Running
0
Previous
0
P•e·-:iOlr~
PtD
PF:t
(.PI)
10
11
12
13
14
15
16
17
!8
19
80
§8
65
71
71
25
74
61
69
25
41
17
11
22
22
26
29
2
19
8
C:ur•ent
CPl.!
PP.t
70
20
§_4_ _
8
62
.L
~~-
~~-~~-~~
67
64
25
1~
9
8 -·-·
S:Udlunp • fi~Q
to 38· ·o•1
>trdwnp, 6(.21
The new CP 1.1 and pnontyiPRII v-alue·;. are calculated tor all
ready eroce;. H~:; The scheduler then e::ecut.e ~ t.he
s.chedutng ftlgorilhm. seleclir1g lhe ne:~ process to run
A'S It u~at.es. 111e proce-:s.s. table and Qlteue-:s., lh1:s. ~·rr•ulahon
saves rle ple·.;,ou:. value:. so that i·Ou can compa•e lt1elll
vlilh the nl!\•.1 ones to see ·.•.flat changed
·j
·-i
. I
_J
I
~
I
~
....
Proceed vA>en ready
lltU::
•s ~ regt:;teled lla•:t!E'rn->r)
of AT.?. T
··--
Figure 21.
-·
Showing new values
"""
0"1
47
Following this demonstration of the first steps
the
lesson, some selected screens are shown.
shows the
situation
after
the
user
adds
Figure 22
five
processes by means of the "Add process" menu option.
Figure 23, two processes, numbers 12 and 20,
"killed"
(removed)
cess" menu option.
there
are
no
by
In
of
have
more
In
been
the user through the "Kill prothe
final
figure,
Figure
24,
ready processes to schedule, so the NULL
process is selected to run.
nrdtunp •
a,. .
sche(f
usr usrrs/grdlcbcscskillsko.lolcousc or
10
io 24) "7"1
Htdump • fiJ8
"l"t
sudump • fll.-0
io 26) •t•to
strdump ,. D&IO
io:!~\
to
2~)
THE UNIX• PROCESS SCHEDULER
Run Queues
•e•t
sudump ' fi&ll
,. 28)
mdump > Dll2
·u·u
1029> jOol"'l
sudump > D&l~
to ::0\ •J••
mdump , DJI4
ID :11 "4"5
sudwnp > D&IS
to 3:!1 •s••
Pre·. .·iow.
I 1
nrdump ,, Dslo
Ul
to 3:l) "6"7
sudump :- rit17
ia :,.d\ "7"'1
IJ:
1- mdlimp ·, 6~18
10 :~~ .......
n rdwnp • fif 18&
io
:o·~
"ba9
mdwnp .• 8~ 19
io :.., 1 "19"20
H rdlunp • fi,;!O
ra :::e~ ·o·t
sudump .• 6~21
Current
1915
I0
18 11
16 14 13
10
LIO
Process Table (partial)
I))
22 19 15
24
23 18 16 14 13
2110
20
12
'-'~
1_1')
io :;9, "l"l
sudtunp • D,;!2
r-
The""''' CPI,I and priorily (PRII value-; are calculale<ltor all
reftd·i
~roce;.
;e:.
The scheduler lhen e:·ecure ~ the
PID
PP.I
CPl.!
P"l
O:.PI_t
10
11
12
13
14
15
16
70
64
62
65
65
25
67
20
8
5
4
32
5
11
26
14
65
62
76
62
62
18
19
20
21
r--?2
r--?3
24
64
25
9
8
G
Previous
G
:.chedulng algottlhm. ;electing lhe ne:-~ pr ace;,:. to run
li. ~it u\Jdare:. the proce-s.s table and queue:.. tht'S -;nnuiHiion
:.av!oe:. t 1e previous values ~o that you can con•pa• e theu•
~Htth
Cu11enr
Pteviou:.
Running
the new ones to ~ee \•,11at changed.
11
--19_
!i_
2~-
63
7 ..
62
25
74
8
2L~
R
~~ _!~-- j
6~--~
54
26
__,j
I
I
'!
_______ ___j
I
,______,~
'
I
i
....
J
i
Proceed 1•hlen ready.
I
i
Llt,t:: •s •regntertd ll~·::ltmatl 01' An'. T
'
f·
----
Figure 22.
Five processes have been added
00
"""
~-Erlllll·~ sc ••d
usrtuserslgrdlcbcscsko/ska.lo/c•ll•c ••
sud~unp • fis.-:-
_to
~---
:!.•) ·1·1
sc rd1unp :• ft&B
lo ~~\ "1"9
10
::~;n:~:.:rJ>
THE UNIX* PROCESS SCHEDULER
"rdump > 6&10
io27) ·o·•
scrdump > a,u
~~~~·~: 12
io29)
"l"~
sudump > Ugl3
io30)·~··
.
Process Table (partial)
Run Queue•
Previous
II
Runnin
Currl!!'nt
22 19 15
24
10
22 1915
24
[3
13
g
mdump > 6&14
:~;.:.:,;:~5611 ~
lo ::2) .,.,
.
::~t"!~~·7fi&lo
nrd•unp - UgJ7
L
~:~:-.•6 , 18
1_13
10 =~\
.......
"~~np
23 18 16 14 13
21 10
1.10
111
-,
23 21 10 18 16 14
20
12
M
~
11
Previou-s
PP.I
CPI_I
10
11
12
13
14
15
16
65
62
76
62
62
25
63
10
4
32
5
5
26
7
18
19
20
21
22
23
24
62
25
74
67
22
62
54
4
8
29
15
45
5
26
Clurent
CPU
P~l
!?_
62
76
32
61
61
25
61
2
2
26
3
61
25
2
8
II
'fig!Bo
10 .:10) ...... ,
nrdump • 6gl9
, . :7 •"19"20
-~1-----------t-----------i
l.l5
:~~~~~· fi&ZO
nrdwnp ·' fii,21
:9. "l'l
Hrd1unp. fi~
1
10
.
Th~ """' C:PI.I and pnonly tPP.I) valu~> "'~ calculal~d for all
ready ~~ oces ~e; The scheduler then e:-:ecute' the
>th~du lng algmol.hm. ~~lectlng the ne:~ PIDCI!55 to IUn
40 , • 22 • 23
sudtunp .. ftg:!.~
10
1--
.
Previous
PID
•
63
7
22
45
61
2
54-----··-·
26
~- ~ it upda1.e-s the pt ace ;s table ftnd queues. th1s simulal.lon
:.ave:. the pte·-.:rou-;. vollU!:O -;,o thAt •1ou can commue them
'fth t.he ne..•.: ones to ;ee ~~,.hat changed
'1
r----+-------+-------1
-- j
II.
~--~----~-----~
I
Pooceed "·tlen ready
uru;: 1s
f-
.
,a,,e•~l'>lete•JIIa•11?1n~•• ofAT.~T
L__ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _. _ _ _ _ _ _
Figure 23.
t------i----+---j
-1
------------·----·
Processes 12 and 20 have been killed
,p,.
\0
u..rdwnp .• 6t."
10 241\ "7 .. 1
n rdl.unp ::- figS
io 25) .. , .. ,
sudump , fir,.O
io 20) •t•to
J<rdlmp > BtlO
lo 27) ••• ,
s.n.,.> Bgll
1o 28) ·u·u
ou ..... >BtlZ
1o Z!')
.
·z·l
sudlmp > Btll
lo 301 •3•4
IUdump > Btl4
lo :ll) •••s
oudwnp ,. Btl~
lo~) "!"6
sudUmp • fig lo
ia :t:) ..
r- scrdlunp' 8gJ7
ia :..:• "l"'l
ttrd•unp > 8t1B
,.7
IG :~1 .........
ttrd•unp ,, 8g18o
Ia :0)
•a."9
nrdump . Bgl?
lusrtuserslgrd/cbcscskalska.lolcal/sc oe
sche<l
----
IO
THE UNIX* PROCESS SCHEDULER
Run Queues
Curr1mt
Previou~
22 19 15
24
I0
n
Process Table ( partial )
22 19 15
24
Pre·.;iou:.
Running
Current
PID
PF:I
CPI_I
PF:I
CPIJ
15
25
26
25
26
19
25
8
25
8
22
22
4!L ~:?-
24
54
~6
G
LIO
Previous
lll
G
Uc
1_13
1.1
ll5
•• ro ·19·zo
sudwnp . 8~0
)0 :l6) ••• ,
scrdwnp , fi€21
10 :::9· "l'"'l
~c rdwnp • fie!:!.
io40, •u•2J
ntdwnp :.• af,l:
oo4J)•J••
S<fdump ., "~·
Since lhere are no read','·lo-run processes. !he t·ji_ILL
process is selected to e::ecute
54
26
-
II,.
Proceed v-tlen ready
UUI.:
f-
I~~ rtgiSitt~dtradeiRar•
orATtT
--·
----
Figure 24.
~~------
No ready process to schedule
1.11
0
51
The user can select the "Help" menu option to
out
more
about
running
"More details" option.
more
the
lesson.
find
There is also a
The user selects this
to
learn
of the details about the simulation.
Selection of
this option gives four pages of additional
information.
All text is written in the text box.
This view of the UNIX
general
idea
of
the
process
"flavor"
screens are not shown here due
number
of
screen
difficulties.
For
dumps
scheduler
of
to
the
gives
lesson.
limitations
on
a
Many
the
possible and due to technical
instance,
in
order
to
print
the
screen for this report, it is necessary to move the cursor to the command window at the left of the screen.
is
therefore
It
impossible to demonstrate the menu in the
scheduler lesson, since that would require the cursor to
be in the lesson portion of the display.
).
).
Chapter 5
Programmer's View of the Lesson
For tribal man space was the uncontrollable
mystery.
For technological man it is time
that occupies the same role.
Marshall McLuhan, The Mechanical Bride.
This project presents basic facts
process
scheduler
and
allows
about
the
students to check their
understanding of these facts by observing the
in action.
UNIX
scheduler
This chapter discusses the implementation of
the UNIX Process Scheduler lesson.
It
describes
major
data structures and motivation for design decisions.
Neither time nor space is a critical issue for this
program.
The
workstation.
has
only
project
was
developed
This is a 2 MIPS machine, and
one
user
on it at a time.
enough that pauses have been put in
places,
on
e.g.,
when
the
a Sun-3/110
it
Run time is fast
code
updating tables, etc.
difference
some
notice-
the
speed of the portions of code
that handle calculations.
This should not be a problem,
however,
in
in
If run on a
slower machine, such as a Sun-2, there_ may be a
able
usually
since the factor that really controls the exe-
cution speed of the lesson is the amount of time that
human
requires
to
a
read the text and to comprehend the
changes in the graphics.
52
53
According to the standard UNIX
algorithm,
process
scheduling
if more than one process has the best prior-
ity, the scheduler selects from these processes the
one
that has been waiting in the run queue for the most time
(1:254).
lar
This process may not have been at the particu-
priority
the longest.
To implement the algorithm,
this program uses a single run queue which
in
its
run.
is
it
searches
entirety to select the most eligible process to
Since the first process with the highest
priority
selected, and processes are always added at the tail
of the queue, this implementation ensures that the
cess
that
has
pro-
waited the longest is chosen from those
with equal priorities.
One goal of this project is to enable
students
to
modify algorithms and parameters and observe the effects
of the change, to obtain a better understanding
UNIX process scheduler.
of
the
To facilitate this, the program
uses symbolic constants extensively.
CMU Tutor does not
have true symbolic constants, so they are simulated with
variables that are
changed.
Where
assigned
the
value
a
value
value
is
is
never
of one constant depends on
that of another, the dependent constant
whose
which
is
a
variable
calculated at initialization, based on
the value of the other constant, and the
value
is
not
The function that decays the CPU value and the
one
changed thereafter.
Q
•
54
that
updates
module.
the
process priority are each a separate
The algorithm for either or both functions
can
be changed in order to study the effects of such changes
on the scheduling of processes.
One feature of CMU Tutor greatly
program.
Whenever
the
window
is
complicates
this
resized, CMU Tutor
starts executing the code from the beginning of the main
unit.
To
hide
this from the user, this program saves
state information so that the program can appear to
from
where
it left off.
of the code because it
run
This increases the complexity
requires
additional
parameters
and flags for many routines.
1.
Data Structures
The only data structure in CMU Tutor is the
array.
Due to this limitation, the data structures in this program consist solely
complex
structures,
of
one-dimensional
such
implemented with parallel
implemented
arrays.
inqueue,
as
an
array
as
the
arrays.
arrays.
process
The
table, are
run
of "pointers":
queue
numprocs
elements,
is
indices into
All of the arrays below, with the exception
have
More
of
where numprocs is a
symbolic constant whose value is the maximum
processes that can exist on the system.
number
of
55
1.1.
The Process Table
The process table is represented by two arrays, CPU
and
priority,
PID.
Before the
values
are
oldpri
indexed by the process identifier,
process
table
is
updated,
is
If process
~
old
does not exist, element
n
set to the symbolic constant noexists, a
number that is one less than the lowest valid
Auxiliary
the
saved in the arrays oldCPU and oldpri, also
indexed by PID.
of
both
arrays,
also
per-process values.
indexed
priority.
by PID, contain other
One of these is exectime, which
is
set to a random value for each process when that process
is created.
time
are
This number tells how
many
required by the process.
process'
exectime;
less, the process exits.
sleeping,
are
if
of
subtracted
from
the value is then zero or
Two other arrays,
used as arrays of Boolean.
exists
and
Exists indi-
cates whether a process with that PID exists and
ing
CPU
Each time a process
"runs", the amount of CPU time used is
that
units
sleep-
tells whether the process with that PID is blocked,
waiting for an event.
These last two arrays could
have
been combined into one state array, but the code is more
readable with the current implementation at
only 2
1.2.
*
a
cost
of
numprocs bytes.
The Run Queue
The run queue is implemented
as
an
array
called
56
next.
Element n of next contains the PID of the process
that is the successor in the queue to the process
PID
is
n.
whose
The old run queue is remembered in another
array, oldnext, before the run queue is updated.
1.3.
The inqueue Array
One other array, ingueue, contains
the
processes that have been pictured in queue
ment m.
number
of
in its ele-
~
This array has numgueues elements,
where
num-
gueues is a symbolic constant that represents the number
of queues pictured on the screen.
the
This array is used by
graphics routines that display the current and pre-
vious run queues.
2.
Scalars
The current version
of
CMU
Tutor
has
byte
integer variables, as well as floating point.
byte variables are 8 bits, unsigned, while
variables
are
16 bits, signed.
and
CMU Tutor
the
integer
This program uses byte
variables whenever the number will never take on a negative
value
and
will always be less than 256.
Boolean
variables must be declared as integer because CMU
Tutor
uses -1 for TRUE.
Some important scalars include
first,
run, and prevproc.
first,
last,
old-
First is the PID of the first
process on the run queue, and
therefore
is
the
index
57
into next for the head of the queue.
the last process on the run
always
added
to
the
queue;
head
of
the
a
new
process
is
end of the run queue, so last is
important for enqueueing processes.
the
Last is the PID of
Oldfirst
remembers
previous run queue when the queue is
updated; thus, it is the PID of the process at the
head
of the previous run queue, i.e., the index into oldnext.
Run is the PID
remembers
of
this
the
value
current
process
and
prevproc
when the scheduler picks the new
process to run.
The scalar increment determines how many
different
priority values are shown in one user-level queue on the
screen.
In addition, if increment is set to one, one of
two alternate text units is selected.
This text unit is
appropriate when there is only one priority per pictured
queue;
an alternate text unit is displayed if increment
is greater than one.
tain
When increment is set to one, cer-
scheduling features may be clearer but the maximum
priority for the program becomes unrealistically small.
3.
Modules
The program is divided into five logical parts:
1.
The driver routines - the main module
and
the top-level modules called from main().
2.
Routines for initialization
the initial processes.
and
to
seed
58
3.
calculate
Process management routines:
priorities,
routines
to
choose the most eligible process
to run, etc., to simulate the scheduler, as well as routines to add or remove processes.
4.
Routines to print the lesson text and
the
text modules selected from the menu, such as Help.
5.
3.1.
Routines for graphics display.
Main Module and Driver Routines
The main module, main(), calls setup(), which
dles
initialization
initial state.
the
and
calls
han-
routines to set up the
Next, main() calls a routine that checks
size of the window.
As long as the window is not a
reasonable size, the routine prompts the user to make it
larger and then checks the size again.
The user may resize the window at any time.
resizing
the
Since
window in CMU Tutor causes the program to
run again from the start, in order to continue from
program
state
the
before the resizing, initialization must
not occur if main() is called because of resizing.
How-
ever, in this case, the screen display must be repainted
as it was before the
repaint()
to
do
resizing
this.
occurred;
After
calling
main()
calls
setup()
repaint() and checking the window size, the main
or
module
calls the driver in a loop.
The driver calls
routines
to
save
the
previous
).
59
values
for
the
running process.
process table, the run queues, and the
It then calls the routine
that
simu-
lates the running of a process followed by rescheduling.
The driver also calls text routines that
occurs
during
each
time
slice
and
describe
tell
what
what
the
scheduler is doing.
The driver calls routines to handle
screen
display
updates
to
the
changes caused by the
rescheduling.
3.2.
Initialization and Initial Process Generation Rou-
tines
Setup() initializes scalars, then calls
tines
to
establish
the
initial
state.
four
rou-
The first of
these, initializearrays(), does what the name suggestsinitializes
arrays.
The
other three routines set the
original state by seeding the initial
processes
(which
are in the system when the lesson begins), pick the most
eligible process to run, and dequeue the chosen
process
from the run queue.
3.3.
Process Management Routines
The process management routines perform such
tions
as
saving
the
previous
state,
rescheduling the processes, updating
values,
tem.
given
and
func-
running
priority
and
and
CPU
adding or removing processes from the sys-
Two routines handle enqueueing
process.
Processes
are
and
dequeueing
a
always enqueued at the
60
tail of the queue, but they can be
where in the queue.
by
the
from
any-
Processes come into being either by
being seeded into the system
added
dequeued
user
at
startup
or
with a menu option.
by
being
Processes are
removed from the system when they complete execution
or
when the user kills them.
3.3.1.
Menu Routines to Add a Process
Selecting the menu option to add a process calls
routine,
addprocess(), which prompts the user for input
- the desired priority for the new process.
routine
a
validates
After
the
the input value, it calls a routine,
addproc(), that actually adds the process or
tells
the
user that the process table is full.
3.3.2
Menu Routines to Remove a Process
This set of
(remove
from
the
routines
permits
system)
a
a
user
kill.
"kill"
process by selecting the
option from the menu and giving the PID of
to
to
the
process
Two routines are involved: killprocess() and
kill().
Killprocess() asks the user for the PID of
process
to kill and verifies the input.
cess() has valid user
input,
it
calls
the
After killprokill(),
which
actually removes the process by calling exit().
3.4.
Lesson Text Routines
A text driver controls the sequence of lesson pages
,, '
61
for
the
first
part of the lesson.
the lesson is over, the text is
what
occurs
determined
largely
be
as the non-deterministic scheduler simula-
tion executes.
of
After this part of
Information supports the graphic display
processes running, being rescheduling, perhaps exit-
ing, or maybe becoming blocked while
I/O
takes
place.
Additional text can be selected with the "Help" or "More
details" menu options.
3.4.1.
Help Routine
If the Help option is selected
page
of
information
from
the
menu,
a
is displayed about how to run the
lesson.
3.4.2.
Routines to Give Additional Information
Selecting the More details menu
user
a
series
option
gives
the
of four pages of additional information
about the scheduler simulation.
3.5.
Graphics Routines
The graphics routines draw and
forms
for
the
text
box,
the
label
the
initial
process table, the run
queue, and the current and previous
process.
Some
of
the routines display the values in the process table for
each process and some show
queues.
the
processes
in
the
run
62
4.
Some Challenges of Writing This Program
One of the greatest challenges of this program
was
designing it so that it appears to continue running from
where it was if the screen is resized, which
at
any
time.
size
occur
As mentioned previously, CMU Tutor actu-
ally runs the code again from
window
can
changes.
the
The
beginning
when
the
approach used to hide this
from the user is mentioned above.
If the screen is resized while the program is
cuting
a
multi-unit
menu
option,
the
exe-
program
must
remember that it is in this option and which unit it
executing.
This
requires
a
flag
and
is
an additional
parameter.
Another challenge involves items
menu.
chosen
from
When the user selects a menu option, what essen-
tially happens is that an interrupt occurs.
The
inter-
rupt handler is the routine to be performed for the
ticular menu item selected.
sary
the
to
position
the
In CMU Tutor, it is
cursor,
writing
for
the
If
the
menu
item
to the screen and this item is called
while in a routine that also
possible
neces-
and perhaps change the
font, before writing to the screen.
involves
par~
cursor
involves
writing,
it
is
position to be different, as
well as the font size, when execution resumes
point where the interrupt occurred.
from
the
This is because the
63
action set that positions the cursor and then writes the
information is not atomic.
The solution to this problem is the same as is used
in
critical
interrupts.
by
removing
sections
in
operating
systems:
disable
In the case of the menu items, this is done
the item from the menu where the interrupt
must not occur and adding the item back to the menu when
this section of code is passed.
5.
Additional Features
This program demonstrates the standard UNIX process
scheduler.
The
program is designed for easy modifica-
tion, as outlined above.
Possible extensions include
multi-level help menu with additional information.
an extensive help system is not
required
in
a
Such
order
to
present the UNIX process scheduler in action, and therefore is not considered to be
this time.
an
important
feature
Adding the feature would be quite easy.
The ability for the user to add and kill
is
not
essential
scheduler.
tional
at
processes
for the demonstration of the process
However, these features give the user
addi-
insight into the UNIX process scheduler, as well
as being useful in the program debugging stage.
fore, these features are part of this program.
There-
Chapter 6
Conclusion
A stone thrown at the right time
than gold given at the wrong time.
is
better
Persian Proverb
The question whether, on the whole,
there is
progress in the universe, may depend upon our
choice of a measure of time.
Bertrand Russel, The ABC of Relativity
This
facts
computer-assisted
about
lesson
the UNIX process scheduler and illustrates
the facts through a graphic demonstration of
plement in a
on
third-
or
operating
fourth-year
their
lesson by
running
computer
science
systems in which the general con-
cepts of process schedulers are
test
a
The lesson is intended to be used as a sup-
scheduler.
course
students
teaches
taught.
Students
can
understanding of the UNIX process scheduler
trying
to
predict
which
process
will
be
selected to run and what the new CPU and priority values
will be.
They can then check those predictions
against
the simulation to get immediate feedback on the material
that was presented.
priorities
or
additional
insight
By adding
killing
and
processes
of
specified
processes, the student can gain
understanding
scheduling algorithm.
64
regarding
the
65
At another level, students can modify
code
the
and observe the effect of such changes.
ple, students can change the number
illustrated
of
For exam-
priorities
per
queue, the size of the time slice, the rate
at which the CPU value is decayed, and many
tors.
program
Entire modules can be replaced.
entirely different algorithm could
other
fac-
For instance, an
be
substituted
the present one that decays the CPU value.
for
The code was
designed with an eye toward easy modification.
Possible future extensions
menu
system.
With
this
include
feature,
"Help" from the top-level menu, then
from
which
to
choose
process.
command
process.
current
"nice"
users could select
get
a
help
Another possible extension
specify
is
scheduler
use
the
nice
a lower initial priority for a new
This command is
not
simulator
used
assumes
very
often.
The
the default nice
value for all processes - thus essentially ignoring
nice value.
menu
as a factor in the initial priority of a
In the UNIX system, a user can
to
multi-level
the particular item about which
they desire information.
adding
a
the
Including this additional. factor might hide
the basic workings of the process scheduler by adding to
the
complexity
of
the system.
could be added if desired.
However, such a factor
66
1.
What Did I Learn from This Project?
This project has taught me many
following
new
things.
The
are the primary areas in which I increased my
knowledge as a result of the project.
1.1.
Schedulers
The project
schedulers
and
required
me
to
review
scheduling algorithms.
material
on
It also gave me
the opportunity to compare the treatment given to
these
topics by a number of different authors.
1.2.
UNIX Process Schedulers
As a result of this project, I have learned a great
deal
about
the
UNIX process schedulers.
was new material for me.
Most of this
Trying to implement the
algo-
rithm of the standard UNIX process scheduler required me
to really understand how it works.
1.3.
Writing CAI Lessons
As I developed this project, I came to realize that
writing
a
good
lesson
people learn and how
learning.
I
have
to
requires some knowledge of how
present
material
to
enhance
tried to avoid the "electronic page
turner" syndrome, but there is a lot of text that has to
be presented at the start of the lesson.
Perhaps I have
not been altogether successful in abstaining from
using
Q
•
- - - - ......
67
the
computer
to present page after page of text, but I
have tried to introduce changing graphics along with the
text.
1.4.
The CMU Tutor Language
In order to write this program, I had to learn
CMU
Tutor
language.
is a high-level language and
However, learning any
quite easy to learn.
language
It
takes time.
my
project
be
worked
around.
began (Spring 1987), for example, the
version of CMU Tutor then available
point
programming
The language also had its limita-
tions and peculiarities that had to
When
the
variables.
As
been installed, I have
had
only
floating
newer versions of CMU Tutor have
incorporated
the
new
features
into the program (while keeping a version that runs with
the 1987 CMU Tutor).
1.5.
Using the troff/nroff Language for Text Formatting
This paper was formatted
troff/nroff utility.
with
the
UNIX
system's
nroff formats text for printing on
typewriter-like devices and line printers; troff formats
it for printing on a phototypesetter.
This document was
written to be compatible with either troff or nroff,
that
so
it could be prepared with whatever facilities were
available.
To produce a paper with the physical
format
,, .
68
specified
in
needed.
For
produce
page
Although
I
the
guidelines*,
special
numbers
used
language.
how
were
example, there were no built-in macros to
in
the
required
to
locations.
the ms macro package, I had to add my
own macros in some cases, like the above.
studied
macros
use
conditionals,
To do this, I
etc., in the troff
Thus, I greatly increased my knowledge of the
UNIX text formatting utilities.
1.6.
Documenting
Documenting this
project
confirmed
a
conclusion
that I have reached on previous occasions: documentation
takes about as much time as developing
program
and
is
not as much fun!
and
coding
the
Preparing this paper
with troff/nroff did add a certain challenge
that
made
the documenting more interesting.
* "Guidelines for Preparation of Theses and Graduate
Projects," California State University, Northridge.
June 1983.
BIBLIOGRAPHY
1.
Bach, Maurice J. The Design of the UNIX Operating
System. Englewood Cliffs: Prentice-Hall, 1986.
2.
Bach, M. J., and S. J. Buroff.
"The UNIX System:
Multiprocessor UNIX Operating Systems." AT&T
Bell Laboratories Technical Journal 63, no. 8
(Oct. 1984): 151-167.
3.
Chambers, Jack A., and Jerry w. Sprecher.
"Computer
Assisted Instruction: Current Trends and Critical Issues."
Communications of the ACM 23
(1980): 332-342.
4.
Dietel, Harvey M. An Introduction to Operating Systems. Reading: Addison-Wesley, 1984.
5.
Finkel, Raphael A. An Operating Systems Vade Mecum.
Englewood Cliffs: Prentice-Hall, 1986.
6.
Gagne, Robert M., Walter Wager, and Alicia Rojas.
"Planning
and
Authoring
Computer-Assisted
Instruction Lessons."
Educational Technology
21, No. 9 (Sept. 1981).
7.
Henry, G. J.
"The Fair Share Scheduler." AT&T Bell
Laboratories Technical Journal 63, no-.-8-(0ct.
1984): 260-272.
8.
Lister, A. M.
Fundamentals of Operating Systems.
3rd ed. New York: Springer-Verlag, 1984.
9.
Morris, James H., et al.
"Andrew: A Distributed
Personal Computing Environment."
Communications of the ACM 29 (1986): 184-201.
10. Peterson, James L., and
Abraham
Silberschatz.
oaerating System Concepts.
2nd ed. Reading:
A dison-Wesley, 1985.
11. Ritchie, D. M., and K. Thompson.
"UNIX Time-Sharing
System: The UNIX Time-Sharing System." The
Bell System Technical Journal 57, no. 6, par~
TJUiy/Aug. 1978): 1905-1929.
12. Sherwood, Bruce A.
"CMU Tutor." Proceedings of the
Digital Equipment Computers Users Society--(Faii
1986): 179-180.
69
70
13. Sherwood, Judith N.
Carnegie-Mellon
CMU Tutor Reference
Univers1ty internal
Manual.
report,
1986.
14. Tanenbaum, A.
s.
Implementation.
Hall, 1987.
15. Thompson, K.
Operating Systems:
Design and
Englewood Cliffs:
Prentice-
"UNIX Time-Sharing System: UNIX Implementation."
The Bell System Technical Journal
57, no. 6, par~ TJUiy/Aug. 1978): 1931-1946.
APPENDICES
71
Appendix A
User's Manual
72
-Appendix A
User's Manual
Learning makes a man fit company for himself.
Thomas Fuller, Gnomologia.
1.
Getting Started
To run the UNIX process scheduler lesson, login
the
system
using
instructor.
been
the
account
to
name specified by your
If required, use the password that you have
given.
When you see the "%" prompt, type "wm" to
call up the Andrew window
manager.
After
the
Andrew
banner clears, a window labelled "Typescript" appears on
the left side of the display.
This
is
the
window
in
which you type your commands.
Call up CMU Tutor to run the lesson by typing "emututor -x sched.t", where sched.t is the name of the lesson.
(The lesson name can vary;
tell
you
the
name
if
your
it is not as shown.)
appears in the upper right portion of
nothing
the
will
A window
screen.
Do
until you see the words "PLEASE MAKE THE WINDOW
TALLER" or "PLEASE MAKE THE
take
instructor
some
time.
When
WINDOW
the
BIGGER";
this
may
words appear, enlarge the
screen by "pulling" the bottom edge (also the left edge,
if
needed).
To do this, move the mouse to position the
cursor on the window edge that you wish to "pull".
73
The
74
cursor
changes from a diagonal curved arrow to two fac-
ing arrows with a line, or bar, between them.
similar
to
It
looks
"->1<-" if it is on a vertical window edge,
or the same but rotated 90 degrees if the window edge is
horizontal.
Hold down the center mouse button* and move
the
(by
cursor
moving
the mouse) in the direction in
which the window needs to be extended.
ton
when
you have moved the bar of the cursor to where
you want the window edge.
enlarged
If the
window
needs
to
be
in another direction, repeat the above for the
additional window edge.
in
Release the but-
this
The window size can be
manner at any time.
changed
The program always checks
the size after resizing and lets you know if the
window
is not large enough.
Once the program is satisfied with the size of
window,
it
begins
to present the lesson.
can be run in either of two modes: auto
step.
you must
press
the
RETURN
or
ENTER
The program
run
It starts up in single step mode.
the
or
single
In this mode,
key
or
select
"(Proceed)" from the menu to go to the next lesson step.
This permits you to control the pace of the lesson.
auto
run
rate.
to
mode,
In
the lesson proceeds at a predetermined
Pressing RETURN has no effect.
You do
not
need
do anything; the lesson automatically changes to the
* If your mouse has only two buttons, use both buttons
together whenever this manual says to use the center
button.
75
next step without any intervention.
In either mode, you
can make selections from the menu.
2.
Using the Menu
To get the pop-up menu, with the cursor in the les-
son window, hold down the center mouse button.
When the
menu appears, move the mouse to select the item of
choice.
The
current item appears highlighted.
wish to choose this item,
2.1.
your
If you
release the button.
Available Menu Selections
The choices on the pop-up menu change from time
"Quit" is always on the menu.
time.
Either "Auto run"
or "Single step", whichever is not the current mode,
also
always
an
available
single step mode,
ever
the
menu option.
lesson step is completed.
generally available as a menu option except
earliest
steps
being updated.
is
If you are in
"(Proceed)" appears on the menu
current
to
when-
"Help" is
during
the
of the lesson and when the graphics are
Selecting this option produces
a
brief
help screen in the text box in the lower left portion of
the window.
At one point, the lesson tells you that you can get
more
information about the simulation by choosing "More
details" from the menu.
That option is
then
the
there,
during graphics
menu
and
remains
except
added
to
76
updating, until the option is selected.
It can only
be
chosen once during the lesson; it does not appear on the
menu again once it has been selected.
2.2.
Adding and Killing Processes
The "Add process" and "Kill
included
process"
are
on the menu only at the points when the lesson
text says that you can add or kill
choose
options
to
add
a
process,
processes.
If
you
you are asked to enter the
priority (in the text box); the valid range of values is
indicated.
If
you enter an invalid priority) the word
"no" appears, followed by a message repeating the
range.
Correct
valid
your input by backspacing and typing a
correct value.
The "Kill process" option lets you remove a particular
process from the system.
This option functions in
a manner similar to "Add process": you are asked for the
PID of the process that you wish to kill, with the valid
range of inputs shown.
Erroneous input
is
treated
as
above.
3.
Quitting the Lesson
When you are done with the
from
the pop-up menu.
area,
press
the
choose
"Quit"
The lesson window disappears and
a gray area takes its place.
gray
lesson,
With the
center
cursor
mouse button.
in
this
A set of
77
menus appears with the menus partially overlapping
other.
Move the cursor to the exposed part of the "All
Windows" menu.
move
each
to
the
If you are
This causes the "All
front.
finished
Windows"
menu
to
Select "Zap" to exit from Andrew.
with
the
computer,
remember
to
logout.
4.
A Final Note
Do not be afraid of making a mistake and "crashing"
the
lesson.
harmful.
while
lesson.
The
program does not let you do anything
You can even change the
size
of
the program is running if you want to.
Happy learning!
the
window
Enjoy the
----
-- .....
Appendix B
Source Code Listing
78
Appendix B
Source Code Listing
$version
1.2
*******************************************************
**
*
*
•
*
*
The UNIX Process Scheduler:
A computer-assisted lesson
Author: Sharon Adler
California State University, Northridge
Spring 1987 - Spring 1988
*
*
********************************************************
*
*
*
*
*
*
This implementation uses a single queue for the run queue,
and searches the entire queue to find the next process to
run. This is a simple implementation; it is slower in
searching for the next process to run than are versions
that use separate queues for each priority.
It is good
enough for our purposes, however.
********************************************************
*
*
define global variables
*
********************************************************
*
define
*
*
*
constants
b: TIMESLICE • 60
b: INITIALPROCS • 10
b: FIRSTPID • 10
b: DECAYFACTOR • 1
b: PUSER • 60
b: NUMPROCS • 35
b: TIMEFACTOR • 2
b: PRIORITYFACTOR • 1
i: MAXTIME • 600
b: NUMQUEUES • 8
b: INCREMENT • 5
b: PZERO • 25
b: NULL • 0
i: M!NPRIORITY • 0
arrays
i: exists(NUMPROCS)
i: sleeping(NUMPROCS)
i: priority(NUMPROCS)
i: CPU(NUMPROCS)
i: exectime(NUMPROCS)
b:
b:
i:
b:
b:
next(NUMPROCS)
inqueue(NUMQUEUES)
oldpri(NUMPROCS)
oldCPU(NUMPROCS)
oldnext(NUMPROCS)
global scalars
b: nextpid
b: run
i: bestpriority
b: first
b: last
b: oldfirst
i: maxpriority
b: timeused
b: wakecnt
i: autorun
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
# seconds in a timeslice
# processes created at startup
lowest PID number to be shown
shift factor for CPU value
highest user-level priority
highest PID (don't change)
divisor for assigning initial time
shift factor for priority
the maximum CPU time for a job
# queues displayed (don't change)
# priorities in a pictured queue
min. uninterruptible priority
symbolic name for 0
lowest priority value
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
exists(n) ~ process n exists?
sleeping(n) • process n sleeps?
priority(n) • priority of proc. n
CPU(n) • CPU value for process n
exectime(n) • CPU time still
needed for job n to complete
run queue (an array of pointers)
inqueue(n) • # processes in
remembers previous priorities
remembers previous CPU values
remembers old run queue
$$
$$
$$
$$
$$
$$
$$
$$
$$
$$
next t to try for new PID
PID of current process
best priority so far
next(first) • head of run queue
next(last) • tail of run queue
index of head of prev. queue
highest priority value
CPU time used by current process
# processes that just woke up
user selected "Auto run"?
79
---
80
b:
b:
i:
i:
i:
i:
i:
i:
i:
looptime
prevproc
noexists
textnum
redisplay
first time
more flag
morenum
inmore
$$
$$
$$
$$
$$
$$
$$
$$
$$
II seconds to pause in autorun mode
PID of process that just ran
invalid array entry indicator
number of text unit
redisplay table
queue values?
first time through main( )7
has "More details" been executed?
number of text unit in "More details"
running "More details"?
'
*Note: Any variable with the name x, xl, x2, etc., represents an x-axis
*position; any variable with the name y, yl, y2, etc., represents a
* y-axis position .
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
unit
main
• starting point for execution of the lesson
merge, global:
Help
menu
do
\-zreshape\setup\x
redisplay :• zreshape
calc
setscreen
do
do
\redisplay\repaint\x
loop
do
driver
end loop
*********************************************************
unit
setscreen
* set up screensize, menu, basic display, drive first set of text, etc.
merge, global:
do
screensize
if
-autorun
menu
Auto run: autorunon
else
menu
Single step: autorunoff
end if
redisplay
if
menu
Help
menu
More details
end i f
display
do
do
\inmore\textdriveA\x
do
textdrive(TRUE; textnum)
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
unit
repaint
* called from main loop if screen is resized
merge, global:
menu
More details
do
\-firsttime\showoldproc\x
do
subdisplay(TRUE, FALSE)
-moreflag
if
menu
More details: textdriveA
endif
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
unit
driver
* main loop text, scheduler, and display driver
•
*
•
•
Note:
menu items that call code that repositions the cursor
and/or changes the font must be disabled before the
Q
•
81
*
*
if
end if
calc
calc
do
do
do
do
if
end if
do
do
do
do
do
menu
menu
do
menu
do
do
menu
do
do
do
menu
if
end if
do
do
calc
process table, queues, etc., are printed. To disable,
remove item from menu; reenable item as soon as possible.
merge, global:
redisplay
do
textgenl
firsttime :• FALSE
wakecnt :• 0
saves tate
textadd
runproc
\wakecnt > 0\waketext\x
prevproc I• 0
do
\sleeping(prevproc)\sleeptext(prevproc)\x
do
\exists(prevproc)\x\exittext(prevproc)
if
-sleeping(prevproc) & exists(prevproc)
do
routinetext(prevproc)
endif
proceedtext
checkmode
textgenl
erasetable(660)
erasequeues(l7)
More details
Help
showprevqueues(235)
Help: help
erasearrows
erasecontents
Help
showoldproc
\run\x\nulltext\x
subdisplay(FALSE, TRUE)
Help: help
-more flag
menu
More details: textdriveA
proceed text
checkmode
redisplay :• FALSE
*********************************************************
*
*
Initialization& and process seeding
*
*********************************************************
unit
setup
* driver for setting up the initial situation
merge, global:
i: found
fine
900, 725
rescale FALSE, FALSE, FALSE, FALSE
*
calc
calc
calc
calc
- 1
calc
calc
calc
calc
calc
initialize
autorun :• FALSE
looptime :• 18
wakecnt :• 0
maxpriority :• PUSER + (NUMQUEUES - 3)
first :• NULL
last :• NULL
nextpid :• FIRSTPID
noexists :• MINPRIORITY - 1
textnum :• -2
* INCREMENT + INCREMENT
82
calc
calc
calc
calc
do
firsttime :• TRUE
moreflag :• FALSE
morenum :• 0
inmore :• FALSE
initializearrays
"'
do
do
do
menu
set initial state
initialprocesses
pickprocesstorun
dequeue(run; found)
Help: help
"'"'"'"'*"'"'**************************************************
unit
initializearrays
* initialize arrays that require it
merge, global:
f: i
i :• 1, NUMPROCS
loop
calc
exists(i) :• FALSE
sleeping(i) :• FALSE
calc
oldpri ( i) :• noexists
calc
next( i) :• NULL
calc
endloop
*********************************************************
"'
seed processes
*********************************************************
initialprocesses
unit
* spawn "INITIALPROCS" processes
merge, global:
b: i
loop
i :• 1, INITIALPROCS
do
seedprocess
endloop
*********************************************************
unit
seedprocess
* create an initial process with random values
merge, global:
b: process, queue
do
getptslot( ;process)
if
process 1• 0
$$ if process table is not full
calc
exists(process) :• TRUE
randu
exectime(process), MAXTIME
randu
queue, NUMQUEUES
do
assignpriority(process, queue)
if
queue <• 2
calc
sleeping(process) :• TRUE
end i f
do
enqueue(process)
end if
*********************************************************
unit
assignpriority(process, queue)
* assign priority and CPU values to a process based on its run queue
merge, global:
b: process, queue, randnum
if
queue <• 1
calc
priority(process) :• PZERO
randu
CPU(process), TIMESLICE / TIMEFACTOR
elseif queue
2
calc
priority(process) :• PZERO + 10
---
83
randu
else
randu
calc
+ randnum
if
endif
calc
CPU(process), TIMESLICE
randnum, INCREMENT
priority(process) :• PUSER + INCREMENT
* (queue - 3)
priority(process) > maxpriority
calc
priority(process) :• maxpriority
CPU(process) :• (priority(process) - PUSER) $lsh$ PRIORITYFACTOR
end if
*********************************************************
*
*
*
General purpose units for calculations and scheduling, etc.
*********************************************************
unit
savestate
* save previous state
merge, global:
b: i
prevproc :• run
calc
oldfirst :• first
calc
i :• 1, NUMPROCS
loop
calc
oldnext(i) :• next(i)
calc
oldCPU(i) :• CPU(i)
if
exists(i)
calc
oldpri ( i) :• priority( i)
else
oldpri ( i) :• noexists
calc
endif
endloop
*********************************************************
unit
runproc
* simulate a process running followed by rescheduling
merge, global:
b: i
i: found
update values for old process and enqueue process
if
run I• 0 & exists(run)
if
exectime(run) > TIMESLICE
calc
timeused :• TIMESLICE
do
checkiO
calc
CPU(run) :• CPU(run) + timeused
calc
exectime(run) :• exectime(run) - timeused
do
enqueue(run)
else
do
exit(run)
endif
end i f
* did any process wake up?
do
checkiOcompletion
* update process table
calc
i :• first
loop
i I• NULL
if
-sleeping(i)
do
decay(i)
do
updatepriority(i)
end i f
calc
i :• next(i)
end loop
* find highest priority process
do
pickprocesstorun
* now run the process
*
84
run !• 0
do
dequeue(run; found)
if
~found
$$ can't happen
write
Error-- the process selected to run, <Is, run
1>, is no longer in the queue.
endif
endif
if
*********************************************************
unit
pickprocesstorun
* find the first active process on queue with the best priority
* and set "run" to its PID
merge, global:
b: proc
run :• NULL
calc
proc :• first
calc
bestpriority :• maxpriority + 1
calc
loop
proc !• NULL
if
priority(proc) < bestpriority & ~sleeping(proc)
calc
run :• proc
calc
bestpriority :• priority(proc)
endif
calc
proc :• next(proc)
endloop
********************************************************
unit
bumpnextpid
* bump the value of nextpid with wrap-around from NUMPROCS to FIRSTPID
merge, global:
nextpid :• nextpid + 1
calc
if
nextpid > NUMPROCS
calc
nextpid :• FIRSTPID
end i f
********************************************************
unit
decay( process)
* age the CPU value by applying the decay algorithm
merge, global:
b: process
calc
CPU(process) :• CPU(process) $rsh$ DECAYFACTOR
********************************************************
unit
updatepriority(process)
* update the priority of a process based on recent CPU usage
merge, global:
b: process
calc
priority(process) :• PUSER + (CPU(process) $rsh$ PRIORITYFACTOR)
if
priority(process) > maxpriority
calc
priority(process) :• maxpriority
endif
*********************************************************
unit
getptslot( ;slot)
* return index of first empty slot in the process table;
* if table is full, return 0
merge, global:
b: slot, i
calc
slot :• 0
loop
i :• FIRSTPID, NUMPROCS
if
~exists(nextpid)
calc
slot :• nextpid
85
do
bumpnextpid
out loop
else
do
bumpnextpid
endif
endloop
*********************************************************
enqueue(process)
unit
* add process to end of run queue
merge, global:
b: process
if
last • NULL
calc
first :• process
else
next(last) :• process
calc
endif
calc
next(process) :• NULL
last :• process
calc
*********************************************************
unit
dequeue(process; found)
• remove process from run queue
** note that while a process is always added
* to the end of the queue, it can be removed
* from anywhere in the queue.
calc
calc
calc
loop
merge, global:
b: process, i, prev
i: found
found :• FALSE
i :• first
prev := first
i 1• NULL
$$ found i t !
if
i - process
if
$$ it was first
first • process
first :• next(process)
calc
calc
prev :• first
$$ passes val. to last
else
next(prev) :• next(process)
calc
$$ normal
case
endif
if
-
next( process)
NULL
calc
last :• prev
end if
calc
found :• TRUE
out loop
else
calc
calc
endloop
$$ i t was last
$$ done; get out
$$ keep trying
prev =- i
i :• next(i)
endif
*********************************************************
unit
findqueue(pri; queue)
* find and return queue number for given priority
merge, global:
b: queue
i: pri
if
pri <• PZERO
calc
queue :• 1
else if pri < PUSER
calc
queue :• 2
86
else i f
elseif
else i f
else if
elseif
else
pri <
calc
pri <
calc
pri <
calc
pri <
calc
pri <
calc
calc
PUS!R +
queue
PUSER +
queue
PUSER +
queue
PUSER +
queue
PUSER +
queue
INCREMENT
:- 3
2 * INCREMENT
:- 4
3 * INCREMENT
:- 5
4 * INCREMENT
:- 6
5 * INCREMENT
:- 7
queue :- 8
endif
*********************************************************
unit
exit(proc)
* running process exits from system
merge, global:
b: proc
i: junk
exists(proc) :• FALSE
calc
sleeping(proc) :K FALSE
calc
dequeue(proc~ junk)
do
*********************************************************
checkiO
unit
* use random number to determine whether running process does I/O
merge, global:
b: randnum
randnum, 10
randu
if
randnum - 8 I randnum • 3
randu
timeused, TIMESLICE
calc
sleeping(run) :• TRUE
if
randnum - 8
calc
priority(run) :• PZERO
else
calc
priority(run) :• PZERO + 10
end if
end i f
*********************************************************
unit
checkiOcompletion
* use random numbers to determine if sleeping processes wake up
merge, global:
b: i, randnum
i: found
loop
i :• 1, NUMPROCS
if
sleeping(i) & i I• run
randu
randnum, 10
if
randnum - 3
*
*
*
*
*
*
wake it up; the priority will be
adjusted along with the priorities
of the rest of the processes on the
run queue before rescheduling
calc
do
if
sleeping(i) :• FALSE
found)
found
enqueue(i)
do
calc
wakecnt :• wakecnt + 1
dequeue(i~
87
else
1>, is not here.
$$ can't happen
at
40, 600; 430, 675
write
The sleeping process, <Is, i
end if
endif
endif
endloop
*********************************************************
*
add new process to system
*********************************************************
unit
addprocess
* prompt user for priority value and call routine to
* add process of that priority
merge, global:
b: newproc
i: pri
menu
Help
menu
Add process
menu
Kill process
menu
More details
font
andysans,l6
inhibit arrow
erase
40, 560; 430, 690
at
40, 570
write
Enter priority of new process (<Is, MINPRIORITY I> to <Is, maxpriority
I> l:
arrow
285, 570; 400, 600
compute pri
ok
MINPRIORITY <• pri <• maxpriority
no
at
40, 600
write
Priority value must be an integer between <Is, MINPRIORITY
I> and <Is, maxpriority 1>.
endarrow
at
40, 570
erase
SO, 3
if
pri > PUSER
calc
pri :• ((pri- PUSER) $lsh$ PRIORITYFACTOR) + PUSER
endif
do
addproc(pri; newproc)
newproc I• 0
if
at
40, 570; 430, 690
text
Process <Is, newproc I> has been added and will be displayed when the
screen is updated. It will be eligible for scheduling the NEXT time.
\
menu
Add process: addprocess
endif
menu
Kill process: killprocess
erase
40, 660; 430, 690
40, 660; 430, 675
at
if
newproc I• 0
text
You may add or kill other processes now.
\
else
text
You may kill processes now.
\
endif
pause
4, keys•all
press
zk(space)
erase
40, 560; 430, 690
Q
•
88
menu
if
Help: help
-moreflag
menu
More details: textdriveA
endif
******••·················································
addproc(pri1 newproc)
unit
• add process of given priority to run queue or wait queue
merge, global:
b: newproc, randnum
i: pri
do
getptslot( 1newproc)
if
newproc !• 0
calc
priority(newproc) :• pri
calc
exists(newproc) :• TRUE
randu
exectime(newproc), MAXTIME
if
pri < PUSER
$$ process belongs on wait queue
calc
sleeping(newproc) :• TRUE
randu
CPU(newproc), TIMESLICE- 1
else
$$ process goes on run queue
randu
randnum, 3
calc
CPU(newproc) :• (pri - PUSER) * PRIORITYFACTOR
+ randnum
end i f
enqueue(newproc)
do
else
write message that no more processes can be created
*
at
40, 640
write
The process table is full.
end i f
*********************************************************
*
remove process from system
*********************************************************
unit
killprocess
• prompt user for PID and call routine to
* kill process with that PID, if found, or
* write message
merge, global:
b: pid
i: found
menu
More details
Help
menu
Add process
menu
Kill process
menu
font
andysans,16
inhibit arrow
erase
40, 5601 430, 690
40, 570
at
write
Enter PID of process to kill (<Is, FIRSTPID I> to <Is, NUMPROCS
I>>:
arrow
285, 5701 400, 600
compute pid
ok
FIRSTPID <• pid <• NUMPROCS
no
at
40, 600
write
PID must be an integer between <Is, FIRSTPID I> and
<Is, NUMPROCS I>.
endarrow
at
40, 570
e-rase
50, 3
do
dequeue(pid1 found)
if
found I pid • run
do
kill(pid)
89
at
40, 570; 430, 690
text
Process <Is, pid I> killed.
\
else
at
40, 570; 430, 690
text
Process <Is, pid I> does not exist.
\
end i f
erase
40, 660; 430, 690
menu
Kill process: killprocess
Add process: addprocess
menu
40, 660; 430, 675
at
text
You may add or kill other processes now.
\
4, keys•all
pause
zk(space)
press
40, 560; 430, 690
erase
Help: help
menu
-more flag
if
menu
More details: textdriveA
endif
*********************************************************
unit
kill(pid)
* remove process with given PID from the system
merge, global:
b: pid
do
exit(pid)
*********************************************************
*
*
*
Lesson text units
*********************************************************
*
*
*
*
*
*
*
*
*
*
*
Rules:
1.
Each module is responsible for positioning the
text.
2.
If there is any possibility that a text module
could be called while another font is in effect,
the text module is responsible for setting its
font.
*********************************************************
unit
textdrive(flag; i)
* driver for first set of lesson text displays
*
*
flag determines whether program calls checkmode and clears
* text box.
merge, global:
i: flag, i
loop
i
if
< 8
end if
calc
do
redisplay & i >• -1
calc
i :• i - 1
i
:- i
+ 1
\redisplay & i > 5\showentries(TRUE, FALSE, FALSE)\X
90
font
if
andysans,14
INCREMENT > 1
do
\i\howto\text0\textl\text2\text3\text4\text5\text6\
text7\text8\x
else
\text7\text8\x
endif
if
endif
calc
do
\i\howto\text0\textl\text2\text3\text4\text5a\text6
flag
do
do
do
i ( 8
proceed text
checkmode
cleartext
redisplay :• FALSE
endloop
*********************************************************
unit
how to
* how to run this lesson
cleartext
do
text
40, 430~ 430, 675
To run this lesson:
Each time you are ready to proceed to the next step of the lesson, press
RETURN or select "(Proceed)" from the menu if your are in single step
mode. The lesson starts up in this mode.
To get the menu, hold down the center button if you have a three-button
hold down both buttons if your mouse has only two buttons.
mouse~
You may select "Auto run" from the menu.
by itself at a predetermined rate.
\
menu
help
The program will then proceed
*********************************************************
unit
textO
* schedulers in general
text
40, 430~ 430, 675
In a timesharing system, the process scheduler is the part of the operating
system that determines which of the runnable processes will be allocated
the CPU.
The scheduler is called when the current process cannot continue, when
its time quantum is up, when it terminates, or when a process with a
higher priority may have become eligible to run.
Press RETURN or select ''(Proceed)'' from the menu to continue if in
single step mode.
To run automatically, select ''Auto run•• from the menu.
\
*********************************************************
unit
textl
* introduction to UNIX process scheduler
text
40, 430~ 430, 675
The UNIX process scheduler uses a prioritized round-robin scheduling
algorithm. If all processes have the same priority, the scheduling
is round robin~ otherwise, the highest-priority ready process runs first.
In the UNIX system, the highest priority process has the lowest priority
value.
91
\
*********************************************************
unit
text2
text
40, 430; 430, 675
A part of the process table is shown in the right portion of the screen.
The CPU value is based on the amount of system resources that a process
has used in the recent past. A user-level process priority (PRI) is
related to its CPU value. The process ID number (PID) is not actually
stored in the process table; it is an index into the table.
As you proceed, watch while the values are filled in.
\
-redisplay
if
do
proceedtext
do
checkmode
erase
40, 660; 430, 690
endif
showentries(FALSE, FALSE, FALSE)
do
proceed text
do
*********************************************************
unit
text3
menu
Help
do
\redisplay\showentries(FALSE, FALSE, FALSE)\x
font
andysans,l4
text
40, 430; 430, 675
The priority (PRI) and CPU values for all ready processes are adjusted
periodically, typically once each second. This recalculation of values
causes processes to change to higher priorities as they stay in the
ready state. Eventually, a given process will attain the highest priority
and will be selected to execute.
When a process finishes its turn on the CPU, its priority and CPU values
are modified to reflect the amount of CPU time used, lowering the process
priority. This ensures that CPU bound processes will run less frequently
than I/0 bound ones, giving good response time to interactive processes.
\
*********************************************************
text4
merge, global:
do
\redisplay\showentries(FALSE, FALSE, FALSE)\X
font
andysans,l4
text
40, 430; 430, 675
In the upper left portion of the screen are the prioritized run queues.
The heads of the queues are at the right end. The two queues above
the solid bar (labelled KO and Kl) represent kernel-level priorities.
The remaining run queues (labelled UO through U<ls, NUMQUEUES - 3 l>l
contain user-level runnable processes.
The highest user-level run
queue is the one labelled UO.
unit
As you proceed, watch while the run queues are filled in.
\
-redisplay
if
do
proceedtext
do
checkmode
erase
40, 660; 430, 690
end if
showqueues(450, TRUE)
do
proceedtext
do
*********************************************************
92
unit
textS
* this text is displayed if INCREMENT > 1 (more than 1 priority value
per pictured queue represented)
merge, global:
text
40, 430; 430, 675
Each of the user-level queues shown actually represents <Is, INCREMENT
I> priority values.
The queues for <Is, INCREMENT I> priorities have
been pictured as a single queue for simpler representation, but the
processes selected to run are chosen by their actual priority value.
\
if
-moreflag
do
textmore
endif
*********************************************************
unit
text5a
* this text is displayed if INCREMENT • 1 (1 priority per pictured queue)
merge, global:
text
40, 430; 430, 675
Each of the user-level queues shown contains processes of the same priority
value.
For a given priority, processes that have been in the ready-to-run
state longest are first on their queue.
\
if
-moreflag
do
textmore
endif
*********************************************************
unit
text6
text
40, 430; 430, 675
The kernel-level queues contain processes waiting for some event.
The
priorities of kernel-level processes are based on the reason for waiting.
The highest kernel-level queue, labelled KO, contains processes waiting
at an uninterruptible priority.
These processes are waiting for events
such as disk I/O completion, the availability of a free inode or buffer,
or for swapping.
In this implementation, processes in this queue have
priority values from <Is, MINPRIORITY I> to <Is, PZERO 1>.
The other kernel-level queue, labelled Kl, contains processes waiting
at an interruptible priority.
These processes are waiting for events
like TTY input or output or a child exit. Processes in this queue have
priority values from <Is, PZERO + 1 I> to <Is, PUSER- 1 I> in this
implementation.
\
*********************************************************
unit
text7
text
40, 430; 430, 675
You can add a process to the scheduler simulation once the scheduler
begins to run.
To do so, select ''Add process'' from the menu when
you are told that you may add processes.
You can remove a process
by selecting ''Kill process''·
If at any time the number of processes in a queue exceed the space for
depicting them, the additional processes will not be shown, although
they are in the queue.
They will be displayed as room is freed in their
queue.
\
*********************************************************
93
unit
textS
text
40, 430; 430, 675
The scheduler will now begin to run and schedule processes. Important
events during the process execution and scheduling will be pointed out
as they occur.
Watch the right two columns of the process table as they are updated.
Then the new run queues will be shown.
\
Help: help
menu
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
unit
textmore
text
40, 530; 430, 675
Select ''More details'' now from the menu if you want more information
about the scheduler simulation.
\
More details: textdriveA
menu
*********************************************************
unit
textgenl
* text for each run of the scheduler
merge, global:
b: randnum
font
andysans,l4
calc
looptime :- 8
do
cleartext
text
40, 430; 430, 675
The new CPU and priority (PRI) values are calculated for all ready processes.
The scheduler then executes the scheduling algorithm, selecting the
next process to run.
As it updates the process table and queues, this simulation saves the
previous values so that you can compare them with the new ones to see
what changed.
\
40, 560; 430, 690
erase
-redisplay
if
randu
randnum, 10
endif
*
case
randnum
3
text
40, 580; 430, 675
Can you predict which process will be scheduled to run next?
\
10
text
40, 580; 430, 675
Which process will run next?
\
endcase
proceed text
do
do
checkmode
erase
40, 560; 430,690
*********************************************************
text add
unit
* give user a chance to add process
menu
Add process: addprocess
menu
Kill process: killprocess
erase
40, 560; 430, 690
font
andysans,l4
text
40, 570; 430, 675
94
Q
If you would like to add a process now, you may select ''Add process''
from the menu.
You may remove a process by selecting ''Kill process''.
"
do
do
erase
menu
menu
proceed text
checkmode
40,560; 430, 690
Add process
Kill process
*********************************************************
unit
nulltext
* text when the NULL process executes
do
cleartext
font
andysans,l4
text
40, 430; 430, 675
Since there are no ready-to-run processes, the NULL process is selected
to execute.
\
do
checkmode
*********************************************************
unit
sleeptext(proc)
* text when running process waits for I/O
b: proc
do
cleartext
pause
0.5
font
andysans,l4
text
40, 430; 430, 675
The running process, <Is, proc 1>, will enter a kernel-level queue to
wait for I/O completion.
\
andysans,22
font
printlarrow(470)
do
*********************************************************
wake text
unit
* text when one or more processes wake up
merge, global:
cleartext
do
0.5
pause
andysans,14
font
wakecnt • 1
if
text
40, 470; 430, 675
A process completes I/O and will return to the run queue.
\
else
text
40, 470; 430, 675
<Is, wakecnt I> processes complete I/O and will reenter the run queue.
\
endif
printlarrow(470)
do
do
proceed text
checkmode
do
*********************************************************
exittext(proc)
unit
* text when current process exits
merge, global:
b: proc
i: y
•
95
do
cleartext
pause
0.5
font
andysans,l4
text
40, 430: 430, 675
The running process, <js, proc j>, exits.
\
printrarrow(535)
do
andysans,14
font
calc
y :• 22 * prevproc - 92
erase
760, y: 865, y + 15
*********************************************************
routinetext(proc)
unit
* text when nothing of note happens
b: proc
do
cleartext
pause
0.5
font
andysans,14
text
40, 430: 430, 675
Process <js, proc I> completes its time quantum.
\
*********************************************************
unit
proceedtext
* after erasing line and setting font, print message to proceed when
ready
-auto run
if
erase
40, 660: 430, 690
font
andysans,14
text
40, 660: 430, 675
Proceed when ready.
\
end i f
*********************************************************
*
text unit selected by "Help" menu option
*********************************************************
unit
help
* selected from the menu
font
andysans,l4
erase
40, 560: 430, 690
text
40, 560: 430, 675
To run in single-step mode, select ''(Proceed)'' from the menu or press
a key.
To run automatically, select ''Auto run'' from the menu.
To return to single-step mode, select ''Single step'' from the menu.
To add a process, select ''Add Process'' when told that you can do so.
To remove a process, select ''Kill process'' when told that you can.
\
if
auto run
pause
5
endif
*********************************************************
*
text units selected by "More details" menu option
*********************************************************
unit
menu
calc
calc
if
textdriveA
merge, global:
More details
moreflag :• TRUE
inmore :• TRUE
redisplay
96
if
textnum >• 8
do
showentries(TRUE, FALSE, TRUE)
else
do
showentries(TRUE, FALSE, FALSE)
endif
end if
loop
morenum
do
font
do
do
calc
< 4
cleartext
andysans,14
\morenum\x\detail0\detaill\detail2\detail3\x
checkmode
morenum :• morenum + 1
endloop
cleartext
do
calc
inmore :• FALSE
textnum < 8
if
do
textdrive(FALSE; textnum)
end if
proceed text
do
*********************************************************
unit
detailO
text
40, 430; 430, 675
The algorithm for updating the CPU value varies with different versions
of the UNIX system. This simulation uses the System V algorithm
CPU • CPU / 2
where the division is integer division with truncation.
by shifting right.
\
do
proceedtext
This is accomplished
*********************************************************
unit
detail!
text
40, 430; 430, 675
After the CPU value is updated, the priority is updated using the new
CPU value. Again, different versions of the UNIX system use different
algorithms.
This simulation uses the following algorithm, which is
based on System V
priority • CPU /
2 + lowest user-level priority value
where the division is integer division with truncation and the lowest
user-level priority value is <Is, PUSER 1>. This is also done by shifting
right.
\
do
proceedtext
*********************************************************
detail2
unit
text
40, 430; 430,675
Random numbers are used by this simulation to determine when certain
events take place. These events include
1.
The completion of I/0 by a process which is waiting at kernel level
2. Voluntary release of the CPU by a running process that can no longer
continue to run, usually because it must wait for I/0.
\
do
proceedtext
97
*********************************************************
unit
detail3
text
40, 430; 430, 67S
To determine when a process completes execution and exits, this simulation
assigns a random number to each process when the process is created.
This number represents the total CPU time required by that process.
After each run, the amount of CPU time used by the process is subtracted
from the original random number. When the result reaches zero, the
process exits.
\
do
proceedtext
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
*
*
Display routines
*
*********************************************************
unit
screensize
* prompt user to make screen a reasonable size
font
andysans,14
if
zwidth < 8SO & zheight < 700
text
SO, SO
PLEASE MAKE THE WINDOW BIGGER
\
pause
keys-all
else if zwidth < 8SO
so, so
text
PLEASE MAKE THE WINDOW WIDER
\
keys•all
pause
else if zheight < 700
SO, so
text
PLEASE MAKE THE WINDOW TALLER
\
pause
keys-all
endif
so, so
at
so
erase
********************************************************
unit
display
* display title, process table, run queues, and text box
do
title
do
drawforms
do
textbox
**********************************************************
unit
subdisplay(flagl, flag2)
* display contents of process table and run queues;
* show PID of running process
*
*flags are passed to showentries() to determine whether
* previous queues are shown (flag!) and if there are pauses
* while writing process and queue information (flag2)
i: flag!, flag2
showentries(TRUE, flag!, flag2)
do
andysans,14
font
**********************************************************
unit
title
98
* print
at
font
write
font
at
write
at
write
at
font
write
title and label displays
280, 0
andysans,30
THE UNIX* PROCESS SCHEDULER
andysans,20
180, 40
Run Queues
620, 40
Process Table ( partial )
5, 710
andysans,12
* UNIX is a registered trademark of AT&T
*********************************************************
drawforms
unit
* draw outlines of tables, queues, etc.
merge, global:
do
drawqueues
do
drawptable
runningproc
do
prevrunningproc
do
•********************************************************
drawqueues
unit
* draw the graphic representation of the queues
b: i
i: y
20, 78; 450, 345
box
draw
20, 100; 450, 100
draw
20, 130; 450, 130
20, 160; 450, 160
draw
fill
20, 160; 450, 165
loop
y :- 165, 315, 30
draw
20, y; 450, y
endloop
235, 78; 235, 345
draw
font
andysans,16
95, 83
at
Previous
write
315, 83
at
write
Current
0, 110
at
KO
write
0, 140
at
write
K1
calc
i :- 0
loop
y :- 175, 325, 30
at
0, y
write
U<js, i I>
calc
i :- i + 1
endloop
**********************************************************
unit
drawptable
* draw the process table and label its fields
i: y
draw
draw
draw
box
draw
loop
650,
650,
870,
575,
575,
y :draw
78; 870, 78
78; 650, 100
78; 870, 100
100; 870, 697
125; 870, 125
145, 675, 22
575, y; 870, y;
99
end loop
font
at
write
at
write
at
write
at
write
at
write
at
write
at
write
draw
draw
andysans,l6
675, 83
Previous
785, 83
Current
605, 105
PID
660, 105
PRI
710, 105
CPU
765, 105
PRI
815, 105
CPU
650, 100; 650, 697
755, 78; 755, 697
*********************************************************
unit
showentries(flagl, flag2, flag3)
i: flagl, flag2, flag3
• print the process information in the
• process table and the queues
•
•
•
•
•
•
flagl determines whether current queues are shown;
flag2 controls whether previous queues are shown;
flag 3 indicates whether there are to be pauses during
the writing of process and queue information
do
do
if
ptableentries(flag3)
showrunningproc
flagl
do
showqueues(450, flag3)
endif
if
end if
font
flag2
do
showprevqueues(235)
andysans,l4
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
unit
ptableentries(flag)
• print values in process table
•
*
flag determines whether there are pauses as values are filled in
merge, global:
b: i
i: xl, x2, y, flag
font
andysans,22
calc
xl :• 155
x2 :• 50
calc
loop
i :• FIRSTPID, NUMPROCS
calc
y :• 22 • i - 92
if
oldpri(i) I• noexists
$$ print previous values if
old process existed
do
writenum(i, x2 + 555, y)
writenum(oldpri(i), x2 + 610, y)
do
do
writenum(oldCPU(i), x2 + 665, y)
if
flag
pause
0.5
end if
else
if
-exists(i)
$$ erase entire entry
if previous & current don't exist
100
erase
578, y; 648, y + 15
end i f
end if
if
else
exists( i)
$$ print current values
do
writenum(i, xl + 450, y) .
if
-sleeping(i) I i - prevproc 1 oldCPU(i) I• CPU(i)
if
flag
0.2
pause
endif
at
xl + 655, y
erase
5
end if
do
writenum(CPU(i), xl + 665, y)
-sleeping(i) I i • prevproc I oldpri(i) I• priority(i)
if
if
flag
pause
0.3
endif
xl + 610, y
at
erase
5
end i f
do
writenum(priority(i), xl + 610, y)
if
-sleeping(i) & flag
1 i - prevproc
pause
0.5
end if
$$ erase current entry if process doesn't exist
calc
y :- 22 • i - 92
erase
xl + 603, y; xl + 703, y + 15
end i f
endloop
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
unit
showrunningproc
* print PID of running process in box
merge, global:
font
andysans,22
writenum(run, 500, 130)
do
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••
unit
runningproc
* draw a box labelled "running"
merge, global:
andysans,20
font
at
475, 90
Running
write
490, 120; 530, 160
box
*********************************************************
unit
showoldproc
* print PID of running process in box
merge, global:
at
500, 230; 530, 245
erase
3
font
andysans,22
do
writenum(prevproc, 500, 230)
*********************************************************
unit
prevrunningproc
• draw a box labelled "previous"
merge, global:
font
andysans,20
475, 190
at
write
Previous
101
box
490, 220:530, 260
********************************************************
unit
showqueues(x, flag)
* print the PIDs of all processes in the queues
**
flag determines whether there are pauses as
* PIDs are written in queue
font
zero
calc
loop
merge, global:
b: i, queue
i: x, flag
andysans,20
inqueue
i :• first
i
if
I• NULL
exists(i)
if
i
I•
run
do
calc
do
endif
end if
calc
findqueue(priority(i): queue)
inqueue(queue) :• inqueue(queue) + 1
printproc(i, queue, x, flag)
i :• next(i)
endloop
********************************************************
showprevqueues(x)
unit
* print the PIDs of all processes in the queues
merge, global:
b: i, queue
i:
font
loop
X
andysans,20
i
:• 1, NUMQUEUES
calc
endloop
calc
i
loop
i
inqueue(i) :• 0
:- oldfirst
I• NULL
if
end i f
oldpri ( i) I• noexists
if
i I• prevproc
do
findqueue(oldpri(i): queue)
calc
inqueue(queue) :• inqueue(queue) + 1
do
printproc(i, queue, x, FALSE)
endif
calc
i :• oldnext(i)
endloop
********************************************************
printproc(process, queue, x, pauseflag)
unit
* print pid of process at its location in run queues
merge, global:
b: process, queue
i: x, xpos, ypos, pauseflag
calc
xpos :• x - (inqueue(queue) * 25)
if
xpos > x - 215
if
queue < 3
calc
ypos :• 75 + (queue • 30)
else
calc
ypos :• 80 + (queue * 30)
endif
do
(process, xpos, ypos)
writenum
if
pause flag
pause
0.3
102
endif
endif
*********************************************************
unit
writenum(num, x, y)
• write an integer padded with a blank if less than 10
b: num
i: x, y
andysans,22
font
num < 10
if
text
x, y; X + 30, y + 15
<Is, num I>
\
else
text
X, Yi X+ 30, y +-15
<Is, num I>
\
end i f
*********************************************************
unit
textbox
• draw box that contains the lesson text
box
2 0, 4 0 0; 4 50, 6 9 5
*********************************************************
unit
printrarrow(x)
* print arrow pointing toward right at
• x position given by x.
i : x, y
calc
y :- 130
andysans,22
font
x, y
at
write
>
pause
0.5
x, y
at
erase
1
x, y
at
write
·>
0.5
pause
x, y
at
erase
2
x, y
at
write
-->
0.5
pause
*********************************************************
unit
printlarrow(x)
* print arrow pointing toward left at
• x position given by x.
i:
calc
at
font
write
pause
at
erase
calc
at
write
pause
at
y
X,
y :• 120
x, y
andysans,22
<
0.5
9, y
X
3
:•
x, y
X
X
-
<-
0.5
X
-
9, y
9
103
erase
calc
at
write
font
pause
4
X :• X -
x, y
9
<--
andysans,l4
0.5
*********************************************************
unit
• erase
do
erase
erasecontents
numbers in queue, erase current process
erasequeues(233)
495, 125J 525, 155
*********************************************************
unit
erasetable(x)
* erase PRI and CPU values in process table
merge, global:
b: i
i: x, y
loop
endloop
i :• FIRSTPID, NUMPROCS
calc
y :• 22 * i - 92
erase
x, y; x + 90, y + 15
*********************************************************
unit
erasequeues(x)
* erase PIDs in run queues
* x is leftmost position of queue
merge, global:
b: i
calc
calc
erase
erase
loop
endloop
i: x, y, min, max
min :- X + 4
max :- X + 215
min, lOS, max, 120
min, 135; max, 150
i :- 3, NUMQUEUES
calc
y :• i * 30 + 80
erase
min, y; max, y + 15
*********************************************************
unit
• erase
at
erase
at
erase
erasearrows
any possible arrows pointing to screen features
452, 120
4
535, 130
4
*********************************************************
unit
c1eartext
* erase the lesson text
erase
30, 430J 430, 690
*********************************************************
unit
autorunon
* called when "Auto run" is selected from menu
merge, global:
menu
Auto run
menu
Auto run
104
calc
press
menu
autorun :• TRUE
zk(space)
Single step: autorunoff
*********************************************************
unit
autorunoff
* called when "Single step" is selected from menu
merge, global:
menu
Single step
calc
autorun :• FALSE
menu
Auto run: autorunon
*********************************************************
unit
checkmode
* this routine allows faster switching of
* modes between auto run and single step
merge, global:
b: i
loop
i :• 1, looptime
auto run
pause
1
else
outloop
endif
if
end loop
if
endif
-auto run
pause
*********************************************************