The Structure of the “THE”-Multiprogramming System

Edsger W. Dijkstra

Jimmy Pierce

Progress Report on the multiprogramming effort at the Departmentof Mathematics at the Technological University in Eindhoven.

(1968)

EL X8 Modern2.5 μsMemory Cycle Time

Address Size

Memory Size

27 bits

32K

5 - 70 ns

64 bit

1 - 2 GB

Goals

• Reduction in turn around time for programs of short duration

• Economic use of peripherals

• Automatic control of backing store with economic use of central processor

• Economic feasibility to use machine for programs which only need flexibility of the processor and not the capacity or power of it

• NOT multi access system

• Testable

Guiding Principles

• Select project as ambition as justifiably possible

• Select a machine with sound basic characteristics

• Experience does not lead to wisdom and understanding

Don’t over incorporate features that only add work

Don’t depend on specific properties of a machine

Make an effort to learn as much as possible from past experiences

Layered Operating System

Layered Operating System

Bottom layers provide abstraction of resources

Top layers access lower levels for resources

Access always proceeds from top down

Testing

Done in stages

Bottom layer thoroughly tested before implementing layerabove

Allows full system testing in manageable time

5 + 5 + 5 + 5 + 5 + 5 vs. 5 * 5 * 5 * 5 * 5 * 5

“… testing had not yet been completed, but the resulting system isguaranteed to be flawless.”

Contains:Processor Allocation

Real-time Clock Interrupt

Provides:Processor Abstraction

Each process appears to have own processor

Level 0

Processor Allocation

Only unidirectional passing of time through various programstates has meaning, not amount of time

Delaying of process execution will have no harmful effectsto the internal logic of the process

Thus numerous processes can be executing independentlyof number of actual processors, as long as processors canswitch to the various processes

Semaphores used to regulate cooperation between processes

Semaphores

Integer variable initialized to 1 or 0

P decrements variable and places process on a waiting list if new value is negative

Works since delaying a process has no ill effects

Two atomic methods, P and V

V increments variable and removes a process from waiting list ifnew value is non-positive

Mutual Exclusion

Protection of critical sections

Mutex is globally accessible

mutex = 1;

P(mutex); critical sectionV(mutex);

Private Semaphores

Used to block process while configuring environment( creation of reader-writer buffer )

mutex = 1;privateSemaphore = 0;

P(mutex); modify global state variables V(privateSemaphore);V(mutex);

P(privateSemaphore);

Private semaphore can be released globally but only lockedprivately

Contains:Segment Controller

Provides:Memory Abstraction

Each process has a segment of memory to use

Level 1

Memory Allocation

Unique identifiers for each segment of memory

Detaches memory from core or drum identifier

Memory can be located in any page at core or drum

Segment identifier in core indicating segment is (non)emptyand page address

Memory swapped out of core does not have to return to samedrum page from which it originated

Contains:Message Interpreter

Provides:Device Abstraction

Each process has own individualdevice handle

Level 2

Message Interpreter

All processes share console using mutual synchronization

Process sends message to console with an identification header

Handles interaction between processes and the user

Operator must identify which process to communicate with

Memory segments contain vocabulary for messages

Contains:Communication Units

Provides:Logical Communication Units

Buffering is handled automaticallyvia communication channels

Level 3

Communication Buffering

Mutual exclusion needed to allocate peripherals to processes

Processes must be able to communicate with operator( hardware failure, anomalous conditions )

Peripherals wrapped by buffers and abstracted to logicalcommunication units

Contains:Independent User Programs

Provides:Independent user code

to be executed “simultaneously”

Level 4

Contains:The Operator

Sold Separately

Level 5

Proving Harmonious Cooperation

Processes at rest are at homing positions

When process accepts task, it leaves homing position

Upon return from task, process returns to homing position

Facts:

Processes performing a task will only generate a finitenumber of tasks for other processes

Processes can only generate tasks at a lower level

Thus cannot have circular process calls

Attention must be paid to ensure process requesting segment from segment controller remains in core when call returns

It is impossible that all processes have returned to homingpositions while there is still a generated, pending,

unaccepted task

Calls leave homing positions when tasks are accepted

Calls to lower levels cause higher levels to block until call returns

Calls return to homing positions when tasks are completed

Each process will eventually return to homing positionafter accepting a task

Calls cannot generate an infinite number of child procedures

Any blocked calls are due to lower process performing work onthe higher level’s behalf

Unidirectional flow through layers prevents circular waits ( A waiting on B waiting on C waiting on A )