1

CSE451 Introduction to Operating Systems Autumn 2002

Gary KimuraLecture #1

September 30, 2002

2

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

3

Class details

• Instructor: Gary Kimura (garyki@cs.washington.edu)Office hours: Sieg 325E MF 1:00 to 2:00 or by appointmentEmail is the best way to contact me

• TAs: Alex Quinn (aquinn@cs.washington.edu)Office hours: Wed 10:00 to 11:00 Location TBDRussell Power (rjpower@cs.washington.edu)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?

4

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

5

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)

6

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

7

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.

8

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?”

9

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 and run

programs

10

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 well-defined interfaces to those resources– processes (CPU, memory)– files (disk)

• programs (sequences of instructions)

– sockets (network)

11

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

12

What’s in an OS?

Machine Dependent Services

Interrupts, Cache, Physical Memory, TLB, Hardware Devices

Generic I/OFile System

Memory Management

Process Management

Virtual MemoryNetworking

Naming Access Control

Windowing & graphics

Windowing & Gfx

Machine Independent Services

Application Services

SYSTEM CALL API

MD API

Device Drivers

ShellsSystem Utils

Quake Sql Server

Logical OS Structure

13

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)

14

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?

15

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.

16

Rules - Continued

6. MECHANISM and POLICY are generally separable7. 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

17

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.

18

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

19

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

20

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

21

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

22

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

23

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)

24

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

25

An OS Design Goal

• A good OS should be easily usable by everyone

26

Next time

• What features in the Hardware does an OS need?