About the author Edsger Wybe Dijkstra (1930-2002) A pioneer in the - PowerPoint PPT Presentation

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 

About the author Edsger 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 Hierarchy L5: Operator

Level 0: 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 1: Segment Controller 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 2: Message Interpreter  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 3: Buffering I/O  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 5: Operator Level 4: User Program  Level 4 : The independent user programs  Level 5: the operator (not implemented by the author’s team).

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; 
 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 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 Unstable Situation

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