Review of “The Structure of the “The”-Multiprogramming System” by Edsger W. Dijkstra

1. Review of “The Structure of the “The”-Multiprogramming System” by Edsger W. Dijkstra Burke Ellett CS 533 CS533 - Concepts of Operating Systems

2. Topics • Background of paper • System design • Testing CS533 - Concepts of Operating Systems

3. Who was Dijkstra • Remember him from algorithms • Dutch professor of Mathematics • Designed and implemented one of the first (or the first?) modern operating systems for a multi-process computer using a layered scheme. (With his viz.) CS533 - Concepts of Operating Systems

4. Goals of project • Provide a system to smoothly process a continuous flow of user programs • Shorten duration of execution of short programs • Economic use of the peripheral devices • Automatic process storage to allow an economic use of the CPU • The ability to run large flexible user programs that can communicate with each other • No built in way for different users to communicate with each other CS533 - Concepts of Operating Systems

5. Goals in the System Design • Major choice of machine was the ability of a real time interrupt system • Prove the logical soundness of the system so that extensive debugging to not need to occur • The drum (or disk) could be accessed only one page a time, so a virtual paging system was created that used segments that were exactly the same length as a drum page. • Noticed that user program does not need to be run to completion all at once to be correct, so the processor could be shared by swapping in and out different program states. CS533 - Concepts of Operating Systems

6. Storage allocation • Virtual memory addresses controlled by OS • Allows programs and data to be stored non-sequential thus reducing latency time • Creating using segments as default data length, where a segment will exactly the length of a physical page • Addresses to segments kept that tell the place in physical memory where the segment is stored and whether it has been used or not (segment variables) CS533 - Concepts of Operating Systems

7. Processor Allocation • Process has no idea or concern of the speed it takes to run to completion, cares only about the time succession of various states • Interrupting a process but not changing its state can allow you to swap processes in and out and each can make progress towards completion • Shorter user processes will finish first if they have the same priority (Guarantees one of the goals of the OS) • System is designed on the idea of abstract sequential processes CS533 - Concepts of Operating Systems

8. Decided on a Layered System Design • Break into logical levels that abstract a little more from the hardware and underlining levels as you go higher • Each layer defines and implements an abstraction for the layer above it (Virtual processor, Virtual memory, etc…) • Layers consist of sequential processes that communicate with shared variables • Similar to protocol layers in networking CS533 - Concepts of Operating Systems

9. Level 0 (Processor allocation) • Multiplexing of CPU among society of sequential processes (CPU scheduling) • Interrupts from the real-time clock ensure no one process can monopolize the CPU • Priority rules allow strict responses where needed CS533 - Concepts of Operating Systems

10. Level 1 (Segment controller) • Allows the OS to control memory storage and allocation • Maps segments into core pages, and does the paging between core and drum pages • Retrieves and saves pages between core and drum • Guarantees a page requested by a process will be in core memory after it restarts, this stops fluttering • This level sees virtual processors CS533 - Concepts of Operating Systems

11. Level 2 (Message interpreter) • Routes console input/output to and from the correct processes (reads from keyboard and writes to consoles) • Mutual synchronization used to share the real console • Controls messages passed from operators to processes CS533 - Concepts of Operating Systems

12. Above Level 2 • Every process thinks it has its own private console • Every process thinks it has its own private CPU and memory • No process cares about actual physical memory since it deals with segments • The fact that they share the same console is hidden by a resource restriction of “Only one conversation at a time.” (Accomplished with a mutex) CS533 - Concepts of Operating Systems

13. Level 3 (Communication units) • Buffering of input streams • Un-buffering of output streams (to I/O devices, peripherals, etc) • Used for communication with operators and above the message interpreter so that hardware errors can be detected • Sees a virtual console CS533 - Concepts of Operating Systems

14. Top • Level 4 (Independent User Programs) • Sees virtual I/O drivers • Level 5 The operator. CS533 - Concepts of Operating Systems

15. Each layer consists of • Think of each layer as an abstract machine with certain properties • Sequential process that implement the layer • Each layer has a process assigned to it • Activities that cross layers require interprocess communication that is handled with shared memory • Use synchronization primitives to manage the shared memory communication CS533 - Concepts of Operating Systems

16. Semaphores are the primitives used • A semaphore is a protected variable whose value can be accessed and altered only by operation P() and V() as well a a global initialization. • Each layer has one or more private semaphores plus a public ones to allow communication between layers • P operation (to pass or to test) busy waits or sleeps on a condition that is associated with a resource • V operation (to make free or to increment) signals condition or makes resource available • Think of P as being a synchronous receive and V as the asynchronous send CS533 - Concepts of Operating Systems

17. Testing • Testing was done at each level and was combined with overall proof of correctness to narrow down test cases • The test cases were used to only find bugs in the code due to syntactical errors made by programmers • Because of the level abstractions testing could continue even after the drum channel hardware broke down • Testing was not finished at the time of this paper • Easier to test because you can prove valid one layer at a time CS533 - Concepts of Operating Systems

18. Creation and use of Mutex and Semaphores • Introduced the concepts of a Mutex and Semaphore to allow cooperative sharing of scarce resources • Used to prove the overall validity of design in the absence of any circular waits • Designed the dining philosopher problem to describe this phenomenon • Is this proof of correctness enough? Could you possibly test all cases in a program the size of an OS? CS533 - Concepts of Operating Systems

19. Questions • Is a layered design the best plan to building an OS? • How does it limit performance? • Does the abstractions created at each level in the layered design make programming easier or harder? • Do user level programmers lose valuable information because of these abstractions? • Is layering flexible enough for creating an OS? CS533 - Concepts of Operating Systems