Review of The Structure of the “THE”-Multiprogramming System Edsger W. Dijkstra Technological University, Eindhoven, The Netherlands Communications of the ACM, 11(5):341--346, 1968 Presented by Rachel Cool PSU-CS 533-Winter 2010

Goals of the Multiprogramming System Process smoothly a continuous flow of user programs Reduction of turn-around time for programs of short duration Economic use of peripheral devices Automatic control of backing store to be combined with economic use of the central processor Economic feasibility to use the machine for multiple apps Not intended as a multi-access system

System Hardware Electrologica X8 32K core memory, 2.5msec 512K word drum, 1024 words per track, 40msec rev. time Indirect addressing Commanding peripherals and controlling interrupts Low capacity channels, 10 are used 3 paper tape readers at 1000 char/sec 3 paper tape punches at 150char/sec 2 teleprinters 1 plotter 1 line printer

Storage Allocation Memory units – core pages and drum pages Information units – segments A segment fits in a page Segment identifier gives fast access to a segment variable Segment variable value tells if the segment is empty or not If the segment is not empty, the value denotes which page(s) the segment can be found A core page can be dumped onto a free drum page – will choose the one with the minimum latency time (beginning of the paged virtual memory abstraction) A program does not have to occupy consecutive drum pages

Processor Allocation Only the time succession of various states has logical meaning for a process, not the actual speed of execution Mutual synchronization allows for cooperation between sequential processes Processor switches from process to process, temporarily delaying the progress of the current process The system is designed in terms of the abstract “sequential processes” (beginning of the process/thread abstraction)

Synchronizing Primitives Semaphores are initialized with the value of 0 or 1 P-operation decreases value of a semaphore by 1 If result is non-negative, process can continue If result is negative, process is stopped and is put on waiting list V-operation increases value of a semaphore by 1 If result is positive, operation has no further effect If result is non-positive, a process on the waiting list is removed and able to continue progress once allocated to a processor (it is undefined which process is removed if there is more than one process on the waiting list) Semaphores are used in the design as either mutexes or as condition synchronization mechanisms

Mutual Exclusion Maximum value of mutex equals 1 begin semaphore mutex; mutex := 1; parbegin begin L1: P(mutex); critical section 1; V(mutex); remainder of cycle 1; go to L1 end; begin L2: P(mutex); critical section 2; V(mutex); remainder of cycle 2; go to L2 end parend Maximum value of mutex equals 1 Minimum value of mutex equals –(n-1) if there are n parallel processes

Private Semaphores Used as condition synchronization mechanisms Each sequential processes has a number of private semaphores Initialized to 0; range -1 to 1 When progress of a process depends on current values of state variables: P(mutex) “inspection and modification of state variables including a conditional V(private semaphore)”; V(mutex) P(private semaphore) When blocked processes should get permission to continue: P(mutex); “modification and inspection of state variables including zero or more V-operations on private semaphores of other processes”; V(mutex)

Harmonious Cooperation Sequential processes regarded as cyclic processes Each process has a “homing position” when at rest Processes leave homing position to accept a task and cannot return until task is completed A single initial task cannot generate an infinite number of tasks since processes can only generate tasks for processes at lower levels of the hierarchy Impossible for all processes to be in their homing positions while there is still a pending an unaccepted task After acceptance of an initial task, all processes will eventually return to their homing position Each blocked process relies on other processes to unblock Absence of “circular waits”: P waiting for Q waiting for R waiting for P

System Hierarchy THE admits to a strict hierarchical structure Consists of 6 layers Level 5 - Operator Level 4 – User Programs Level 3 – Buffering I/O Level 2 – Message Interpreter Level 1 – Segment Controller Level 0 – Processor Allocation

Level 0 – Processor Allocation Responsible for processor allocation to a process Real-time clock interrupts prevent a process to monopolize the processor Priority rule included Above this level, the number of processors shared is no longer relevant At higher levels, the actual processor has lost its identity

Level 1 – Segment Controller Consists of a sequential process synchronized with the drum interrupt and sequential processes of higher levels Responsible for memory storage and allocation Provides a level of abstraction where higher levels identify information in terms of segments At higher levels, the actual storage pages have lost their identity

Level 2 – Message Interpreter Works closely with the operator – when a key is pressed, the character along with an interrupt is sent to the machine Printing is done via output command generated by the message interpreter Manages ‘conversations’ between operators and processes Above this level, each process thinks it has its own private console; the console teleprinter has lost its identity Satisfied by mutual synchronization, “only one conversation at a time” restriction is placed since the processes share the same physical console

Level 3 – Buffering I/O Buffering of input streams Un-buffering of output streams Placed above level 2 to allow conversations with the operator (for error detection) Abstracts the actual peripherals to higher levels as “logical communication units”

Levels 4 and 5 Level 4 contains independent-user programs Level 5 is the operator The EL X8 Operator's Console Image from http://www.science.uva.nl/museum/X1.html

Testing Verification of the system began at level 0 Portions of higher levels were not added until previous levels were thoroughly tested Level 0: inspection that under all circumstances processor time was divided among sequential processes Level 1: all relevant states were formulated in terms of sequential processes making demands on core pages If not for separation between levels 0 and 1, the number of relevant states would have increased to the point that exhaustive testing would not have been possible Testing had not completed at the time paper was written

Conclusions Concepts introduced in the paper are taken for granted today Process/thread abstraction Paged virtual memory abstraction Use of semaphores Implementation of independent abstractions via hierarchical levels Hierarchical structure was vital for verification Levels of complexity were removed at each layer Logical soundness can be proved early At each stage, the number of relevant cases were small enough to allow testing of all and remove doubts about the system Testing was able to continue even after drum channel hardware broke down