The Structure of the “THE”- Multiprogramming System Edsger W. Dijkstra Presented by: Jin Li
Migration of Operating Systems Simple Batch Systems (mid 1950s – mid 1960s) Spooling Batch Systems (mid 1960s – mid 1970s) Multiprogramming Systems (1960s – ) Timesharing Systems (1970s – ) Personal Computers Multiprocessor and Distributed Systems
The Hardware EL X8 32K core memory, cycle time 2.5 usec; 512K drum, rev. time 40 msec; Indirect addressing Commanding peripherals and controlling interrupts Low capacity channels for paper tape readers, paper tape punches, teleprinters, and etc.
The Goal A multiprogramming system to “process smoothly a continuous flow of user programs” Specific objectives Short turn-around time for short programs Economic use of peripheral devices Automatic control of backing store and economic use of the central processor Sharing the machine among multiple applications
The “THE”-Multiprogramming System A hierarchical system for multiprogramming Each level implements an independent abstraction A collection of sequential processes Automatic storage management Core pages and drum pages Segments: abstract memory units Segment controller maps segments into core pages, and manages paging between core pages and drum pages Multiplexing processor Semaphores Timer interrupt Priority rule
Storage Allocation Physical storage: Core pages and drum pages Information unit: segments A segment just fits in a page The number of possible segment ids >> the number of core pages + drum pages Segment variable the physical location of the segment Separation of logical information from its physical location A program can reside in several non-consecutive drum pages A core page can be written to any free drum page (choose the one with lowest latency) The primitive form of VM
Processor Allocation Multiplexes the processor Important observation: the logical meaning of a process depends on time succession of its states, not its execution speed; Timer interrupt Synchronization: semaphores Priority rule for scheduling ready processes
System Hierarchy A number of sequential processes placed at various hierarchical levels User programs Input peripherals Output peripherals … … Each level implements an independent abstraction Higher levels are built on top of the abstractions provided by the lower levels
System Hierarchy: Level 0 Processor allocation Timer interrupts Priority rule (primitive form of scheduler) Synchronization: using semaphores Observation: The correctness of a process depends on the succession of its internal state, not its execution speed Abstraction: each process owns a processor EL X8 Processor Allocation
System Hierarchy: Level 1 Segment controller Abstraction: Programs refer to segments, independent of their physical address Above level 1, each process has its own processor, and information is identified using segment-id EL X8 Processor Allocation Segment Controller call direction
System Hierarchy: Level 2 Message interpreter Handles interrupt from keyboard Generates printing command to printer Routes console I/O to and from the right processes Multiplexes the console, needs mutual synchronization Why is it on top of the segment controller? Abstraction: each process has its own console Above level 2, each process has its own processor, only sees storage in segments, and has its own console EL X8 Processor Allocation Segment Controller Message Interpreter call direction
System Hierarchy: Level 3 Buffering I/O streams Multiplexes peripherals Each peripheral device is associated with a sequential process, which manages the input/output buffers of the device Each process talks directly to the I/O buffers Abstraction: real peripherals to “logical communication units” Above level 3, each process has its own processor, information is identified by their segments, has its own console, and talks to the logical communication units EL X8 Processor Allocation Segment Controller Message Interpreter Buffering I/O streams call direction
System Hierarchy: Level 4 User programs Each corresponds to a sequential process EL X8 Processor Allocation Segment Controller Message Interpreter Buffering I/O streams User Programs call direction
Semaphores In this paper P(Semaphore s) { s := s-1; if s < 0, then wait;} V(Semaphore s) { s := s+1; if s <= 0, then a waiting process is ready to execute; } The semantics of semaphores P(Semaphore s) { await s > 0, then s := s-1;} V(Semaphore s) { s := s+1;} Private semaphores are similar to condition variables
Experiences System abstraction Conception stage took a long time Prevent bugs instead of debugging Verification stage Add a new level after the previous level has been thoroughly tested How many tests do we need?