the structure of “the” – multiprogramming system by edsger w. dijksta technological...
Post on 20-Dec-2015
216 views
TRANSCRIPT
The Structure of “THE” – Multiprogramming System
by
Edsger W. DijkstaTechnological University, Eindhoven,
Netherlands.
Presented by Navya Jammula
What is the paper about?
The Conception, Construction and Verification of a multiprogramming system – “THE” (Technische Hogeschool Eindhoven)
Outline
Goal Hardware configuration used System Components Synchronization Primitives Experience Mistakes Concerns
Goal
Process smoothly a continuous flow of user programs.
Objectives
Reduction of turn-around time for programs of short duration
Economic use of peripheral devices Efficient use of Memory and Processor. Support programs that need the flexibility of
general purpose computer without the capacity and the processing power
Tool Dutch Electrologica EL X8 computer
32K core memory (cycle time 2.5usec)
512K words drum (1024 words per track, 40msec rev )
An indirect addressing (suited for stack implementation)
Low capacity channels supporting peripherals (3 paper tape readers and punches, printer, plotter, and 2 teleprinter)
A sound control of interrupts and peripherals
System Components
Storage Allocation Processor Allocation System Hierarchy
Storage Allocation
strict distinction between memory units and corresponding Information Units
Pages Core Pages Drum Pages
Segments A segment fits in a page.
Storage Allocation Contd. Number of possible segment identifiers is
much larger than the total number of pages in primary and secondary store.
The segment identifier gives fast access to a so-called “segment variable” in core whose value denotes Whether the segment is still empty or not, If not empty, in which page (or pages) it can be
found.
Consequences No need to return the segment to the same
drum page from which it originally came Can select one from among the free drum pages
with minimum latency time.
Total absence of a drum allocation problem A program need not occupy consecutive drum
pages
Processor Allocation In a single sequential process only the time
succession of various states has a logical meaning, but not the actual speed with which the sequential process is performed.
Hence the whole system can be arranged as a society of sequential processes, progressing with undefined speed ratios
Society of Sequential Processes
Each user program accepted by the system Each input peripheral (buffering input streams in
synchronism with the execution of the input commands),
Each output peripheral (unbuffering output streams in synchronism with the execution of the output commands);
Segment Controller associated with the drum Message Interpreter associated with the console
keyboard.
How do these processes co-operate with each other Using Explicit Mutual Synchronization
statements. Semaphores Private Semaphores
System Hierarchy “THE” system admits a strict hierarchical
structure.
THE has six Layers, levels 0 – 5
Each layer builds an abstraction hiding the details below it
Each layer uses only the functionality of the lower layers
Level 0
Responsible for processor allocation to one of the processes whose dynamic progress is logically permissible
It deals with interrupts and performs the context switches when a process change is required.
A priority rule is incorporated to achieve quick response of the system
Above level 0 the number of processors actually shared is no longer relevant
This is the first level of abstraction
Level 1 The segment controller is present at this
level. Responsible to cater to the bookkeeping
resulting from the automatic backing store At all higher levels identification of
information takes place in terms of segments, the actual storage pages had lost their identity
This is the next level of abstraction.
Level 2
At level 2 we find Message Interpreter taking care of the allocation of the console keyboard.
Above level 2 it is as if each process had its private conversational console
In fact they all share one physical resource and the sharing is provided via mutual synchronization.
At higher levels the actual console teleprinter loses its identity
This is the next level of abstraction
Levels 3 – 5 Level 3
Contains the Sequential Processes associated with buffering of input streams and unbuffering of output streams.
Manages all I/O between the devices attached to the computer
Level 4 Consists of the independent – user programs.
Level 5 Consists of the System Operator.
Synchronizing Primitives Mutual synchronization of parallel sequential
processes is implemented via "semaphores.“
Semaphores are special purpose integer variables initialized with the value 0 or 1
Parallel processes will access the semaphores via two specific operations P-operation
"P(sem)" decreases the value of the semaphore called "sem“ by 1.
V-operation. "V(sem)" increases the value of the semaphore called
"sem“ by 1
Semaphores Contd. If a semaphore value is nonpositive its absolute value
equals the number of processes booked on its waiting list.
The P-operation represents the potential delay, the complementary V-operation represents the removal of a barrier.
P- and V-operations are "indivisible actions"; If the semaphore value resulting from a V – operation
is negative, its waiting list originally contained more than one process.
It is logically immaterial-which of the waiting processes is then removed from the waiting list.
Semaphores in action
begin semaphore mutex; mutex := 1;parbegin
begin L1 : P (mutex ) ; critical section 1;remainder of cycle 1; go to L1
end;begin L2:
P (mutex); critical section 2;V (mutex);remainder of cycle 2; go to L2
endparend
end
Private Semaphores
Each sequential process has associated with it a number of private semaphores, initialized to 0. Max value equals 1, Min value equals -1.
No other process can ever perform a P-operation on them.
A process reaches a stage where the permission for dynamic progress 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).
If the resource is available, It performs the operation "V (private semaphore) “ The semaphore value then changes from 0 to 1
Else this V-operation is skipped, leaving to other processes, to
perform this V – operation at a suitable moment
A process reaches a stage where as a result of its progress possibly one (or more) blocked processes should now get permission to continue
P (mutex) ;"modification and inspection of state variables includingzero or more V-operations on private semaphoresof other processes";V(mutex).
Proving Harmonious Co-operationHoming Position: The neutral point in which all cyclic
processes are when the system is at rest.
A single task cannot give rise to an infinite number of task generations processes can only generate tasks for processes at
lower levels of the hierarchy so that circularity is excluded
System cannot be at rest if there are still pending tasks
All processes will eventually be in homing position (no deadlock)
Experience
Conception Construction Verification
Conception, Construction
Conception All the concepts are born It took long time. Learnt that the society of mutually
synchronized processes in time behavior can satisfy all the requirements.
Construction Done in rather traditional manner. Change of specifications has been rare.
Verification Starting at level 0 the system was tested, each time
adding (a portion of) the next level only after the previous level had been thoroughly tested. Force the system into all different relevant states Verify that the system continued to react according
to specification
Hierarchical structure made testing easy Else the number of "relevant states" would have
exploded to such a height that exhaustive testing would have been an illusion
The hardware failures couldn’t effect testing due to the hierarchical structure
Not Intended
Supports multi tasking but not multi access system
No common data base via which independent users can communicate
Does not cater for user programs written in machine language
Mistakes Made
Paying too much attention to eliminating what was not the real bottle neck.
Trying for “Perfect Installation”
Late Debugging.
Concerns Production speed severely slows down
working with half – time people.
People lose time and energy in switching over and the group loses decision speed.
Similar to context switching in OS
This type of work is very difficult, and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expense.
This strongly supports the argument that we need wizards for multi programming
Conclusion The “THE” system apparently introduced the first forms
of software-based memory segmentation freeing programmers from being forced to use actual physical locations on the drum memory
The design of the “THE” multiprogramming system is significant for its use of a layered structure, in which "higher" layers only depend on "lower' layers
Hierarchical structure of the system in which layers of abstraction are used to virtualize resources.
A refined multiprogramming system whose logical soundness can be proved a priori and that its implementation admits exhaustive testing.
Why read this paper? No abstraction available, writing machine code, by hand, in order
to deal with all the possible combinations of CPU/Peripheral device states
Low-level, interrupt driven, concurrent OS code which is hard to write even with tool and language support and decades of experience.
Building and testing abstractions and then using them as building blocks to construct an entire OS was critical,
Virtualizing the CPU and memory and I/O devices etc, and developing a blocking synchronization construct (semaphores) was a brilliant way of gaining control over this enormous level of complexity.
Concept of Combining the layered hierarchical approach and the use of processes with homing states based on the semaphores, had a major impact on testing and verification
Also, Many of the concepts presented here we take for granted today.
Questions?