1 / 15

The Structure of the “THE”-Multiprogramming System

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 – )

ewa
Download Presentation

The Structure of the “THE”-Multiprogramming System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Structure of the “THE”-Multiprogramming System Edsger W. Dijkstra Presented by: Jin Li

  2. 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

  3. 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.

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. System Hierarchy: Level 0 Processor Allocation EL X8 • 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

  10. System Hierarchy: Level 1 call direction Segment Controller • 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 Processor Allocation EL X8

  11. System Hierarchy: Level 2 call direction Message Interpreter • 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 Segment Controller Processor Allocation EL X8

  12. System Hierarchy: Level 3 call direction Buffering I/O streams • 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 Message Interpreter Segment Controller Processor Allocation EL X8

  13. System Hierarchy: Level 4 call direction • User programs • Each corresponds to a sequential process User Programs Buffering I/O streams Message Interpreter Segment Controller Processor Allocation EL X8

  14. Semaphores • The semantics of semaphores • P(Semaphore s) • { await s > 0, then s := s-1;} • V(Semaphore s) • { s := s+1;} • 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; } • Private semaphores are similar to condition variables

  15. 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?

More Related