Review of The Structure of the “THE”-Multiprogramming System

1. Review ofThe 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

2. 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

3. 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

4. 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

5. 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)

6. 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

7. Mutual Exclusion 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 end • Maximum value of mutex equals 1 • Minimum value of mutex equals –(n-1) if there are n parallel processes

8. 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)

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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”

15. 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

16. 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

17. 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