MULTICS

1,323 views

Published on

Overview and selected implementation details of the MULTICS operating system.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,323
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

MULTICS

  1. 1. 16.01.2013Seminar: Origins of Operating SystemsDepartment of Operating Systems and Middleware(Prof. Dr. Andreas Polze)Hasso-Plattner-Institut Potsdam http://www.multicians.org/mulimg/multics-frisbee.jpg
  2. 2. http://www.dcl.hpi.uni-potsdam.de/teaching/origins/os-evolution.jpgLukas Pirl Multics Seminar: Origins of Operating Systems 2
  3. 3. Fernando José Corbató http://graphics8.nytimes.com/images/2011/06/20/opinion/morris_email_corbato2/morris_email_corbato2-blog427.jpg http://upload.wikimedia.org/wikipedia/commons/3/3d/Fernando_Corbato.jpgLukas Pirl Multics Seminar: Origins of Operating Systems 3
  4. 4. How it all began… ◾ Design started 1965 ◾ Successor of CTSS (1961 - 1973) ◾ Project leader: F. J. Corbató ◾ Part of ProjectMAC at MITLukas Pirl Multics Seminar: Origins of Operating Systems 4
  5. 5. Cooperation ◾ MIT ◾ Prior pioneering work ◾ Bell Labs ◾ Engineering ◾ Business management ◾ Communications ◾ experienced users ◾ General Electric ◾ HardwareLukas Pirl Multics Seminar: Origins of Operating Systems 5
  6. 6. Goals (1) ◾ Reliability ◾ Increases acceptance and convenience ◾ Continuity ◾ maintain hardware during runtime (redundancy) ◾ Timesharing ◾ Simulate private computer for many users ◾ long I/O waits ◾ Selective information sharing ◾ Increase effectiveness with shared facilities between usersLukas Pirl Multics Seminar: Origins of Operating Systems 6
  7. 7. Goals (2) ◾ Security ◾ Configurable access for data and programs ◾ Changeable system configuration ◾ Wide variety of system capacities ◾ Convenient use (also remote) “[…] the system should be sympathetic to its users. Multics provides no direct assistance toward this goal […]” [SMS] ◾ Openness “open-shop computer facility” ◾ Most system modules implemented like user programsLukas Pirl Multics Seminar: Origins of Operating Systems 7
  8. 8. Development on CTSS on IBM 7094 (probably smaller) http://www.columbia.edu/cu/computinghistory/7094-ibm.jpgLukas Pirl Multics Seminar: Origins of Operating Systems 8
  9. 9. Development Run Development on (heavily loaded) CTSS } edit code compile create boot tape 1 day! boot read crash dump no yes crashLukas Pirl Multics Seminar: Origins of Operating Systems 9
  10. 10. Written in PL/1 ◾ high level language ◾ Comprehensible ◾ Machine-Independent ◾ Hardware might change ◾ Adoptable ◾ Requirements might change ◾ “enthusiasm of those planning to implement the compiler” [MVMSD]Lukas Pirl Multics Seminar: Origins of Operating Systems 10
  11. 11. Phases ◾ Subdivide work ◾ Each phase defined ◾ Quality targets ◾ Functional benchmarks ◾ No performance goals ◾ A lot of research effortLukas Pirl Multics Seminar: Origins of Operating Systems 12
  12. 12. March 1967 – Phase 0.5 Working file system On GE-645 simulatorLukas Pirl Multics Seminar: Origins of Operating Systems 13
  13. 13. December 1967 – Phase 1 bootload Warm bootable Create process Do terminal I/OLukas Pirl Multics Seminar: Origins of Operating Systems 14
  14. 14. General Electric 645 set-up 1967 @ MIT CPU@435KIPS 2x512k core memory 18 MB drum storage http://www.multicians.org/mulimg/martin-widrig-645.jpgLukas Pirl Multics Seminar: Origins of Operating Systems 16
  15. 15. http://www.multicians.org/mulimg/betti-blank.jpg set-up 1972 @ MITLukas Pirl Multics Seminar: Origins of Operating Systems 17
  16. 16. *http://www.multicians.org/mulimg/h6180-doors-open-big.jpg $7 MLukas Pirl Multics Seminar: Origins of Operating Systems http://www.multicians.org/mulimg/you-would-b2-2.jpg * ≈29 Mio. € (2012) 18
  17. 17. Honeywell 6180 Configuration ◾ 2x CPU ◾ 1 MIPS each ◾ 384k MOS memory ◾ 36-bit words ◾ 1MW drum storage ◾ 4,5 MB ◾ 15 150MB disks ◾ 2,25 GB ◾ 8 tape drives ◾ ARPANet connection ◾ Card reader & punch, printer, …Lukas Pirl Multics Seminar: Origins of Operating Systems 19
  18. 18. File System File Branch - bits/bytes/… Directory 1 n Entry 1 - phy. address - name n - access control {XOR} - time created 1 1 - time modified 1 - time referenced ◄ references - state (#r, w, …) 1 ◾ Hierarchical namespace ◾ Addressing by symbolical names NEW ! ◾ Symbolic links ◾ Working directory per process ◾ In Multics: File = SegmentLukas Pirl Multics Seminar: Origins of Operating Systems 20
  19. 19. Access Control Lists ◾ ACL for every file ◾ prepend only ◾ Garbage collector ◾ Evaluated LIFO ◾ TRAP, READ, EXECUTE, WRITE, APPEND Garry (member of ProjectMAC) can read and execute but not write xyz. Alice (member of ProjectMAC) can read and write but not execute xyz. File xyz ACL Garry: rx ProjMac: rw Alice: xLukas Pirl Multics Seminar: Origins of Operating Systems 21
  20. 20. “[…] speed of light, the physical sizes […] and the speed of memories are intrinsic limitations of any single processor, […] multiple processors and multiple memory units are needed to provide greater capacity.” [IOMS]Lukas Pirl Multics Seminar: Origins of Operating Systems 22
  21. 21. Hardware Layout CPU CPU memory memory memory memory GIOC controller GIOC drum system system controller console consoleterminalterminal terminal terminal terminal reader terminal terminal terminal terminal terminal reader disks punch punch controller tapesLukas Pirl Multics Seminar: Origins of Operating Systems 23
  22. 22. Old-fashioned Buffering load to bufferProcess R/W memory disk write backLukas Pirl Multics Seminar: Origins of Operating Systems } manually! 24
  23. 23. Buffering in Multics disk 0 1 2 3 R/ W 4 memory 5Process 12 6 7 7 1 8 9 } 10 11 automatic 12 13Lukas Pirl Multics Seminar: Origins of Operating Systems buffering 25
  24. 24. Memory Hierarchy ◾ Singe-level Storage ◾ Multiple layers but flat view like all files mmaped ◾ On access, data automatically loaded into memory ◾ No loss of identity ◾ Operation on original data ◾ No manual loading/saving of filesLukas Pirl Multics Seminar: Origins of Operating Systems 26
  25. 25. Segments ◾ Symbolic name (i.e. not address in memory) ◾ Attributes ◾ Addressing: (name, i) like a lot of small core memories Name Name Name <unused> Attributes Attributes Attributes i < 2**18Lukas Pirl Multics Seminar: Origins of Operating Systems 27
  26. 26. Why Segments Programs and Data (=everything) stored in segments NEW ◾ Unified, symbolic addressing ◾ Space-efficiency ◾ Re-use segments in memory ◾ I/O efficiency ◾ Read only required parts of file ◾ Fine-grained access control ◾ Per segmentLukas Pirl Multics Seminar: Origins of Operating Systems 28
  27. 27. Segments in MemoryMemory 2 5 10 + ? 9 ◾ Fragmentation during runtimeLukas Pirl Multics Seminar: Origins of Operating Systems 29
  28. 28. Paging 10Memory 2 5 9 ◾ Whole core memory divided into pages ◾ 1024 words each ≈ 4,6kB each ◾ Split segments onto pages ◾ Space efficiency ◾ Keep only active pages in memory ◾ No defragmentation requiredLukas Pirl Multics Seminar: Origins of Operating Systems 30
  29. 29. Page Lookup DBR = descriptor base register DS = descriptor segment PT = page table L = length P = pointer DBR Page “ip” of P L Segment “s” iw PT of DS Word[s,i] Page “sp”of DSsp sw P L P L ACL fault PT of Segment “s” ip P L faultLukas Pirl Multics Seminar: Origins of Operating Systems 31
  30. 30. Address spaces NE ◾ Address space per process W ◾ Already accessed addresses ◾ Set of (segment number, word number) tuples ◾ Supervisor has no dedicated memory area ◾ Protected through access control ◾ Can be paged ◾ Easy sharing of supervisory proceduresLukas Pirl Multics Seminar: Origins of Operating Systems 32
  31. 31. Supervisory Data per Process ◾ Stack segment ◾ Data of process ◾ Concealed stack segment ◾ Various Supervisory data (charging information, …) ◾ descriptor segment ◾ Maps segment addresses to core memory addresses ◾ Known Segment Table ◾ Maps symbolic segment names to segment numbers ◾ Further segments dynamically, as neededLukas Pirl Multics Seminar: Origins of Operating Systems 33
  32. 32. Dynamic Linking NE W ◾ Compiler retains symbolic names ◾ Segment lookup and linking on first access ◾ Get most recent shared procedure / data ◾ For long execution times: explicit unlinking possible ◾ Access to data of other segments via (linked) code in other segments ◾ Inter-process communicationLukas Pirl Multics Seminar: Origins of Operating Systems 34
  33. 33. Sharing through Linking no access Data Data Segment Segment Purchases Items Procedure Procedure Segment as Segment Trade Warehouse access in execution as daemon linking call ship Data Data Segment Segment Sales Shipments ◾ Access to segments of linked segments ◾ configurableLukas Pirl Multics Seminar: Origins of Operating Systems 35
  34. 34. Process Life Cycle ◾ Creation ◾ Spawned from other process ◾ With segments to copy, segments to hide, start pointer ◾ States ◾ Running ◾ Blocked ◾ Maximum blocked time ◾ Access violation, I/O wait, wait for lock, wait for 21.12.2012, … ◾ Ready ◾ Termination ◾ Done XOR gets killed by other processLukas Pirl Multics Seminar: Origins of Operating Systems 36
  35. 35. Load ◾ Hard to predict load in multiprogrammed system ◾ Load rarely matches system capacity ◾ Perform well under light overload ◾ Switching processes often when load is light ◾ Provide responsive system when possible ◾ Frequency of switches indirect proportional to load ◾ Access occasional overload ◾ For economical reasonsLukas Pirl Multics Seminar: Origins of Operating Systems 37
  36. 36. Scheduling - Aims ◾ Symmetry in CPU responsibilities ◾ Good service to all customers ◾ Good service at reasonable cost ◾ Differentiate between urgencies ◾ Delays of results differ in resulting costs ◾ Human-determined ◾ As efficient as possibleLukas Pirl Multics Seminar: Origins of Operating Systems 38
  37. 37. st 1 Scheduler – Priority Queuing Queue priority 0 Dispatchernew Queue priority 1 Queue priority 2 CPU Queue blockedLukas Pirl Multics Seminar: Origins of Operating Systems done 39
  38. 38. st 1 Scheduler – Priority Queuing ◾ Descended from scheduler in CTSS ◾ N queues reflecting different priorities ◾ Exponential quantum length ◾ Highest priority (0), shortest quantum x ◾ Lowest priority (n), longest quantum x*2**n ◾ Rules for lowering and raising priorities ◾ Run first job from non-empty queue with highest priority ◾ Lower priority when job misses quantum end ◾ (Move all jobs to highest priority queue periodically) ◾ Enhancement: Grant %age of CPU time to groups ◾ Priority queuing within groupsLukas Pirl Multics Seminar: Origins of Operating Systems 40
  39. 39. Percentage Scheduler - Challenges ◾ Unused CPU time ◾ ? idle OR sum for later use OR split to others ◾ ! add up a little (with maximum), split the rest ◾ Interval in which CPU time will be accounted ◾ ? daily, hourly, secondly, … ◾ ! 4 * length(quantum) ◾ Scheduler should consider (very) near future ◾ Will the job use the whole quantum? ◾ ! Account CPU time as credits per group ◾ Per default, discount credits for whole quantum ◾ Add back credits accordingly (if process finishes earlier)Lukas Pirl Multics Seminar: Origins of Operating Systems 41
  40. 40. Percentage Scheduler – Multilevel Q ◾ Percentage scheduler degrades response time ◾ Process that caused interaction consumed CPU time ◾ Queuing Theory ◾ Introduced interactive queue ◾ For processes that recently interacted ◾ FIFO ◾ Good response time for simple commands ◾ cp. boost of priority after I/O in WindowsLukas Pirl Multics Seminar: Origins of Operating Systems 42
  41. 41. Deadline Scheduling NE W ◾ Assign deadlines to groups ◾ Virtual deadlines ◾ Used to sort processes of all groups in one queue – No attempt to meet deadline ◾ Different deadlines and quanta length after interaction – Retain good average response time ◾ Realtime deadlines ◾ Used to sort process into a realtime queue ◾ Deadline for start of work ◾ Execution on deadline ◾ Other scheduling similar to a process with virtual deadlineLukas Pirl Multics Seminar: Origins of Operating Systems 43
  42. 42. Traps ◾ System Traps ◾ Failures, I/O termination, … ◾ Process Traps ◾ Overflows, access violation, … ◾ Trap handling ◾ Routine per system trap ◾ With intercept points for custom trap handling ◾ Default or custom trap routine for all traps ◾ Custom overflow handling, custom page-fault handling, …Lukas Pirl Multics Seminar: Origins of Operating Systems 44
  43. 43. Hardware Failures ◾ Essential for dependability ◾ On-line reconfiguration ◾ Core memory ! NEW ◾ Unwritten data will be lost ◾ Attached I/O devices ◾ CPUs ◾ Affected process will be damaged ◾ Unsolved: misbehaving hardware ◾ “We have no very useful techniques for protecting the system from software bugs” [M]Lukas Pirl Multics Seminar: Origins of Operating Systems 45
  44. 44. Accounting ◾ Pay-per-use ◾ CPU time in milliseconds ◾ Number of pages in Memory ◾ every millisecond ◾ Number of pages on disk ◾ every millisecond ◾ Quotas ◾ Dollar-limitsLukas Pirl Multics Seminar: Origins of Operating Systems 47
  45. 45. Security http://www.multicians.org/mulimg/slider-you-would-b2.jpg ◾ Access Control ◾ Single concept for whole addressable memory NE ◾ Ring layout W! ◾ Access relative to ring of execution ◾ 8 rings in hardware, 64 simulated in software ◾ Supervisor in ring 0 ◾ Now, standard architecture on Intel and of Microsoft ◾ “No back door was ever discovered in any 6180 Multics” [M]Lukas Pirl Multics Seminar: Origins of Operating Systems 48
  46. 46. http://www.multicians.org/mulimg/outgrow-sm.jpgLukas Pirl Multics Seminar: Origins of Operating Systems 50
  47. 47. *s ◾ [IOMS]: F. J. Corbato, and V. A. Vyssotsky, "Introduction and Overview of the Multics System", Fall Joint Computer Conference, 1965 ◾ [SMS]: V. A. Vyssotsky, F. J. Corbato, and R. M. Graham, "Structure of the Multics Supervisor", Fall Joint Computer Conference, 1965 ◾ [MVMSD]: F. J. Corbató, and C. T. Clingen, “A Managerial View of the Multics System Development”, M.I.T. Press, 1979 ◾ R. C. Daley, and P. G. Neumann, "A general-purpose file system for secondary storage", Fall Joint Computer Conference, 1965 ◾ J. F. Ossanna, L. Mikus, and S. D. Dunten, "Communications and input- output switching in a multiplexed computing system", Fall Joint Computer Conference, 1965 ◾ [M] http://www.multicians.org/, accessed 15 January 2013 ◾ All slides underLukas Pirl Multics Seminar: Origins of Operating Systems 51

×