Instructor: Mark Kampe
(markk@cs.ucla.edu)
CS 111 – Operating Systems
Introduction to course
Background
–
experience survey
–
introduction to course, grading, academic honesty
–
not a professor, not regular faculty
–
why study operating systems
–
software engineer with 30 years of OS experience
–
themes and techniques to be covered in course
–
here because I love OS and I love teaching
Introduction to operating systems
Available for help
–
OS, applications, and system services
–
before and after class
–
resources and abstractions
–
any time via e-mail
–
the evolution of operating systems
–
by appointment
introduction
4/3/03 - 1
Course Web Site
it is full now, but there may be openings later
I distribute PTE #s at the end of the 2nd week
schedules
if you want to get into this class
reading, lectures, quizzes, exams, homework
copies of lecture slides (pdf, 4 per page)
announcements
answers to homework and exam questions
–
attend lectures, do reading, turn in all assignments
–
send me e-mail with your name, ID#, major, year,
and why you must have this section this quarter
I allocate PTEs based on performance and need,
up to a maximum acceptable class size
Greek to English dictionary
auditors are welcome, even encouraged
sample quiz, exam and final problems
introduction
4/3/03 - 2
If you are trying to get into this class
http://www.cs.ucla.edu/classes/qtr/cs111/scn
–
introduction
4/3/03 - 3
introduction
4/3/03 - 4
Course Prerequisites
Course Load
CS 32 programming
reputations this course has
–
this is THE hardest class in the CS department
–
a fast pace through a lot of non-trivial material
–
I try to provide a "rich" treatment of the material
–
CS 33 systems programming
–
lecture/lab
5-6 hours/week
–
reading/homework
4-8 hours/week
–
projects
3-20 hours/week
–
exams
5-15 hours (3 times)
introduction
assembly language programming and data structures,
linkage conventions, stack frames, register saving
CS 118 networking
expectations you should have
–
objects, data structures, queues, stacks, tables, trees
–
packets, addressing, routing, protocols, protocol layering
CS 151 computer systems architecture
–
4/3/03 - 5
instructions, registers, memory, traps, interrupts, DMA
introduction
4/3/03 - 6
Course Lectures
Primary Text for Course
Nutt: Operating Systems – a modern perspective
–
–
background reading for virtually all lectures
good introduction to a good range of topics
–
good level of depth in most topics
–
good illustrations from real systems
–
repeat material that is well-covered in the reading
lectures will
–
clarify and elaborate on the text
provide examples and illustrative anecdotes
weaknesses for this course
work problems and expand on difficult concepts
–
occasional use of unnecessary formalisms
–
often misses practical perspectives and implications
introduction
what I can try to do is make it clear and relevant
lectures will not
strengths for this course
–
I cannot make this material simple or easy
explore implications and applications of concepts
4/3/03 - 7
–
introduction
present important material absent from the text
4/3/03 - 8
I want you to ask questions
Key Concepts
lectures cover things I consider to be important
–
if I lecture on something, expect to see it on a test
my only goal is to help you master this material
–
if you missed a point, others probably missed it too
–
if a point is not clear, I didn't explain it properly
–
asking questions will help us all
I will tell you up-front what the key concepts are
–
there is a list of them at the end of every lecture
–
there is a complete list posted on the web site
I will regularly test you on those key concepts
we learn new concepts by interacting with them
–
feel free to ask about implications and applications
–
challenge my generalities and over-simplifications
introduction
I am here to help you master some key concepts
4/3/03 - 9
–
90% of exam questions will center on key concepts
–
apply key concepts to real problem situations
–
use key concepts to gain insight into new problems
introduction
4/3/03 - 10
Course Grading
Quizzes
breakdown of points
When: first five minutes of each lecture period
–
18 daily quizzes
–
9 weekly homeworks 10%
–
2 midterms
20%
–
4 projects
30%
–
final exam
30%
10%
Scope: reading assigned for that lecture
Format:
expect the curve to fall near 90/80/70/60
–
typical distribution:
introduction
four simple questions (definitions, examples, ...)
–
should require at most one sentence answer
Goals:
course grades will be on a curve
–
–
–
test your familiarity with major concepts
–
encourage you to come prepared for each lecture
10 A's, 20 B's, 10 C's, 2 D's, 1 F
4/3/03 - 11
introduction
4/3/03 - 12
Homework
Regular Examinations
When: Due at start of first class of each week
When: 3rd / 4th week and 7th week
Scope: One week's reading and lectures
Scope: approximately six lectures of material
–
Format:
–
2-4 moderate essay questions or problems
–
some from the text, some I make up
Format:
Goals:
–
10-15 essay questions, most with short answers
–
debrief during last ten minutes of period
Goals:
–
test ability to apply key concepts from text
–
reinforce key concepts,
–
work areas where students often have problems
introduction
approximately 60% lecture, 40% text
4/3/03 - 13
–
test understanding of key concepts
–
test ability to apply principles to practical problems
introduction
4/3/03 - 14
Lab Projects
Final Exam
Format:
Scope: entire course
–
3/4 projects, of increasing difficulty
Format:
–
may be done individually or as two-person teams
–
8-12 hard multi-part essay questions
–
you get to pick a subset of them to answer
Goals:
Goals:
–
develop ability to exploit OS features
–
develop programming/problem solving ability
–
test mastery of key concepts
–
test ability to apply key concepts to real problems
–
instructor cannot help you with projects
–
use key concepts to gain insight into new problems
–
TA cannot help you with lectures, homework, exams
introduction
lab and lecture are completely separate
4/3/03 - 15
introduction
4/3/03 - 16
Grading: partial and extra credit
Partial Credit
–
Quizzes
will be awarded on all problems/projects, for
clear understanding of problem
reasonable approach to problem
start promptly at the beginning of the first hour
–
there are no make-ups for late or missed quizzes
–
Extra Credit
extra credit problems on midterm and final exams
likely to be more difficult than the other problems
raise possible score above 100%
–
–
Homework Assignments
incomplete or flawed solutions
–
Late Assignments and Make-ups
possible on any quiz/test/homework question
will not be accepted after the solutions are posted
Exams
–
make-ups only available for medical emergencies
–
requires a letter from your doctor
–
make-up (different tests) given after end of quarter
50% bonus for any answer that is better than mine
introduction
4/3/03 - 17
Academic Honesty – take it seriously
academic dishonesty cheats us all
–
devalues grades & degrees, threatens accreditation
all suspected infractions must be reported to Dean
–
discussing problems helps you to understand them
–
do not copy another student's homework
–
do not turn in solutions from off the web
I decide when two assignments are too similar
no warnings, no second chances, zero tolerance
–
every year a few students test these policies
and I forward them immediately to the Dean
if you need help, ask the instructor
–
they try to cheat on homework, quizzes, projects
–
graduations are delayed, students are suspended
introduction
Academic Honesty – homework
but you must do your homework by yourself
my policy
–
4/3/03 - 18
it is OK to study with friends
University policy
–
introduction
4/3/03 - 19
introduction
4/3/03 - 20
Academic Honesty – Quizzes/Exams
Academic Honesty – Projects
do not copy anyone else's answers
–
do your own projects
if you study with a friend, sit very far apart
do not use any reference materials during tests
if you need a dictionary, inform the instructor
–
if you don't understand a question, ask the instructor
no talking or exchanging notes during tests
all tests are to be returned to the instructor
introduction
–
if you need additional help, ask the TA
–
do not ask others how they solved the problem
–
do not copy solutions from the web, files or listings
protect yourself
if you have a question, raise your hand
no removal of test materials from the class room
–
work only with your team-mate
you must design and write all your own code
–
–
–
4/3/03 - 21
–
do not show other people your solutions
–
be careful with old listings
introduction
How OS relates to other courses
OS will apply concepts introduced in other courses
–
data structures, programming languages, assembly
language programming, network protocols, computer
architectures, ...
OS will prepare you for more advanced courses
–
data bases and distributed computing
–
security, fault-tolerance, high availability
–
computer system modeling, queueing theory
processes, files, threads, capabilities, synchronization, ...
introduction
Why Study Operating Systems?
few of you will build OS, but many of you will ...
–
set up, configure and manage computer systems
–
write programs that exploit OS features
–
work with complex, distributed, and parallel software
–
work with abstracted services and resources
OS have had to solve many very hard problems
OS will give you a rich set of foundation concepts
–
4/3/03 - 22
4/3/03 - 23
–
synchronization, security, integrity, protocols, distributed
computing, dynamic resource management, ...
–
in OS, we study these problems and their solutions
–
these approaches can be applied to many other areas
introduction
4/3/03 - 24
Why do I love Operating Systems?
they are extremely complex
–
Recurring Themes in this course
view services in terms of objects and operations
yet they must be understandable by one person
they are very demanding
–
and behind every object there is a data structure
mechanism/policy separation
–
they require vision, imagination and insight
–
mechanism implements basic operations on resources
–
they must have elegance and generality
–
policy determines how resources are allocated
–
they also demand meticulous attention to detail
–
mechanisms should not dictate or limit policies
–
new policies should not require mechanism changes
they are held to very high standards
–
different situations call for different policies
performance, scalability, correctness, extensibility
mechanisms should include policy specification interfaces
they attract some very interesting people
introduction
4/3/03 - 25
Recurring Themes in this course
an interface specification is a contract
introduction
What Does an Operating System do?
Manage hardware for programs
–
defines responsibilies of producers and consumers
–
allocate hardware and manage its use
–
basis for product/vendor/release interoperability
–
enforce controlled sharing (and privacy)
–
oversee execution and deal with problems
interface vs. implementation
–
an implementation is not an interface specification
–
there are many ways to implement a specification
–
make it easier to use
–
inappropriate dependencies reduce interoperability
–
optimize performance
modularity and functional encapsulation
–
introduction
4/3/03 - 26
abstract the hardware
provide other useful abstractions for applications
complexity hiding and appropriate abstraction
–
4/3/03 - 27
useful features, not provided by the bare hardware
introduction
4/3/03 - 28
What does OS look like to its clients?
Hardware/Software Platform Layering
Management/abstraction are behind the scenes
Applications Software
(e.g. word processor, compiler, MPEG decoder, ...)
What applications see is objects and services
–
Application Binary Interface
computers support data-types and operations on them
System Services/Libraries
(e.g. string, random #s, encryption,graphics ...)
bytes, shorts, longs, floats, pointers, ...
System Call Interface
add, subtract, copy, compare, indirection, ...
–
so do operating systems
Operating System
files, processes, devices, communications ports, ...
Privileged instruction set
create, destroy, read, write, signal, ...
an operating system extends a computer
–
Hardware
4/3/03 - 29
What makes the OS so special?
4/3/03 - 30
as much as necessary, as little as possible
–
–
it is automatically loaded when the machine boots
–
it is the first software to have access to the hardware
–
it continues running while applications come and go
it alone has complete access to the hardware
privileged instruction set, all of memory, all I/O devices
it mediates the applications' access to the hardware
it can block, permit, or modify application requests
introduction
introduction
What functionality goes into the OS?
it is always in control of the hardware
–
(arithmetic, logical, copy, test, flow-control operations, ...)
creating a much richer virtual computing platform
introduction
–
Standard instruction set
4/3/03 - 31
OS code is very expensive to develop and maintain
functionality must be in the OS if it ...
–
requires the use of privileged instructions
–
requires the manipulation of OS data structures
–
must maintain security, trust, or resource integrity
functions should be implemented in libraries if it ...
–
is a service commonly needed by applications
–
does not actually have to be implemented inside OS
introduction
4/3/03 - 32
Abstracted Resources
Abstracted Resources
Map one set of objects/operations into another
–
e.g. CPU->processes, disk->files, network->services
simplifying abstractions: easier to use
generalizing abstractions: unify different resources
–
make many different types appear to be same
–
enable applications to deal with generic ideal
usually involves a common model
–
compartmentalize/encapsulate complexity
–
eliminate behavior that is irrelevant to user
–
portable document format (pdf) for printers
–
create more convenient behavior
–
SCSI standard for disks, CDs and tapes
examples:
usually involves a federation framework
–
a GPS moving-map navigation system
–
printer drivers that make different printers look the same
–
a network protocol that provides a reliable channel
–
browser plug-ins to handle multi-media data
introduction
4/3/03 - 33
introduction
example: layers of abstraction – browser
General Types of Resources
Serially reusable resources (temporal multiplexing)
display driver – generalizing abstraction for video adaptors
–
used by multiple clients, but only one at a time
–
require access control to ensure exclusive use
plug-in framework – generalizing abstraction for data formats
–
require graceful transitions from one user to the next
html
–
examples: bathroom stalls, printers
Browser – simplifying abstraction for data navigation
mp3
jpeg
flash
Partition-able resources (spatial multiplexing)
http – simplifying abstraction for remote file access
ssl – simplifying abstraction for secure communication
introduction
4/3/03 - 34
4/3/03 - 35
–
divided into pieces for multiple clients
–
requires access control to ensure containment/privacy
–
examples: dormitory rooms, disk space
introduction
4/3/03 - 36
Sharable Resources
OS Evolution – the earliest computers
simultaneously usable by multiple concurrent clients
–
clients do not have to “wait” for access to resource
–
clients do not “own” a particular subset of the resource
may involve resources that are effectively limitless
–
examples: air in this room, copy of the operating system
examples: cell-phone channel, shared network interface
introduction
input: cards/tape, output: print-outs, tape
persistent data: cards and tape
debugging: lights and switches
I/O devices: simple and slow
No Operating System
may involve under-the-covers multiplexing
–
Scheduled for use by one user at a time
4/3/03 - 37
compilers, assemblers, math-packages
introduction
OS Evolution – Batch Processing
Typified by the 1960s IBM System/360
4/3/03 - 38
OS Evolution – Time Sharing
Typified by IBM/CMS, Multics, UNIX
–
Programs submitted and picked up later
–
Multi-user, interaction through terminals
–
input and output spooling to tape and disk
–
all programs and data stored on disk
–
batch control language to manage program execution
Goals: efficient use of CPU, maximize throughput
–
I/O able to proceed with minimal CPU
–
overlapped execution and I/O maximize CPU usage
–
may have multi-tasking ability to minimize idle time
OS: batch monitor and I/O supervisor
introduction
4/3/03 - 39
Goals: sharing for interactive users
–
interactive apps demand short response time
–
enhanced security required to ensure privacy
OS and system services expanded greatly
–
terminal I/O, synchronization, inter-process
communication, networking, protection, etc.
introduction
4/3/03 - 40
Evolution: PCs and Work Stations
OS Evolution – Embedded Systems
PCs returned to single user paradigm
general purpose systems vs. appliances
–
running software vs. performing a service
many appliances based on computers
–
video games, CD players, TV signal decoders
–
telephone switches, avionics, medical imaging
–
file systems and interactivity from timesharing systems
–
multi-tasking, networking, plug-n-play devices
ultra-high availability, more automation, zero admin
–
file transfer and e-mail led to group collaboration
–
the evolution of work groups and work-group servers
PCs got bigger, faster, more services
–
introduction
high end applications gave rise to work-stations
advent of local area networking
general purpose OS becoming more appliance-like
–
initially minimal I/O and system services
advent of personal productivity applications
appliances require increasingly powerful OSs
–
–
4/3/03 - 41
until they became indistinguishable from work stations
introduction
Evolution: the network is the computer
Client/Server Computing
centralized file and print servers for work groups
–
centralized mail and database servers for organizations
–
clients got thinner, servers became necessary
Wide-Area Networking
e-mail, HTML/HTTP and the world-wide-web
–
electronic business services
Evolution of Operating Systems
they have grown larger and more sophisticated
–
–
4/3/03 - 42
their role has fundamentally changed
–
from shepherding the use of the hardware
–
to shielding the applications from the hardware
–
to providing a powerful application computing platform
they still sit between the applications and hardware
best understood in terms of services they provide
Distributed Computing Platforms
–
services are offerred by/among groups of systems
–
capabilities they add, and the applications they enable
–
system services must enable distributed applications
–
problems they eliminate
introduction
4/3/03 - 43
introduction
4/3/03 - 44
For the next lecture
Key Concepts
relationship of hardware, OS, libraries, applications
read chapters 1-3
–
a lot of pages, but the material is very simple
what functionality belongs in the operating system
–
WARNING: obtuse fork/join example in 2.3.1
generalizing and simplifying abstractions
there will be a quiz on chapters 1-3
serially reusable, partitionable, sharable resources
Next lecture
batch and timesharing systems and goals
–
expanding on design considerations
–
introduction to system services
–
introduction to processes and threads
introduction
architectural principles:
mechanism/policy separation,
modularity/encapsulation, interface vs.
implementation, appropriate abstractions
4/3/03 - 45
introduction
4/3/03 - 46