You are on page 1of 4

Systems Architecture 2 - Cooperation and

Preemption

Outline
In this essay I will talk about the history of running programs on computers, the reason
cooperative or pre-emptive multitasking is important to this, how they work, the
hardware and software support required and their strengths and weaknesses.

Introduction
Cooperation and pre-emption are two different approaches to solving the same
problems: how do we run multiple processes on the same machine? When two or more
processes can be run, which should be run first? The Operating System [OS] must
decide, using a scheduler to make this decision. It must make an informed decision
based on information about the processes, to ensure that each process gets a fair share
of the CPU, preventing starvation, minimises CPU idling, is responsive to human user
input, and maximises turnaround - the completion of batch jobs, and throughput
- number of jobs processed in a given time.

History

Computer use was inefficient and time consuming

From the 1940s to mid-1950s, computers had no OS and users had to interact directly
with the machine hardware. It was very inefficient; users had to schedule machine time
by reserving it on a paper timesheet, and if their program finished before their allotted
time the CPU would just lay idle until the next user came, losing money. Furthermore, if
their program overran the booking, their program would be stopped altogether - the
user would never get their output printed. It was also very time consuming to set up;
each user had to load in their compiler and source code into the card reader, compile,
and load and link the object program and common functions - all involving huge punch
card decks. If there was an error, they had to load it in all over again.

Maximise CPU usage to save money

The batch OS, introduced in the mid-1950s, involved the user submitting a job (their
program plus operands, etc.) to the Computer Operator. He then stacked up all of the
cards together in sequence - in a batch, and placed all of them into the reader. The
reader would then write the job contents onto magnetic tape. Controller software on the
computer, called the Monitor, automated the role of loading in each program from the
tape in turn. Running the programs went like this: Monitor runs Program1. Program1
finishes, Program1 writes to output tape, then returns control to Monitor. Monitor runs
Program2, etc. This is the first multitasking method used, and is an improvement on
the 1940s in that jobs are executed much quicker without CPU idling. Unfortunately, the
card reader and output printer still slowed down the procedure. The problem still exists
that if a programmer makes a mistake, they only find out after the printer has outputted
their results, and printers were slow. Multiprogramming allowed the computer to run
Program2 while Program1 was writing to the output tape.

Why Cooperation or Pre-emption are needed

Cooperation

By the 1960s, computers had evolved to be used in interactive mode - responding to


user input as it received it - and batch multiprogramming was not enough to provide this
functionality. Interactivity was especially important to transaction
processing. Timesharing was developed to cater for this need, using the existing large
computers as mainframes to serve many users at once. It gave each user the illusion
that their program had sole ownership of the CPU time, but in reality, multiprogramming
was being used to manage multiple interactive jobs. Cooperative
multitasking required programs to voluntarily give up CPU time to each other, and was
needed so that each got a turn to run. It was used in Mac OS 9, and DOS.

Pre-emption

With both interactive processes and compute intensive processes now being valid
types of processes coexisting on one machine, there became a need to distinguish
between and manage these types, so that each process would be handled appropriately.
In addition to this, we need a way to protect the programs from the monitor, and from
each other. Pre-emptive multitasking utilized interrupts to allow the CPU take over,
and make decisions about processes on the OS, preventing them from running for too
long.

How they work

Cooperation

Cooperation is quite simple. For example, a running process on Mac OS 9 has full control
of the CPU, until it decides to make a system call to yield the CPU for another process.
This implementation is similar in other OSs.

Pre-emption

Interrupts make pre-emption possible by returning control back to the CPU at regular
intervals. The interrupts allow the scheduler to either 1) Return control to the currently
running process, 2) Schedule another process using a scheduling algorithm, or 3) Kill
the process. If the scheduler decides to do 2), we need to decide which other process to
schedule, so each process must have a priority - the higher the priority, the more likely
the process owning that priority will get scheduled next. The scheduler may change the
priority throughout the life of the process due to the process changing between
being CPU bound to I/O bound, or other reasons. Once a suitable process has been
selected, the OS must save the state of the current process using a context switch.
This involves saving all the data associated with the process - which could be registers,
memory maps, tables and lists. It must then load in the relevant registers, etc. saved for
the process taking its place. An example of a pre-emptive scheduling algorithm is
Shortest Remaining Time [SRT]. SRT involves calculating an expected completion
time for each process, and choosing the shortest time of these.
Hardware and Software support

Cooperation

No special hardware other than a standard computer architecture is required, but it is


good to have enough fast memory to hold multiple processes in it at once, to avoid
regular swapping - the storage and retrieval of a process and associated data to/from
disk. The software required is a monitor. It usually has two parts - a resident
monitor which stays in memory and schedules jobs one by one, and the rest of the
monitor contains common functions and utilities like printing, displaying text on a
teletype display, etc. Signals

Pre-emption

A hardware interrupt requires a hardware clock or timer to send the interrupts at


intervals of around 100msecs so that the CPU can take over. The computer will need a
place to save the state of each process and its state of execution - this could be volatile
memory like RAM or a disk. The scheduling algorithm is implemented in software, as well
as the run queue - which keeps track of each process's information, including priorities.
In addition to this, there are various related software constructs which prevent some of
the problems that arise from multitasking with shared resources, such
as semaphores and mutexes.

Strengths and Weaknesses

Cooperation

One strength of cooperation is its simplicity - the method means there is very little
overhead affecting the CPU giving more time to running processes, which is our goal.
However, it suffers from many weaknesses. What if the programs don't want to
cooperate? As I talked about in the history section, the Monitor was very simple - it
would just run each program in sequence. It relies on trust, since it could be easily
exploited - and was: some programmers would maliciously design their program to
starve other jobs of CPU time altogether, so they could have true sole use of the CPU.
More innocent programmers may simply make a mistake and overwrite the Monitor or
another jobs data, or cause an infinite loop - rendering the system unusable. In fact,
these were problems of Mac OS 9 - a program that didn't want to play nicely could bring
down the whole OS. This is bad, and to stop this, we need the to regularly suspend the
running process to forcibly give control back to the OS, and thus the concept of
interrupts and pre-emptive multitasking - deciding what to do with the suspended
process, was introduced.

Pre-emption

As mentioned, pre-emption combined with scheduling prevents runaway and malicious


processes from bringing the system to it's knees. But because any process can be
suspended at any moment, race conditions - synchronisation problems that arise from
sharing resources - are possible, and thus require the need of the semaphores and
mutexes - signalling and locking devices on those resources. Other problems include the
overhead of interrupts. Interrupts will intermittently pause the running process, even if
there are no other processes waiting to use the CPU, so a cooperative method may be
preferred. The frequency of interrupts is a tradeoff - high frequency interrupts are good
for interactive processes, and low frequency interrupts are good for compute intensive
processes, and a good scheduler tries finds a balance between the two. Schedulers can
be 'too good' though - if the scheduler spends more time deciding which process to
schedule, than the OS spends running processes, the OS is said to be thrashing.

Conclusion
Pre-emption and cooperation attempt to be fast but fair, and an attempt to find a
balance is ongoing. Pre-emption seems to be the best way to manage multiple tasks
running on the same machine, with its added protection, but also has its drawbacks and
complications.

References
BRADFORD, R, 2010, CM10195: Systems Architecture 2 [online]. Lecture slides,
Available from: http://people.bath.ac.uk/masrjb/CourseNotes/cm10195.html. Accessed
25/03/10
STALLINGS, W., 2005, Operating Systems Internals and Design Principles, Prentice Hall
TANENBAUM, A., 1992, Modern Operating Systems, Prentice Hall

You might also like