Introduction CS 4410 Operating Systems [ R. Agarwal, L. Alvisi, A. - - PowerPoint PPT Presentation

introduction
SMART_READER_LITE
LIVE PREVIEW

Introduction CS 4410 Operating Systems [ R. Agarwal, L. Alvisi, A. - - PowerPoint PPT Presentation

Introduction CS 4410 Operating Systems [ R. Agarwal, L. Alvisi, A. Bracy, M. George, F. B. Schneider, E. G. Sirer, R. van Renesse ] What an OS does OS is an intermediary between programs and hardware. OS creates an environment to


slide-1
SLIDE 1

Introduction

CS 4410 Operating Systems

[R. Agarwal, L. Alvisi, A. Bracy, M. George,

  • F. B. Schneider, E. G. Sirer, R. van Renesse]
slide-2
SLIDE 2
  • OS is an intermediary between programs and

hardware.

  • OS creates an environment to execute programs in a

convenient and efficient manner:

  • allocates resources (CPU and storage)
  • controls programs
  • cooperation (sharing and synchronization)
  • isolation (protection and resource management)

What an OS does

2

Operating System

Application Application Application Application Application

Hardware

OS Interface

Physical Machine Interface

slide-3
SLIDE 3
  • Services it provides to programs
  • Components implementing those

services

  • internal design and implementation
  • Real hardware is ugly.
  • interactions

Ways to view an OS

3

slide-4
SLIDE 4

Learn solutions to problems arising in all systems:

  • Resource sharing (scheduling)
  • Cooperation (concurrent programming:

communication, synchronization)

  • System structure (abstractions, interfaces)

Why Study OS?

4

slide-5
SLIDE 5

How designing an OS differs from designing a program.

  • Measure of success: OS concerned with

extensibility, security, reliability, …

  • External interface: OS more complicated and

subject to change. Eg I/O devices.

  • Internal structure: OS must pick boundaries

between functions:

  • RISC vs CISC
  • C-time vs run-time (cf Java)
  • Heap with garbage collection vs stack allocation
  • Structuring techniques: OS employs
  • modules, layers, client-server, event-handler, transaction

Systems vs Programs (I)

5

slide-6
SLIDE 6

How designing an OS differs from designing a program.

  • OS must bridge mismatched performance

characteristics.

  • Registers vs RAM vs Disk
  • Desktop processor vs Cloud

Systems vs Programs (II)

6

slide-7
SLIDE 7

Copy file F from cpu 1 to cpu 2 despite possible transients. Copy proceeds one block b1, b2, b3, … at a time. Packets size ≠ block size. Soln 1: Checksum F, send all blocks, send checksum. Soln 2: Checksum sent with each packet on network. Soln 3: Checksum successive file prefixes. So sends…

  • B1 chk(b1), b2 chk(b1 b2), b3 chk(b1, b2, b3)

End to End Argument: Trade-offs

7

cpu 1 cpu 2

file F

network

transient

slide-8
SLIDE 8

Copy file F from cpu 1 to cpu 2 despite possible transients. Copy proceeds one block b1, b2, b3, … at a time. Packets size ≠ block size. Soln 1: Checksum F, send all blocks, send checksum. Soln 2: Checksum sent with each packet on network. Soln 3: Checksum successive file prefixes. So sends…

  • B1 chk(b1), b2 chk(b1 b2), b3 chk(b1, b2, b3)

End to End Argument: Trade-offs

8

cpu 1 cpu 2

file F

network

transient

slide-9
SLIDE 9

Copy file F from cpu 1 to cpu 2 despite possible transients. Copy proceeds one block b1, b2, b3, … at a time. Packets size ≠ block size. Soln 1: Checksum F, send all blocks, send checksum. Soln 2: Checksum sent with each packet on network. Soln 3: Checksum successive file prefixes. So sends…

  • B1 chk(b1), b2 chk(b1 b2), b3 chk(b1, b2, b3)

End to End Argument: Trade-offs

9

cpu 1 cpu 2

file F

network

transient

slide-10
SLIDE 10

Copy file F from cpu 1 to cpu 2 despite possible transients. Copy proceeds one block b1, b2, b3, … at a time. Packets size ≠ block size. Soln 1: Checksum F, send all blocks, send checksum. Soln 2: Checksum sent with each packet on network. Soln 3: Checksum successive file prefixes. So sends…

  • B1 chk(b1), b2 chk(b1 b2), b3 chk(b1, b2, b3)

End to End Argument: Trade-offs

10

cpu 1 cpu 2

file F

network

transient

slide-11
SLIDE 11

Emergent properties: Evident only when components are combined.

Example: Millennium Bridge (London)

What makes systems complex?

11

slide-12
SLIDE 12

Propagation of Effects: When small changes have disproportionate effects. Examples:

  • Power failures in power grid
  • Change auto tire size from 13” to 15”
  • Boeing 737 max 8 design

4th generation of 737: new engines, same exit doors.

What makes systems complex?

12

slide-13
SLIDE 13

Incommensurate Scaling: Different parts follow different scaling rules. Examples:

  • Height limits on skyscrapers
  • Size limits on railroad trains and cargo ships

» Horizon distance is linear in size of object » Stopping distance is proportional to object volume.

What makes systems complex?

13

slide-14
SLIDE 14
  • Modularity: Good modularity minimizes

connections between components.

  • Abstraction: Separate interface from

internals; separate specification from implementation

  • Hierarchy: Constrains interactions so easier

to understand.

  • L levels with N components / level
  • (N x L)2

vs L x N2 interactions

How to Manage Complexity

14

slide-15
SLIDE 15

Referee

  • Manages shared resources: CPU, memory, disks,

networks, displays, cameras, etc.

Illusionist

  • Look! Infinite memory! Your own private processor!

Glue

  • Offers set of common services (e.g., UI routines)
  • Separates apps from I/O devices

OS has many roles

15

slide-16
SLIDE 16

OS as Referee

16

Resource allocation

  • Multiple concurrent tasks, how does OS decide

who gets how much?

Isolation

  • A faulty app should not disrupt other apps or OS
  • OS must export less than full power of

underlying hardware

Communication/Coordination

  • Apps need to coordinate and share state
slide-17
SLIDE 17

OS as Illusionist (1)

17

Virtualization: Resources seem present but aren’t.

  • processor, memory, screen space, disk, network
  • the entire computer:
  • fooling the illusionist itself!
  • ease of debugging, portability, isolation

Operating System (VMM)

App

Hardware

Virtual Machine Interface

App Guest OS Guest OS App App

slide-18
SLIDE 18

Abstraction: Enables new assumptions for clients

  • Atomic operations
  • HW guarantees atomicity at word level
  • what happens during concurrent updates to complex data

structures?

  • what if computer crashes during a block write?
  • At the hardware level, packets are lost…
  • Reliable communication channels

OS as Illusionist (2)

18

slide-19
SLIDE 19

OS as Glue

19

Simplify app design and facilitate sharing due to:

  • send/receive of byte streams
  • read/write files
  • pass messages
  • share memory
  • UI

Decouples HW and app development

slide-20
SLIDE 20
  • Structure: how is the OS organized?
  • Concurrency: how are parallel activities

created and controlled?

  • Sharing: how are resources shared?
  • Naming: how are resources named by users?
  • Protection: how are distrusting parties

protected from each other?

  • Security: how to authenticate, authorize, and

ensure privacy?

  • Performance: how to make it fast?

Issues in OS Design

20

slide-21
SLIDE 21
  • Reliability: how do we deal with failures??
  • Portability: how to write once, run anywhere?
  • Extensibility: how do we add new features?
  • Communication: how do we exchange

information?

  • Scale: what happens as demands increase?
  • Persistence: how do we make information outlast

the processes that created it?

  • Accounting: who pays the bill and how do we

control resource usage?

Issues in OS Design

21