Transcript CSE451 Introduction to Operating Systems Autumn 2002 Gary Kimura Lecture #1 September 30, 2002

CSE451 Introduction to Operating Systems
Autumn 2002
Gary Kimura
Lecture #1
September 30, 2002
1
Today
• Class details
• CSE451 educational objectives
• A quick look at what is an operating system
• The class web page is up and running
– Class information
– Lecture notes
– Project and homework assignments
– Helpful hints and other pointers
– Email discussion
2
Class details
• Instructor:
Gary Kimura ([email protected])
Office hours: Sieg 325E MF 1:00 to 2:00 or by
appointment
Email is the best way to contact me
• TAs:
Alex Quinn ([email protected])
Office hours: Wed 10:00 to 11:00 Location TBD
Russell Power ([email protected])
Office Hours: Tues 1:30 to 2:30 Location TBD
• Please ask questions during class and make the lectures
interactive
• I’m open to suggestions for later OS topics to cover
• Overloads?
3
Grading (subject to adjustment)
• 20% Homework
– Approximately 5 assignments
– One week from when the assignment is handed out to
when it it due
• 40% Exams
– Two midterms (tentatively October 25 and November
22)
– Final
• 35% Projects
– Tentatively 4 projects
– At least two weeks to finish each project
• 5% Other
4
Tentative class outline
• Silberschatz, et.al., Operating System Concepts (Sixth
Edition)
– What about the Windows XP Update?
•
•
•
•
•
•
OS Overview (Chapters 1, 2, and 3)
Process Management (Chapters 4, 5, 6, 7, and 8)
Storage Management (Chapters 9, 10, 11, and 12)
I/O Systems (Chapters 13, and 14)
Distributed Systems (Chapter 15)
Accounting, Protection, and Security (Chapters 18 and 19)
5
Your job for week #1
• Readings in Silberschatz
– Chapter 1 (Monday lecture),
– Chapter 2 (Wednesday lecture)
– Chapter 3 (Friday lecture)
• Homework #1
– Out: Today Monday September 30, 2002
– Due: Next Monday October 7, 2002 in class
– See handout
• Thursday Project #1 will be handed out
• Review “C” and brush on binary/octal/hexadecimal
6
CSE 451 Education objectives
• Two views of an OS
– The OS user’s (i.e., application programmers) view
– The OS implementer’s view
• In this class we will learn:
– What are the parts of an O.S.
– How is the O.S. and each sub-part structured
– What are the important interfaces
– What are the important policies
– What algorithms are typically used
• We will do this through reading, lectures, and a project.
• You will need to keep up with all three of these.
7
What is an Operating System?
• The average computer user has trouble understanding this
question
• I worked on Windows NT for many years and had a
terrible time explaining to my mother what I really worked
on
• Take a moment and answer the question
“What is an Operating System?”
8
What really is an Operating System?
• Naively it is “All the code that you didn’t write” in order to
implement your application (only true if you are not the
OS programmer).
• A software layer to abstract away and manage details of
hardware resources
– Provides users (application programmers) with
“logical” well-behaved environment
– O.S. defines a set of logical resources (objects) and a
set of well-defined operations on those objects (i.e., an
interface to use those objects)
– Provides mechanisms and policies for the control of
objects/resources
– Controls how different users and programs interact
• Without an OS there would be a lot more work to write and9
run programs
The OS and Hardware
• An OS mediates programs’ access to hardware resources
– Computation (the CPU which as a rule can only do one
thing at a time)
– Volatile storage (memory) and persistent storage (disk,
etc.)
– Network communications (TCP/IP stacks, ethernet cards,
etc.)
– Input/output devices (keyboard, display, sound card, etc.)
• The OS abstracts hardware into logical resources and welldefined interfaces to those resources
– processes (CPU, memory)
– files (disk)
• programs (sequences of instructions)
– sockets (network)
10
Why bother with an OS?
• Application benefits
– programming simplicity
• see high-level abstractions (files) instead of low-level hardware
details (device registers)
• abstractions are reusable across many programs
– portability (across machine configurations or
architectures)
• device independence: 3Com card or Intel card?
• User benefits
– safety
• program “sees” own virtual machine, thinks it owns computer
• OS protects programs from each other
• OS fairly multiplexes resources across programs
– efficiency (cost and speed)
• share one computer across many users
• concurrent execution of multiple programs
11
What’s in an OS?
Quake
Application
Services
SYSTEM CALL API
System Utils
Naming
Networking
Machine
Independent
Services
Generic I/O
Device Drivers
Sql Server
Shells
Access Control
Windowing & graphics
Windowing & Gfx
Virtual Memory
File System
Process Management
Memory Management
MD API
Machine Dependent
Services
Interrupts, Cache, Physical Memory, TLB, Hardware Devices
Logical OS Structure
12
Major issues in Operating Systems
•
•
•
•
•
•
•
•
•
Structure – how is an operating system organized?
Sharing – how are resources shared among users
Naming – how are resources named (by users or programs)
Protection – how is one user/program protected from
another
Security – how to restrict the flow of information
Performance – why is it so slow?
Reliability and fault tolerance – when something goes
wrong
Extensibility – how do we add new features?
Communication – how and with whom can we
communicate (exchange information)
13
Major issues in OS (2)
• Concurrency – how are parallel activities created and
controlled?
• Scale and growth – what happens as demands or resources
increase?
• Persistence – how to make data last longer than programs
• Compatibility – can we ever do anything new?
• Distribution – Accessing the world of information
• Accounting – who pays the bills, and how do we control
resource usage?
14
A Few Ground Rules
1. Always think about the “system” part of an operating
system
– Good analogies found in real life systems
2. Technology changes everything
– Look for the inflection points!
• Stemming from, or leading to, the “killer app”
– Generally, someone’s trying to MAKE money or
SAVE money by doing something differently
3. Most designers are not stupid, but priorities do change
– Choose 2 of [Soon, Good, Cheap.]
4. Three things people tend to forget:
– Testability, Usability, Manageability.
5. Code and Data are a matter of perspective.
15
Rules - Continued
6. MECHANISM and POLICY are generally separable
7. Simple solutions are generally better than complex ones.
– “Simple and good enough” almost always more attractive than
optimal.
– Always consider the “Do nothing” option.
– Static solutions are generally simpler than dynamic ones
8. In general, the future is unknowable, except in retrospect
– It’s a good bet though that it looks like the past
9. Laziness in the presence of uncertainty is generally
rewarded
– But punished in its absence
10. Often, all it takes is the the right level of indirection.
11. Space and time are interchangeable
12. 2x rarely matters, 10x almost always does.
13. SCALABILITY separates the good from the great
16
A very brief and incomplete history of operating
systems
• “In the beginning”, the OS was just code to which you
linked your program, loaded the whole thing into memory,
and ran your program; basically, just a run-time library
• Simple batch systems were the first real operating systems:
– O.S. was stored in part of primary memory
– It loaded a single job (from card reader) into memory
– Ran that job (printed its output, etc.)
– Loaded the next job...
– Control cards in the input file told the O.S. what to do
• Spooling and buffering allowed jobs to be read ahead of
time onto tape/disk or into memory.
17
Spooling
• Disks were much faster than card readers and printers
• Spool (Simultaneous Peripheral Operation On-Line)
– while one job is executing, spool next job from card
reader onto disk
• slow card reader I/O is overlapped with CPU
– can even spool multiple programs onto disk
• OS must choose which to run next
• job scheduling
– but, CPU still idle when a program interacts with a
peripheral during execution
18
Multiprogramming
• Multiprogramming systems provided increased utilization
– Keeps multiple runnable jobs loaded in memory
– Overlaps I/O processing of a job with computes of
another
– Benefits from I/O devices that can operate
asynchronously
– Requires the use of interrupts and DMA
– Tries to optimize throughput at the cost of response
time
19
Timesharing
• Timesharing supported interactive use of
– Each user feels as if he/she has the entire machine (at
least late at night!)
– Timesharing tries to optimize response time at the cost
of throughput
– Based on time-slicing -- dividing CPU equally among
the users
– Permitted active viewing, editing, debugging,
participation of users in the execution process
• MIT Multics system (mid-late 1960s) was first large
timesharing system
20
Distributed Operating Systems
• Distributed systems facilitate use of geographically
distributed resources
– Machines connected by wires
• Supports communication between parts of a job or
different jobs
– Interprocess communication
• Sharing of distributed resources, hardware and software
– Resource utilization and access
• Permits some parallelism, but speedup is not the issue
21
Parallel Operating Systems
• Support parallel applications wishing to get speedup of
computationally complex tasks
• Needs basic primitives for dividing one task into multiple
parallel activities
• Supports efficient communication between those activities
• Supports synchronization of activities to coordinate
sharing of information
• It’s common now to use networks of high-performance
PCs/workstations as a parallel computer
22
Embedded Operating Systems
• The decreased cost of processing makes computers
ubiquitous. Each “embedded” application needs its own
OS or control software:
– Cell phones
– PDAs (Palm Pilot, etc.)
– “Network terminals” (internet interfaces)
• In the future, your house will have 100s of these things in
it (if it doesn’t already)
23
Future Operating Systems
• Who knows that future is going to bring?
• An OS for a ubiquitous computing environment?
• Radically different programming and usage paradigms will
necessitate changes to the OS
• Without a crystal ball it’s hard to say where this will end
• This class will stress some of the fundamental parts that
will probably always be needed in any basic OS (but there
are no guarantees)
• In many ways the OS is like the service industry. By itself
it has little use, but it supports services for programs that
do provide value, and it must be kept usable
24
An OS Design Goal
• A good OS should be easily usable by everyone
25
Next time
• What features in the Hardware does an OS need?
26