The Structure of “THE” – Multiprogramming System

Slides:



Advertisements
Similar presentations
I/O Management and Disk Scheduling
Advertisements

Part IV: Memory Management
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
The Structure of the “THE”- Multiprogramming System
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
The Structure of “THE” – Multiprogramming System by Edsger W. Dijksta Technological University, Eindhoven, Netherlands. Presented by Navya Jammula.
Computer Science 162 Discussion Section Week 2. Agenda Recap “What is an OS?” and Why? Process vs. Thread “THE” System.
1 Computer System Overview OS-1 Course AA
Computer System Overview
Chapter 11 Operating Systems
CS533 - Concepts of Operating Systems
Device Management.
Computer Organization and Architecture
The Structure of the “THE” -Multiprogramming System Edsger W. Dijkstra Jimmy Pierce.
Layers and Views of a Computer System Operating System Services Program creation Program execution Access to I/O devices Controlled access to files System.
Chapter 3 Memory Management: Virtual Memory
1 Computer System Overview Chapter 1. 2 n An Operating System makes the computing power available to users by controlling the hardware n Let us review.
Computer System Overview Chapter 1. Operating System Exploits the hardware resources of one or more processors Provides a set of services to system users.
Chapter 5 Operating System Support. Outline Operating system - Objective and function - types of OS Scheduling - Long term scheduling - Medium term scheduling.
The Structure of the “THE”-Multiprogramming System
Computers Operating System Essentials. Operating Systems PROGRAM HARDWARE OPERATING SYSTEM.
Ihr Logo Operating Systems Internals & Design Principles Fifth Edition William Stallings Chapter 2 (Part II) Operating System Overview.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
The Structure of the “THE”- Multiprogramming System Edsger W. Dijkstra Presented by: Jin Li.
Lecture 1: Review of Computer Organization
CS533 Concepts of Operating Systems Jonathan Walpole.
Concepts and Structures. Main difficulties with OS design synchronization ensure a program waiting for an I/O device receives the signal mutual exclusion.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Operating Systems Overview: Using Hardware.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
The Structure of the "THE"- Multiprogramming Edsger W. Dijkstra Technological University, Eindhoven, The Netherlands System Andrew Edwards.
Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Silberschatz, Galvin and Gagne ©2007 Chapter 0: Historical Overview.
Introduction to Operating Systems Concepts
Module 3: Operating-System Structures
Computer Organization
Processes and threads.
Chapter 2 Memory and process management
Chapter 8: Main Memory.
Review of The Structure of the “THE”-Multiprogramming System
Operating Systems : Overview
The Nucleus of a Multiprogramming System
Advanced OS Concepts (For OCR)
Andy Wang COP 5611 Advanced Operating Systems
Chapter 9 – Real Memory Organization and Management
William Stallings Computer Organization and Architecture
חוברת שקפים להרצאות של ד"ר יאיר ויסמן מבוססת על אתר האינטרנט:
Concurrency: Mutual Exclusion and Synchronization
Lecture 2: Processes Part 1
Recap OS manages and arbitrates resources
Operating Systems.
Operating Systems : Overview
Operating Systems.
Outline Module 1 and 2 dealt with processes, scheduling and synchronization Next two modules will deal with memory and storage Processes require data to.
BIC 10503: COMPUTER ARCHITECTURE
Operating Systems : Overview
Operating Systems : Overview
Operating Systems : Overview
Chapter 2: Operating-System Structures
Concurrency: Mutual Exclusion and Process Synchronization
The Structure of the “The” –Multiprogramming System
Operating Systems : Overview
Operating Systems : Overview
Operating Systems : Overview
Operating Systems : Overview
Operating Systems : Overview
CSE 153 Design of Operating Systems Winter 19
Chapter 6: Synchronization Tools
CSE 542: Operating Systems
Chapter 2: Operating-System Structures
Presentation transcript:

The Structure of “THE” – Multiprogramming System by Edsger W. Dijksta Technological University, Eindhoven, Netherlands. Slideset (mostly) 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 Key Contribution Areas 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

Key Contribution Areas Storage Allocation Processor Allocation System Hierarchy

Storage Allocation strict distinction between memory units and corresponding information units Pages Core Pages (page frames) Drum Pages (disk blocks) Segments A segment fits in a page (virtual pages)

Storage Allocation Contd. Number of possible segment identifiers is much larger than the total number of pages in primary and secondary store. Virtual space >> physical space The segment identifier (page #) gives fast access to a so-called “segment variable” in core whose value denotes 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 In other words … virtual memory!

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 In other words – virtualization of the CPU!

Society of Sequential Processes The following are 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.

Cooperation Among Processes Processes co-operate with each other using explicit mutual synchronization statements Semaphores! Two Uses for Semaphores Mutual Exclusion Semaphores Private Semaphores (Condition Synchronization)

System Hierarchy “THE” has 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 layers below it

Level 0 – CPU Virtualization 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 Processor virtualization is the first level of abstraction

Level 1 – Memory Virtualization The segment controller is present at this level It is responsible for the bookkeeping for an automatic backing store At all higher levels identification of information takes place in terms of segments, the actual storage pages have lost their identity Memory virtualization is the second level of abstraction

Level 2 – Console Virtualization At level 2 we find the 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 all processes share one physical resource and the sharing is enabled via mutual synchronization At higher levels the actual console teleprinter loses its identity Console virtualization is the third level of abstraction

Levels 3 – 5 Level 3 – I/O Virtualization Level 4 – Application Level 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 – Application Level Consists of the independent – user programs Level 5 – The actual user! 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“ Presumably implemented via interrupt disabling? 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 For 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

Semaphores for Condition Synchronization 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

Semaphores for Condition Synchronization 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

Semaphores for Condition Synchronization 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 including zero or more V-operations on private semaphores of other processes"; V(mutex).

Proving Harmonious Co-operation Homing 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 All the concepts are born It took a 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 affect testing due to the hierarchical structure

Software Engineering Observations Production speed severely slows down when working with part–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

Mistakes Made Paying too much attention to eliminating what was not the real bottle neck Trying for “Perfect Installation” Late Debugging

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 whose implementation admits exhaustive testing