Upload
pembroke
View
74
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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: Amin Almassian CS510 - Concepts of Operating Systems, Fall 2013 Portland State University. - PowerPoint PPT Presentation
Citation preview
S
The Structure of the “THE”-Multiprogramming System
Edsger W. DijkstraTechnological University, Eindhoven, The Netherlands
Communications of the ACM, 11(5):341--346, 1968Presented by: Amin AlmassianCS510 - Concepts of Operating Systems, Fall 2013Portland State University
About the authorEdsger Wybe Dijkstra (1930-2002)
A pioneer in the area of distributed computing. His foundational work:
Concurrency primitives (such as the semaphore), Concurrency problems (such as mutual exclusion and deadlock), Reasoning about concurrent systems, and self-stabilization
Winner of ACM's A.M. Turing Award in 1972 The Edsger W. Dijkstra Prize in Distributed Computing is named for him Graphs “shortest path” algorithm: shortest route between two cities
in the Netherlands. “Without pencil and paper you are almost forced to avoid all avoidable complexities.”
“In 1955 when I decided not to become a physicist, to become a programmer instead. At the time programming didn't look like doing science, it was just a mixture of being ingenious and being accurate.” [1]
Multiprogramming System Objectives
Not intended as a multi-access system To process smoothly a continuous flow of user programs Making economic use of peripheral devices Reduction of turn-around time for programs of short duration Automatic control of backing store to be combined with
economic use of the central processor Feasibility to use the machine for multiple apps economically
Hardware Configuration EL X8
Core memory: 2.5µsec, 27 bits; 32K Storage: drum of 512K words, 1024 words per track, 40 msec An indirect addressing mechanism well suited for stack
implementation A sound system for commanding peripherals and controlling
of interrupts low capacity channels
3 paper tape readers at 1000char/see; 3 paper tape punches at 150char/sec; 2 teleprinters (a plotter, a line printer)
Storage Allocation
Memory units (pages): core pages and drum pages Information units: segments (a segment fits in a page) Segment variable: Segment variable value tells if the segment is empty
or not Segment identifier gives fast access to a segment variable If the segment is not empty, the value denotes which page(s) the segment can
be found
Consequences: A core page can be dumped onto a free drum page (the one with the minimum
latency time) to free up the core page Drum page occupation does not have to be consecutive.
Process Allocation
A society of sequential processes (the concept of process abstraction) logical meaning for a process:
The time succession of various states, Not the actual speed of execution
Mutual synchronization Allows for cooperation between sequential processes Processor switches from process to process, Temporal delaying the progress of the processes (blocking)
System HierarchyL5: Operator
L4: User Program
L3: Buffering I/O
L2: Message Interpreter
L1: Segment Controller
L0: Process Allocation
Is in charge of allocation of the processor for processes
Takes advantage of real-time clock interrupts to regain the control of the processor
Provides an abstraction: The number of processors actually shared is no longer relevant. The actual processor that had lost its identity having
disappeared from the picture. Priority rule included
Level 0: Process Allocation
Is in charge of memory storage and allocation
Consists of a sequential process synchronized with the drum interrupt and sequential processes of higher levels
Provides a level of abstraction: Higher levels identify information in terms of segments the actual storage pages that had lost their identity having
disappeared from the picture. At higher levels, the actual storage pages have lost their identity
Level 1: Segment Controller
A mediator between the operator and any of the higher level processes
When a key is pressed, the character along with an interrupt is sent to the system
Sends output commands to printer
Provides an abstraction level: Processes share the same physical console Above this level, each process thinks it has its own private console
(the advantage of using mutual synchronization)
Level 2: Message Interpreter
Is in charge of buffering of input streams and Un-buffering of output streams by using sequential processes
The sequential processes associated with the peripherals are of a level above the message interpreter, because they must be able to converse with the operator (e.g. in the case of detected malfunctioning).
Provides an Abstract level: Abstracts the actual peripherals as “logical communication
units” to higher levels
Level 3: Buffering I/O
Level 4 : The independent user programs Level 5: the operator (not implemented by the
author’s team).
Level 4: User Program
Level 5: Operator
Synchronizing Primitives
Semaphores Initialized with the value of 0 or 1 P-operation decreases value of a semaphore by 1
If sem ≥ 0 process can continue If sem< 0 process is stopped and is put on waiting list
V-operation increases value of a semaphore by 1 If sem >0 no effect If sem ≤ 0 a process on the waiting list is removed and continues
progressing once allocated to a processor If there is more than one process on the waiting list it is undefined which process
is removed
Semaphore [2]
Mutual Exclusion
begin semaphore mutex; mutex := 1;parbeginbegin L1: P(mutex); critical section 1; V(mutex);remainder of cycle 1; go to L1end;begin L2: P(mutex); critical section 2; V(mutex);remainder of cycle 2; go to L2endparend
End
Mutex: {-(n-1), …,-1, 0, 1} Allows for straightforward extension to more than two parallel processes
Private Semaphors
Analogous to condition synchronization mechanisms
Each sequential process has associated with a number of private semaphores (range between -1 and 1)
Private Semaphors
Whenever a process reaches a stage where the permission for dynamic progress depends on current values of state variables, it follows the pattern:
P(mutex) ;
"inspection and modification of state variables including a conditional V(private semaphore)";
//if wants to continue // V(private-semaphore)
//If (private semaphore > 0)V (mutex);
P(private semaphore)
Private Semaphors
Whenever a process reaches a stage where as a result of its progress possibly one (or more) blocked processes should now get permission to continue, it follows the pattern:
P (mutex) ;
"modification and inspection of state variables including zero or more V-operations on private semaphores of other processes";
V(mutex).
Proving the Harmonious Cooperation
Homing position
Accepted a task
Perform the task
Blocked
A Free resource needed
Perform the task
Unstable Situation
Homing position
Accepted a task
Perform the taskBlocked
Perform the task
Proving the Harmonious Cooperation
1. a process generate a finite number of tasks for other processes. processes can only generate tasks for processes at lower levels of
the hierarchy so that circularity is excluded. 2. It is impossible that all processes have returned to their
homing position while there is still pending tasks. (This is proved via instability of the situation)
3. After the acceptance of an initial task all processes eventually will be (again) in their homing position. (proof by induction on the level of hierarchy, starting at the lowest level)
Summary and Conclusion
Old concepts yet state-of-the-art (1968-2013) Segments == Segments Core page and drum pages == Paged virtual memory abstraction Sequential Process abstraction == Process/Thread Semaphores == Semaphores hierarchical implementation == hierarchical implementation
Hierarchical structure has been a great advantage to verification and testing Abstraction at each layer Proof of logical soundness at each level of abstraction Small components results in small test cases => Easier to test
Refrences
[1] Thomas J. Misa and Philip L. Frana. 2010. An interview with Edsger W. Dijkstra. Commun. ACM 53, 8 (August 2010), 41-47. DOI=10.1145/1787234.1787249 http://doi.acm.org/10.1145/1787234.1787249
[2] Animations for Operating Systems, Sixth Edition by William Stallings, available at http://williamstallings.com/OS/Animation/Animations.html