This document summarizes a seminar on the origins of operating systems. It discusses the development of the Multics operating system, which was developed starting in 1965 through a collaboration between MIT, Bell Labs, and General Electric. Multics was an influential early time-sharing and mainframe operating system that introduced innovations like hierarchical file systems, dynamic linking and loading, and ring-based protection domains. It also describes some of Multics' design goals and technical features, such as its modular development process, use of the PL/1 programming language, segmentation and paging of memory, and priority-based and percentage-based scheduling algorithms.
Luciano Resende - Scaling Big Data Interactive Workloads across Kubernetes Cl...
Origins of the Multics Operating System
1. 16.01.2013
Seminar: Origins of Operating Systems
Department of Operating Systems and Middleware
(Prof. Dr. Andreas Polze)
Hasso-Plattner-Institut Potsdam http://www.multicians.org/mulimg/multics-frisbee.jpg
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.jpg
Lukas Pirl Multics Seminar: Origins of Operating Systems 3
4. How it all began…
◾ Design started 1965
◾ Successor of CTSS (1961 - 1973)
◾ Project leader: F. J. Corbató
◾ Part of ProjectMAC at MIT
Lukas Pirl Multics Seminar: Origins of Operating Systems 4
5. Cooperation
◾ MIT
◾ Prior pioneering work
◾ Bell Labs
◾ Engineering
◾ Business management
◾ Communications
◾ experienced users
◾ General Electric
◾ Hardware
Lukas Pirl Multics Seminar: Origins of Operating Systems 5
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 users
Lukas Pirl Multics Seminar: Origins of Operating Systems 6
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 programs
Lukas Pirl Multics Seminar: Origins of Operating Systems 7
8. Development on CTSS on IBM 7094
(probably smaller)
http://www.columbia.edu/cu/computinghistory/7094-ibm.jpg
Lukas Pirl Multics Seminar: Origins of Operating Systems 8
9. Development Run
Development on (heavily loaded) CTSS
}
edit code
compile
create boot tape
1 day!
boot
read crash dump
no yes
crash
Lukas Pirl Multics Seminar: Origins of Operating Systems 9
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. Phases
◾ Subdivide work
◾ Each phase defined
◾ Quality targets
◾ Functional benchmarks
◾ No performance goals
◾ A lot of research effort
Lukas Pirl Multics Seminar: Origins of Operating Systems 12
12. March 1967 – Phase 0.5
Working file system
On GE-645 simulator
Lukas Pirl Multics Seminar: Origins of Operating Systems 13
13. December 1967 – Phase 1
bootload
Warm bootable
Create process
Do terminal I/O
Lukas Pirl Multics Seminar: Origins of Operating Systems 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.jpg
Lukas Pirl Multics Seminar: Origins of Operating Systems 16
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. 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 = Segment
Lukas Pirl Multics Seminar: Origins of Operating Systems 20
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: x
Lukas Pirl Multics Seminar: Origins of Operating Systems 21
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. Hardware Layout
CPU CPU
memory memory memory memory
GIOC controller GIOC
drum
system system
controller
console console
terminal
terminal
terminal
terminal
terminal reader terminal
terminal
terminal
terminal
terminal
reader disks
punch punch
controller
tapes
Lukas Pirl Multics Seminar: Origins of Operating Systems 23
22. Old-fashioned Buffering
load to buffer
Process R/W memory disk
write back
Lukas Pirl Multics Seminar: Origins of Operating Systems
}
manually!
24
23. Buffering in Multics
disk
0
1
2
3
R/ W 4
memory 5
Process 12 6
7 7
1 8
9
}
10
11
automatic
12
13
Lukas Pirl Multics Seminar: Origins of Operating Systems buffering 25
24. Memory Hierarchy
◾ Singe-level Storage
◾ Multiple layers but flat view
like all files mmap'ed
◾ On access, data automatically loaded into memory
◾ No loss of identity
◾ Operation on 'original data'
◾ No manual loading/saving of files
Lukas Pirl Multics Seminar: Origins of Operating Systems 26
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**18
Lukas Pirl Multics Seminar: Origins of Operating Systems 27
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 segment
Lukas Pirl Multics Seminar: Origins of Operating Systems 28
27. Segments in Memory
Memory 2 5
10
+
?
9
◾ Fragmentation during runtime
Lukas Pirl Multics Seminar: Origins of Operating Systems 29
28. Paging
10
Memory 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 required
Lukas Pirl Multics Seminar: Origins of Operating Systems 30
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 DS
sp
sw
P L
P L ACL fault PT of Segment “s”
ip
P L
fault
Lukas Pirl Multics Seminar: Origins of Operating Systems 31
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 procedures
Lukas Pirl Multics Seminar: Origins of Operating Systems 32
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 needed
Lukas Pirl Multics Seminar: Origins of Operating Systems 33
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 communication
Lukas Pirl Multics Seminar: Origins of Operating Systems 34
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
◾ configurable
Lukas Pirl Multics Seminar: Origins of Operating Systems 35
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 process
Lukas Pirl Multics Seminar: Origins of Operating Systems 36
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 reasons
Lukas Pirl Multics Seminar: Origins of Operating Systems 37
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 possible
Lukas Pirl Multics Seminar: Origins of Operating Systems 38
37. st
1 Scheduler – Priority Queuing
Queue priority 0
Dispatcher
new
Queue priority 1
Queue priority 2 CPU
Queue blocked
Lukas Pirl Multics Seminar: Origins of Operating Systems
done 39
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 groups
Lukas Pirl Multics Seminar: Origins of Operating Systems 40
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. 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 Windows
Lukas Pirl Multics Seminar: Origins of Operating Systems 42
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 deadline
Lukas Pirl Multics Seminar: Origins of Operating Systems 43
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. Hardware Failures
◾ Essential for dependability
◾ On-line reconfiguration
◾ Core memory !
NEW
◾ Unwritten data will be lost
◾ Attached I/O devices
◾ CPU's
◾
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. Accounting
◾ Pay-per-use
◾ CPU time in milliseconds
◾ Number of pages in Memory
◾ every millisecond
◾ Number of pages on disk
◾ every millisecond
◾ Quotas
◾ Dollar-limits
Lukas Pirl Multics Seminar: Origins of Operating Systems 47
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
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 under
Lukas Pirl Multics Seminar: Origins of Operating Systems 51