The UNIX Time-Sharing
System
Mosharaf Chowdhury
1/11/16
EECS 582 – W16
1
Time Sharing
• As opposed to batch processing
• Submit jobs to queues to be processed one at a time
• Non-interactive
• Divide a shared resource between multiple programs and users
to lower the cost of computing
• John McCarthy wrote a memorandum in 1959
• Early examples include
• MIT CTSS (Compatible Time-Sharing System)
• Berkeley Timesharing System
• Dartmouth Time-Sharing System (DTSS)
1/11/16
EECS 582 – W16
2
Multics
• Multiplexed Information and Computing Service
• Started in 1964 at MIT; led by Fernando Corbató w/ GE and Bell Labs
• Time-sharing operating system
• Developed initially for GE-645 mainframe, a 36-bit machine w/ support
for virtual memory
• Hierarchical file system
• Protection ring-based security
• Access Control Lists (ACL)
•…
• Bell Labs pulled out in 1969
1/11/16
EECS 582 – W16
3
UNIX
• Started by Ken Thompson and Dennis Ritchie in 1969
“UNIX was never a ‘‘project;’’ it was not designed to
meet any specific need except that felt by its major
author, Ken Thompson, and soon after its origin by the
author of this paper, for a pleasant environment in
which to write and use programs.”
- Dennis Ritchie, “The UNIX Time-sharing System – A
1/11/16
EECS 582 – W16
Retrospective”
4
UNIX
• First version on DEC PDP-7 and PDP-9 (circa 1969-70)
• Second version on unprotected DEC PDP-11/20
• Third version w/ multiprogramming on PDP-11/40, 45 etc.
• Described in today’s paper
• February, 1971: PDP-11 Unix first operational
1/11/16
EECS 582 – W16
5
PDP-11/40
• 16-bit word (8-bit byte)
• 144K bytes core memory
• UNIX took 42K bytes
• Minimal system 50K bytes
• Storage
• 1M byte fixed-head disk
• 4X 2.5M byte moving-head disk
cartridge
• 1X 40M byte moving-head disk
pack
• 14 variable speed
communication interfaces
• Many other attached devices
1/11/16
http://www.catb.org/esr/writings/taoup/html/graphics/kd14.j
pg
EECS 582 – W16
6
Simplicity
• Simple abstractions
• Everything is a file
• Simple file system design
• Hierarchical for programming
simplicity
• Simple connectors
• Pipes that look like files
• Simple maintenance
• Self-maintained
1/11/16
“It is hoped, however, the users of
UNIX will find that the most
important characteristics of the
system are its simplicity,
elegance, and ease of use.”
- DR & KT, “The UNIX Time-Sharing
System”
EECS 582 – W16
7
Influences
• Berkeley Timesharing
System
• Process forks
• Multics
• I/O system calls
• Multics and TENEX
• Shell and related
• CTSS
• “…in essence a modern
implementation of MIT’s
CTSS system…” – D. Ritchie
1/11/16
“The success of UNIX lies not so
much in new inventions but rather
in the full exploitation of a
carefully selected set of fertile
ideas, and especially in showing
that they can be keys to the
implementation of a small yet
powerful operating system.”
- DR & KT, “The UNIX Time-Sharing
EECS 582 – W16
8
System”
Key Concepts
• Names and namespaces
• Directories, paths, and links
• Root, home, and current directory
• Rooted tree and mounting sub-trees on leaves
• Special files and access control
• Process management
• System calls, address space, signals/interrupts
• User interface
• Shell, I/O redirection, and pipes
1/11/16
EECS 582 – W16
9
Hierarchical Namespace
• Easy to traverse
• Easy to modify/add/delete
• Access control is simpler
• Hierarchical as well
• Can be arbitrarily increased
• Mount new drives!
1/11/16
EECS 582 – W16
10
Everything is a File
• Regular files
• Special files
• Devices
• Networks
• Directories
• Same as files, except when not
• Keeps track of pointers to files, not actual content
• Simplifies linking!
1/11/16
EECS 582 – W16
11
I/O Calls
• Inspired by Multics
• Primary functions
• open, close, read, write, seek
• Interface that has passed the test of time: haven’t effectively changed
yet!
• BSD socket API is similar
• open, close, send, recv
1/11/16
EECS 582 – W16
12
No Locks
“We take the view that locks are neither necessary nor
sufficient, in our environment, to prevent interference
between users of the same file. They are unnecessary
because we are not faced with large, single-file data bases
maintained by independent processes. They are
insufficient because locks in the ordinary sense, whereby
one user is pre- vented from writing on a file which another
user is reading, cannot prevent confusion when, for
example, both users are editing a file with an editor which
makes a copy of the file being edited.”
1/11/16
EECS 582 – W16
- DR & KT, “The UNIX Time-Sharing System”
13
File System Implementation
• Thompson and Ritchie took special pride in their design of the
file system
• My opinion from the reading
• Given the long-term impact, I think it’s justified!
• We’ll skip the details, and wait for next week when we read FFS
1/11/16
EECS 582 – W16
14
Execution
• Image is an execution environment
• Container is the current parallel
• Process is the execution of the image
• Program text is write-protected and shared between all running
processes of the same program
• Created using fork
• Inspired by Berkeley Timesharing System
1/11/16
EECS 582 – W16
15
Processes and the Kernel
• Process
P1
P2
P3
• Separate virtual address space
• Only one thread!
• Kernel
Interactions via system calls and signals/interrupts
• Mediator for accessing shared
resources and kernel services
Kernel
1/11/16
EECS 582 – W16
16
Pipes
• This is the ‘|’ when writing shell commands
• Mechanism for inter-process communication
• Using file descriptor
• Again files!
• Allows to build large workflows by connecting separate
programs
• We do the same today
1/11/16
EECS 582 – W16
17
Worse is Better & End-to-End Arguments
1.
2.
3.
4.
5.
6.
1/11/16
Simplicity
Ease of Use and Maintenance
Consistency Across Interfaces
Completeness of Design
Correctness of Specification and Implementation
Placement of Functionality
EECS 582 – W16
18
Next Class…
• System R
1/11/16
EECS 582 – W16
19