Contentfilip/bsy/OS-SS-2016.pdf · 14.04.2016 1 Lecture Operating Systems SS 2016 Prof. Dr. Werner...

170
14.04.2016 1 Lecture Operating Systems SS 2016 Prof. Dr. Werner Filip [email protected] 1 Content 1. Introduction 2 P d P M t General Topics 2. Processes and Process Management 3. Memory Management 4. File Systems 5. Input/Output Operating Systems Prof. Dr. Werner Filip 6. Multiple Processor Systems 2

Transcript of Contentfilip/bsy/OS-SS-2016.pdf · 14.04.2016 1 Lecture Operating Systems SS 2016 Prof. Dr. Werner...

14.04.2016

1

Lecture

Operating Systems

SS 2016

Prof. Dr. Werner Filip

[email protected]

1

Content

1. Introduction

2 P d P M t

Gen

eral

Top

ics 2. Processes and Process Management

3. Memory Management

4. File Systems

5. Input/Output

Operating Systems Prof. Dr. Werner Filip

6. Multiple Processor Systems

2

14.04.2016

2

A.S. Tanenbaum, H. Bos: Modern Operating Systms, 4th Ed., Pearson, 2015.

A.S. Tanenbaum:

Moderne Betriebssysteme Pearson Studium 2012

ReferenceG

ener

al T

opic

s

Moderne Betriebssysteme, Pearson Studium, 2012. Silberschatz, P. Galvin, G. Gagne:

Operating Systems Concept, 9th Ed., John Wiley & Sons, 2013. Achilles:

Betriebssysteme, Springer, 2006. E. Glatz:

Betriebssysteme - Grundlagen, Konzepte, Systemprogrammierung,G

Operating Systems Prof. Dr. Werner Filip

Betriebssysteme Grundlagen, Konzepte, Systemprogrammierung, dpunkt.verlag, 2006.

3

Chapter 1

Introduction

Intr

oduc

tion

Operating Systems Prof. Dr. Werner Filip4

14.04.2016

3

Outline

• What is an Operating System

Intr

oduc

tion • The history of Operating Systems

• Hardware of Operating System

I t t t f O ti S t

Operating Systems Prof. Dr. Werner Filip5

• Important concepts of Operating Systems

What is an Operating System

A modern computer consists of:

Intr

oduc

tion

• One or more processors

• Main memory

• Disks

• Printers

• Various input/output devices

Operating Systems Prof. Dr. Werner Filip6

Managing all these components requires a layer of software – the operating system

14.04.2016

4

What is an Operating System

• A modern computer is very complex. – Networking

Intr

oduc

tion

– Disks– Video/audio card– ….

• It is impossible for every application programmer to understand every detail

Operating Systems Prof. Dr. Werner Filip7

• A layer of computer software is introduced to provide a better, simpler, cleaner model of the resources and manage them

What is an Operating System

Intr

oduc

tion

Operating Systems Prof. Dr. Werner Filip8

Where the operating system fits in.

14.04.2016

5

What is an Operating System

o Users use various OS• Windows Linux Mac OS etc

Intr

oduc

tion

Windows, Linux, Mac OS etc.

o User interacts with shell or GUI• part of OS ? • they use OS to get their work done

Operating Systems Prof. Dr. Werner Filip9

o Is device driver part of OS ?

What is an Operating System

• On top of hardware is OS

• Most computers have two modes of operation:

Intr

oduc

tion

• Most computers have two modes of operation:– Kernel mode and user mode– OS runs in kernel mode, which has complete access to

all hardware and can execute any instruction– Rest of software runs in user mode, which has limited

capabilityShell or GUI is the lowest level of user mode software

Operating Systems Prof. Dr. Werner Filip10

– Shell or GUI is the lowest level of user mode software

14.04.2016

6

What is an Operating System

• Two functions:

– From top to down: provide application programmers a

Intr

oduc

tion

– From top to down: provide application programmers a clean abstract set of resources instead of hardware ones

– From down to top: Manage hardware resources

Operating Systems Prof. Dr. Werner Filip11

The Operating System as a Resource Manager

• Allow multiple programs to run at the same time

• Manage and protect memory I/O devices and

Intr

oduc

tion

• Manage and protect memory, I/O devices, and other resources

• Includes multiplexing (sharing) resources in two different ways: • In time

Operating Systems Prof. Dr. Werner Filip12

• In space

14.04.2016

7

The Operating System as a Resource Manager

• Modern OS runs multiple programs of multiple users at the same time

Intr

oduc

tion

– Imagine what would happen if several programs want to print at the same time?

– How to account the resource usage of each process?

– Resources can be multiplexed:• How to ensure fairness and efficiency?

Operating Systems Prof. Dr. Werner Filip13

y

Summary

• Operating system is a software

I l ft

Intr

oduc

tion

– Is a complex software

– Runs in kernel mode

– Manages hardware

– Provide a friendly interface for application programmer

Operating Systems Prof. Dr. Werner Filip14

14.04.2016

8

History of Operating Systems

• First generation 1945 - 1955– vacuum tubes, plug boards

• Second generation 1955 - 1965– transistors, batch systems

• Third generation 1965 – 1980– ICs (Integrated Circuits) and multiprogramming

Intr

oduc

tion

• Fourth generation 1980 – present– personal computers

Operating Systems Prof. Dr. Werner Filip2- 6615

1st: vacuum tubes

• Large and slow

• Engineers design, build, operate and maintain the

Intr

oduc

tion

computer

• All programming is done with machine language, or by wiring circuits using cables

• insert plugboards into the computer and operate

• The work is mainly numerical calculations

Operating Systems Prof. Dr. Werner Filip16

y

14.04.2016

9

1st: vacuum tubesIn

trod

ucti

on

Operating Systems Prof. Dr. Werner Filip2- 6617

2nd: transistors and batch systems

• Also called mainframes

• Computers are managed by professional operators

Intr

oduc

tion

• Programmers use punch card to run programs; operators operate (load compiler, etc ) and collect output to the user

• Complains soon come:– Human Operation between computer operation

Operating Systems Prof. Dr. Werner Filip2- 6618

– Lead to batch system

– Collect a batch of jobs in the input room, then read them into a magnetic tape; the same for output

14.04.2016

10

2nd: transistors and batch systems

Early batch systemIntr

oduc

tion

– bring cards to 1401– read cards to tape– put tape on 7094 which does computing– put tape on 1401 which prints output

Operating Systems Prof. Dr. Werner Filip19

2nd: transistors and batch systems

Intr

oduc

tion

• Structure of a typical FMS job – 2nd generationFMS – Fortran Memory System

Operating Systems Prof. Dr. Werner Filip20

14.04.2016

11

2nd: transistors and batch systemsIn

trod

ucti

on

Operating Systems Prof. Dr. Werner Filip2- 6621

3rd: IC and Multiprogramming

• OS/360: “a dinosaur”– Aims to adapts 1401/7904, covers all trades of life

Intr

oduc

tion

– However, OS/360 introduces several key techniques• Multi-programming: solve the problem of CPU idling

• Spooling: simultaneous peripheral operation on line

– Whenever a job finishes, OS load a new job from disk to the empty-partition

Operating Systems Prof. Dr. Werner Filip22

p y p

14.04.2016

12

3rd: IC and MultiprogrammingIn

trod

ucti

on

• Multiprogramming system – three jobs in memory

Operating Systems Prof. Dr. Werner Filip23

3rd: IC and Multiprogramming

Intr

oduc

tion

Operating Systems Prof. Dr. Werner Filip24

14.04.2016

13

3rd: IC and Multiprogramming

• Problems:– 3rd generation OS was well suited for big scientific

Intr

oduc

tion

calculations and massive data processing

– But many programmers complain a lot… for not be able to debug quickly….

– And the solution to this problem would be….?

– Timesharing:• a variant of multiprogramming

Operating Systems Prof. Dr. Werner Filip2- 6625

a variant of multiprogramming

• sharing of a computing resource among many users by means of multiprogramming

3rd: IC and Multiprogramming

• A system to be remembered: MULTICS– A machine that would support hundreds of

Intr

oduc

tion

simultaneous timesharing users (like a web server nowadays)

– Introduces many brilliant ideas but enjoys no commercial success

– Its step-child is the well-known and time-honored

Operating Systems Prof. Dr. Werner Filip2- 6626

UNIX

– System V/ FreeBSD, MINIX, Linux

14.04.2016

14

4th: Personal Computers

• Computers have performance similar to 3rd

generation, but prices drastically different

CP/M

Intr

oduc

tion

• CP/M (Control Program for Microcomputers)

– First disk-based OS

• 1980, IBM PC, Basic Interpreter, DOS, MS-DOS

• GUI--Lisa—Apple: user friendly

• MS DOS with GUI Win95/98/ winNT/xp

Operating Systems Prof. Dr. Werner Filip2- 6627

• MS-DOS with GUI– Win95/98/ – winNT/xp…

4th: Personal Computers

Intr

oduc

tion

Operating Systems Prof. Dr. Werner Filip2- 6628

14.04.2016

15

4th: Personal ComputersIn

trod

ucti

on

Operating Systems Prof. Dr. Werner Filip2- 6629

libguides.riphah.edu.pk

Summary

• 4 generations OS

Intr

oduc

tion

• Develops with hardware and user needs

• Multi-user, multi-programming, time-sharing

Operating Systems Prof. Dr. Werner Filip2- 6630

14.04.2016

16

Computer Hardware Review

Monitor

Bus

Intr

oduc

tion

• Components of a simple personal computer

Operating Systems Prof. Dr. Werner Filip31

Hardware: processor

• Brain of computer– Fetches instruction from memory and execute

C l f CPU

Intr

oduc

tion

– Cycle of CPU: • fetch, decode, execute

– CPU has registers to store variable and temporary result: load from memory to register; store from register to memory

– Program counter: next instruction to fetch

Operating Systems Prof. Dr. Werner Filip32

g

– Stack pointer: the top of the current stack

– . . .

14.04.2016

17

Computer Hardware Review In

trod

ucti

on

4 MB

1-8 MB

1-4 TB

• Typical memory hierarchy– numbers shown are rough approximations

Operating Systems Prof. Dr. Werner Filip33

Memory

Questions when dealing with cache:

• When to put a new item into the cache?

Intr

oduc

tion

• Which cache line to put the new item in?

• Which item to remove from the cache when a slot is needed?

• Where to put a newly evicted item in the larger memory?

Operating Systems Prof. Dr. Werner Filip34

y

14.04.2016

18

DisksIn

trod

ucti

on

Structure of a disk drive

Operating Systems Prof. Dr. Werner Filip35

Disks

• Cheap and large: two orders better than RAM• Slow: three orders worse than RAM

M h i l t t f t h d t

Intr

oduc

tion

• Mechanical movement to fetch data• One or more platter• Information is stored on concentric circles• Arm, track, cylinder, sector• Disk helps to implement Virtual Memory

Operating Systems Prof. Dr. Werner Filip36

– When not enough memory is available, disks are used as the storage, and memory as cache

14.04.2016

19

I/O DevicesIn

trod

ucti

on

(a) (b)

(a) Steps in starting an I/O device and getting interrupt(b) How the CPU is interrupted

Operating Systems Prof. Dr. Werner Filip37

( )

I/O Devices

• Two parts: a controller and a device

• Controller: to provide a simpler interface to OS

Intr

oduc

tion

Controller: to provide a simpler interface to OS

• Device driver: talks to controller, give commands and accepts response

• Busy waiting/interrupt/DMA

Operating Systems Prof. Dr. Werner Filip38

14.04.2016

20

Booting the Computer

• BIOS—basic input/output system

– On the motherboard, low-level I/O software

Intr

oduc

tion

– Checks RAM, keyboard and other basic devices

– Determine the boot device: floppy, CD-ROM, disk

– First sector of the boot-device is read into memory

– The sector contains program to check which partition is active

Operating Systems Prof. Dr. Werner Filip39

is active

– Then a secondary boot-loader is read into memory and reads in operating system from the active partition

Computer Hardware Review

Intr

oduc

tion

Structure of a large Pentium systemISA - Industry Standard Bus PCI - Peripheral Component Interconnect

USB - Universal Serial Bus SCSI – Small Computer System Interface

Operating Systems Prof. Dr. Werner Filip40

14.04.2016

21

The Operating System Zoo

• Mainframe operating systems

• Server operating systemsServer operating systems

• Multiprocessor operating systems

• Personal computer operating systems

• Real-time operating systemsIntr

oduc

tion

• Embedded operating systems

• Smart card operating systems

Operating Systems Prof. Dr. Werner Filip41

Operating System Concepts

A

Intr

oduc

tion

• A process tree– A created two child processes, B and C

– B created three child processes, D, E, and F

Operating Systems Prof. Dr. Werner Filip42

14.04.2016

22

Operating System Concepts In

trod

ucti

on

(a) a potential deadlock. (b) an actual deadlock.

Operating Systems Prof. Dr. Werner Filip43

Operating System Concepts

Intr

oduc

tion

File system for a university department

Operating Systems Prof. Dr. Werner Filip44

14.04.2016

23

System Calls

• System calls - interface for users to contact OS and hardware

Intr

oduc

tion • System calls vary from system to system, but

the underlying concepts are similar

Operating Systems Prof. Dr. Werner Filip45

Steps in Making a System Call

Intr

oduc

tion

There are 11 steps in making the system call

read (fd, buffer, nbytes)

Operating Systems Prof. Dr. Werner Filip46

14.04.2016

24

Some System Calls For Process ManagementIn

trod

ucti

on

Operating Systems Prof. Dr. Werner Filip47

Some System Calls For File Management

Intr

oduc

tion

Operating Systems Prof. Dr. Werner Filip48

14.04.2016

25

Some System Calls For Directory ManagementIn

trod

ucti

on

Operating Systems Prof. Dr. Werner Filip49

Some System Calls For Miscellaneous Tasks

Intr

oduc

tion

Operating Systems Prof. Dr. Werner Filip50

14.04.2016

26

System Calls

(a) File system before the mountIntr

oduc

tion

(b) File system after the mount

Operating Systems Prof. Dr. Werner Filip51

System Calls

Intr

oduc

tion

Some Win32 API calls

Operating Systems Prof. Dr. Werner Filip52

14.04.2016

27

Operating System Structure

Monolithic systems – basic structure:

• A main program that invokes the requested service procedure

Intr

oduc

tion

procedure.

• A set of service procedures that carry out the system calls.

• A set of utility procedures that help the service procedures.

Operating Systems Prof. Dr. Werner Filip53

Operating System Structure

Intr

oduc

tion

Structure of the THE operating system

Operating Systems Prof. Dr. Werner Filip54

Technical High School Eindhoven, E.W.Dijkstra 1968

14.04.2016

28

Operating System Structure In

trod

ucti

on

Structure of VM/370 with CMS

Operating Systems Prof. Dr. Werner Filip

VM/CMS (Virtual Machine / Conversational Monitor System) – IBM

55

Operating System Structure

Intr

oduc

tion

a type 1 hypervisor. a type 2 hypervisor.

Operating Systems Prof. Dr. Werner Filip56

hypervisor or virtual machine monitor (VMM) is a piece of computer software, firmware or hardware that creates and runs virtual machines

14.04.2016

29

Operating System Structure In

trod

ucti

on

The client-server model

Operating Systems Prof. Dr. Werner Filip57

Operating System Structure

Intr

oduc

tion

The client-server model in a distributed system

Operating Systems Prof. Dr. Werner Filip58

14.04.2016

1

Processes and Process Management

Chapter 2ge

men

t

Processes and Process Management

and

Pro

cess

Man

ag

Processes Threads Scheduling Interprocess communication (IPC)

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

p ( ) Deadlocks

1

Process Creation

Process – program in execution

gem

ent

Principal events that cause process creation

1. System initialization

2. Execution of a process creation system

3 U t t t

and

Pro

cess

Man

ag

3. User request to create a new process

4. Initiation of a batch job

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip2

14.04.2016

2

Process Termination

Conditions which terminate processes

gem

ent

1. Normal exit (voluntary)

2. Error exit (voluntary)

3. Fatal error (involuntary)

4. Killed by another process (involuntary)and

Pro

cess

Man

agP

roce

sses

Operating Systems Prof. Dr. Werner Filip3

Process Hierarchies

• Parent creates a child process, child processes can t itge

men

t

create its own process

• Forms a hierarchy– UNIX calls this a "process group“

• Windows has no concept of process hierarchyand

Pro

cess

Man

ag

Windows has no concept of process hierarchy– all processes are created equal

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip4

14.04.2016

3

The Process Model - Pseudoparallelismge

men

t

• All modern computers do many things at the same time

and

Pro

cess

Man

ag

• In a uni-processor system, at any instant, CPU is running only one process

• But in a multiprogramming system, CPU switches from processes quickly, running each for tens or

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip5

hundreds of ms

The Process Model

gem

ent

• Multiprogramming of four programs

and

Pro

cess

Man

ag

• Conceptual model of 4 independent, sequential processes

• Only one program active at any instantPro

cess

es

Operating Systems Prof. Dr. Werner Filip6

14.04.2016

4

Process States (1)ge

men

t Terminate

• Possible process states– runningan

d P

roce

ss M

anag

Create

g– blocked– ready

• Transitions between states shownPro

cess

es

Operating Systems Prof. Dr. Werner Filip7

Process States (2)

gem

ent

L t l f t t d OS

and

Pro

cess

Man

ag

• Lowest layer of process-structured OS– handles interrupts, scheduling

• Above that layer are sequential processesPro

cess

es

Operating Systems Prof. Dr. Werner Filip8

14.04.2016

5

Implementation of Processes (1)ge

men

tan

d P

roce

ss M

anag

Fields of a process table entry

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip9

Implementation of Processes (2)

gem

ent

and

Pro

cess

Man

agP

roce

sses

Operating Systems Prof. Dr. Werner Filip10

Skeleton of what lowest level of OS does when an interrupt occurs

14.04.2016

6

The Thread Model (1)ge

men

t

2 3

and

Pro

cess

Man

ag

(a) Three processes each with one thread(b) One process with three threads

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip11

The Thread Model (2)

gem

ent

and

Pro

cess

Man

ag

• Items shared by all threads in a process

• Items private to each thread

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip12

14.04.2016

7

The Thread Model (3)ge

men

tan

d P

roce

ss M

anag

Each thread has its own stackPro

cess

es

Operating Systems Prof. Dr. Werner Filip13

The Thread Model (4)

gem

ent

and

Pro

cess

Man

agP

roce

sses

Operating Systems Prof. Dr. Werner Filip14

14.04.2016

8

Thread Usage (1)ge

men

tan

d P

roce

ss M

anag

A word processor with three threadsPro

cess

es

Operating Systems Prof. Dr. Werner Filip15

Thread Usage (2)

gem

ent

and

Pro

cess

Man

ag

A multithreaded Web serverPro

cess

es

Operating Systems Prof. Dr. Werner Filip16

14.04.2016

9

Thread Usage (3)ge

men

tan

d P

roce

ss M

anag

Three ways to construct a server

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip17

Implementing Threads in User Space

gem

ent

and

Pro

cess

Man

ag

A user-level threads package

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip18

14.04.2016

10

Pop-Up Threadsge

men

tan

d P

roce

ss M

anag

• Creation of a new thread when message arrives(a) before message arrives(b) after message arrives

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip19

Making Single-Threaded Code Multithreaded (1)

gem

ent

and

Pro

cess

Man

ag

Conflicts between threads over the use of a global variableP

roce

sses

Operating Systems Prof. Dr. Werner Filip20

14.04.2016

11

Making Single-Threaded Code Multithreaded (2)ge

men

tan

d P

roce

ss M

anag

Threads can have private global variablesPro

cess

es

Operating Systems Prof. Dr. Werner Filip21

gem

ent

Concurrent Processing

• How can concurrent processing activity be structured on a single processor?

and

Pro

cess

Man

ag

• How can application-level information and system-level information be combined to provide efficient scheduling of processing activities?

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip22

14.04.2016

12

Introduction to Scheduling (1)ge

men

tan

d P

roce

ss M

anag

• Bursts of CPU usage alternate with periods of I/O wait– a CPU-bound process– an I/O bound processP

roce

sses

Operating Systems Prof. Dr. Werner Filip23

Introduction to Scheduling (2)

gem

ent

and

Pro

cess

Man

ag

Scheduling Algorithm Goals

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip24

14.04.2016

13

gem

ent Preemptive vs. Nonpreemptive Scheduling

• Preemptive processes

Introduction to Scheduling (3)an

d P

roce

ss M

anag – Can be removed from their current processor

– Can lead to improved response times

– Important for interactive environments

– Preempted processes remain in memory

• Nonpreemptive processes

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

– Run until completion or until they yield control of a processor

– Unimportant processes can block important ones indefinitely

25

gem

ent

First-Come-First-Served:

FCFS FIFO (Fi t I Fi t OUT)

Introduction to Scheduling (4)

and

Pro

cess

Man

ag FCFS same as FIFO (First-In-First-OUT)

Simple, fair, but poor performance. Average queueing time may be long.

What are the average queueing and residence/turnaround times for this scenario?

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

How do average queueing and residence times depend on ordering of these processes in the queue?

26

14.04.2016

14

gem

ent

Process Arrival Time Service Time

First-Come-First-Served (Nonpreemptive Scheduling)

Introduction to Scheduling (5)an

d P

roce

ss M

anag P1 0 7 sec

P2 2 4 sec

P3 4 1 sec

P4 5 3 sec

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

Schedule : P1; P2; P3; P4

27

gem

ent Time Diagram:

P1 P2 P4P3

Introduction to Scheduling (6)

and

Pro

cess

Man

ag 150 7 11 12

Average waiting time: sec75,44

19

4

7750

Average residence/turnaround time (waiting + processing):

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

sec5,84

34

4

10897

28

14.04.2016

15

gem

ent Shortest-Job-First (SJF)

Optimal for minimizing queueing time, but impossible to implement.

Introduction to Scheduling (7)an

d P

roce

ss M

anag Tries to predict the process to schedule based on previous history.

Predicting the time the process will use on its next schedule:

Process Arival Time Service TimeP1 0 7 secP2 2 4 secP3 4 1 sec

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

3

P4 5 3 sec Schedule : P1; P3; P4; P2

29

gem

ent Time Diagram:

150 7 8 11

P1 P2P4P3

Introduction to Scheduling (8)

and

Pro

cess

Man

ag Average waiting time:

sec75,34

15

4

9330

Average residence/turnaround time (waiting + processing):

sec5,73013647

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

,44

30

14.04.2016

16

gem

ent Determining Length of Next CPU Burst

Introduction to Scheduling (9)an

d P

roce

ss M

anag

• Cannot “know” which burst is shortest,

• … but we can make a reasonable guess

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip31

gem

ent • Predict by using the length of previous CPU bursts.

• This is called exponential averaging.

Introduction to Scheduling (10)

and

Pro

cess

Man

ag

1

1. actual length of CPU burst

2. stores the past history

3. predicted value for the next CPU burst

4. , 0 1

5 D fi

nth

n

n

nt

1t

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip32

5. Define: 1 1n n nt

14.04.2016

17

gem

ent • = 0

– n+1 = n

– Recent history does not count.

Introduction to Scheduling (11)an

d P

roce

ss M

anag

• = 1– n+1 = tn

– Only the actual last CPU burst counts.

• If we expand the formula, we get:n+1 = tn+ (1 - ) tn -1 + …

+ (1 ) j t +

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

+ (1 - ) j tn -1 + …+ (1 - ) n=1 tn 0

• and (1 - ) are <= 1, so each successive term has less weight than its predecessor.

33

gem

ent Example. (0 = 0, = 1/2):

Introduction to Scheduling (12)

and

Pro

cess

Man

ag

4

6

8

10

12

geschätzt

gemessenmeasured

predicted

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

0

2

0 1 2 3 4 5

34

14.04.2016

18

gem

ent Round Robin - Based on FIFO

• Processes run only for a limited time slice or quantum Must be preemptible

Introduction to Scheduling (13)an

d P

roce

ss M

anag

P2 P3 P4 Pn

Ready-Queue

newProcesses

Running“ for

Context switch overhead must be minimized

• Often used as part of more complex algorithms

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

P1

„Running fortime quantum

blocked or terminatedProcesses

35

Time Diagram:

150 10

P1 P2 P4P3

5

P1 P2 P1 P2 P1 P1 P1P4 P4P2

gem

ent

Introduction to Scheduling (14)

Round Robin Scheduling

Average waiting time:

sec75,04

3

4

2100

A id /t d ti ( iti + i )

150 105

and

Pro

cess

Man

ag

Process Arrival Time Service Time P1 0 7 sec P2 2 4 sec P3 4 1 sec P4 5 3 sec

Average residence/turnaround time (waiting + processing):

sec94

36

4

921015

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip36

14.04.2016

19

gem

ent

• Determines response time to interactive requests

Introduction to Scheduling (15)

Round Robin Scheduling

and

Pro

cess

Man

ag • Very large quantum size Processes run for long periods

Degenerates to FIFO

• Very small quantum size System spends most time context switching

• Compromise:

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

p Long enough for normal processes to issue I/O request

Batch processes still get majority of processor time

37

gem

ent

• Priority associated with each process

Priority Scheduling

Introduction to Scheduling (16)

and

Pro

cess

Man

ag

• CPU allocated to process with highest priority Preemptive or non-preemptive

Example - SJF: priority scheduling where priority is predicted next CPU burst time.

• Problem: Starvationlow priority processes may never execute

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

low priority processes may never execute.

• Solution: Aging

as time progresses increase the priority of the process.

38

14.04.2016

20

gem

ent

Introduction to Scheduling (17)an

d P

roce

ss M

anag

A scheduling algorithm with four priority classes

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip39

gem

ent Multilevel Queue

• Ready queue partitioned into separate queues:

Introduction to Scheduling (18)

and

Pro

cess

Man

ag

y q p p q– foreground (interactive) and background (batch)

• Each queue has its own scheduling algorithm, foreground – RR, background – FCFS

• Scheduling between queues.– Fixed priority scheduling; Possible starvation.

– Time slice: i e 80% to foreground in RR 20% to

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

Time slice: i.e., 80% to foreground in RR, 20% to background in FCFS

40

14.04.2016

21

Thread Scheduling (1)ge

men

tan

d P

roce

ss M

anag

Possible scheduling of user-level threads• 50-msec process quantum• threads run 5 msec/CPU burstP

roce

sses

Operating Systems Prof. Dr. Werner Filip41

Thread Scheduling (2)

gem

ent

and

Pro

cess

Man

ag

Possible scheduling of kernel-level threads• 50-msec process quantum• threads run 5 msec/CPU burst

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip42

14.04.2016

22

Interprocess Communication - Race Conditionsge

men

t /* Process A /* Process B Increase account by 100 */ Increase account by 200 */ i

and

Pro

cess

Man

ag int account; account=db_read("account X"); account=account+100; int account; account=db_read("account X"); account=account+200; db_write("account X",account); /* end Process B */

Switch over to Process B

Two processes want to access shared memory at same timePro

cess

es

Operating Systems Prof. Dr. Werner Filip

db_write("account X", account); /* end Process A */

43

Interprocess Communication - Race Conditions

gem

ent

A R C diti if t

and

Pro

cess

Man

ag A Race Condition occurs, if two or more processes/threads access and manipulate the same data concurrently, and the outcome of the execution depends on the particular order in which the access takes place.

A Critical Section/Region is a section of code in which a process accesses shared resources

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip44

which a process accesses shared resources.

14.04.2016

23

Critical Regions (1)

Four conditions to provide mutual exclusion

gem

ent

1. No two processes simultaneously in critical region

2. No assumptions made about speeds or numbers of CPUs

3. No process running outside its critical region may block another processan

d P

roce

ss M

anag

p

4. No process must wait forever to enter its critical region

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip45

Critical Regions (2)

gem

ent

and

Pro

cess

Man

ag

Mutual exclusion using critical regions

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip46

14.04.2016

24

Mutual Exclusion with Busy Waiting (1)ge

men

tan

d P

roce

ss M

anag

Proposed solution to critical region problem(a) Process 0. (b) Process 1.

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip47

Mutual Exclusion with Busy Waiting (2)

gem

ent

and

Pro

cess

Man

ag

Peterson's solution for achieving mutual exclusion

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip48

14.04.2016

25

Mutual Exclusion with Busy Waiting (3)ge

men

tan

d P

roce

ss M

anag

Entering and leaving a critical region using the TSL (test-and-set) instruction

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip49

Sleep and Wakeup

gem

ent

and

Pro

cess

Man

ag

Producer-consumer problem with fatal race conditionPro

cess

es

Operating Systems Prof. Dr. Werner Filip50

14.04.2016

26

Semaphores (1)ge

men

t Semaphore is a type of generalized lock

and

Pro

cess

Man

ag • Defined by Dijkstra in the last 60s• Main synchronization primitives used in UNIX• Consist of a positive integer value• Two operations

Originally called P( ) and V( ) (Prolaag and Verhoog)Also called down( ) and up( )

d ( ) i i h i f h

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip2 - 66

down( ): an atomic operation that waits for semaphore to become positive, then decrement it by 1

up( ): an atomic operation that increments semaphore by 1 and wakes up a waiting process or thread at down( ), if any.

51

gem

ent

Semaphores (2)

• No negative values• Only operations are down( ) and up( )

and

Pro

cess

Man

ag – Cannot read or write semaphore values– Except at the initialization times

• Operations are atomic– Two down( ) calls cannot decrement the value

below zero– A sleeping thread at down( ) cannot miss a wakeup

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

A sleeping thread at down( ) cannot miss a wakeup from up( )

52

14.04.2016

27

Semaphores (3)ge

men

tan

d P

roce

ss M

anag

The producer-consumer problem using semaphores

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip53

Monitors (1)

gem

ent

• Higher level construct than semaphores

• A package of grouped procedures, variables and data i.e. object oriented

and

Pro

cess

Man

ag oriented

• Processes call procedures within a monitor but cannot access internal data

• Can be built into programming languages (C++, Java, …)

• Synchronization enforced by the compiler

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip54

• Synchronization enforced by the compiler

• Only one process allowed within a monitor at one time

• wait and signal operations on condition variables

14.04.2016

28

Monitors (2)ge

men

tan

d P

roce

ss M

anag

Example of a monitor

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip55

Monitors (3)

gem

ent monitorProducerConsumer

condition full, empty; int count;count = 0;

d t ()

and

Pro

cess

Man

ag procedure enter();{

if (count == N) wait(full); // if buffer is full, block put_item(item); // put item in buffer count = count + 1; // increment count of full slots if (count == 1) signal(empty); // if buffer was empty, wake consumer

} procedure remove();{

if (count == 0) wait(empty); // if buffer is empty, block

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip56

( ) ( y) yremove_item(item); // remove item from buffer count = count - 1; // decrement count of full slots if (count == N-1) signal(full); // if buffer was full, wake producer

} end monitor;

14.04.2016

29

Monitors (4)ge

men

t

procedure Producer();{

while (TRUE) {

make_item(item); // make a new item ProducerConsumer enter; // call enter function in monitor

and

Pro

cess

Man

ag ProducerConsumer.enter; // call enter function in monitor }

}

procedure Consumer(); {

while (TRUE) {

ProducerConsumer.remove; // call remove function in monitor consume_item; // consume an item

}

• Outline of producer-consumer problem with monitors– only one monitor procedure active at one time– buffer has N slots

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip57

} }

Monitors (5)

gem

ent

and

Pro

cess

Man

ag

Solution to producer-consumer problem in Java (part 1)

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip58

14.04.2016

30

Monitors (6)ge

men

tan

d P

roce

ss M

anag

Solution to producer-consumer problem in Java (part 2)

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip59

Producer-consumer with message passing (1)

• Interprocess Communication– via shared memory

hi b d inage

men

t

– across machine boundaries

• Message passing can be used for synchronization or general communication

• Processes use send and receive primitives

and

Pro

cess

Man

60

– receive can block (like waiting on a Semaphore)

– send unblocks a process blocked on receive (just as a signal unblocks a waiting process)

Pro

cess

es a

Operating Systems Prof. Dr. Werner Filip2 - 66

14.04.2016

31

Producer-consumer with message passing (2)

• The basic idea:– After producing, the producer sends the data to

consumer in a message

nage

men

t

g– The system buffers messages

• The producer can out-run the consumer• The messages will be kept in order

– But how does the producer avoid overflowing the buffer?

• After consuming the data, the consumer sends back an “empty” messagean

d P

roce

ss M

an

61

“empty” message• Consumer starts by sending N empty messages

– A fixed number of messages (N=100)– The messages circulate back and forth.

Pro

cess

es a

Operating Systems Prof. Dr. Werner Filip2 - 66

gem

ent

Producer-consumer with message passing (3)

and

Pro

cess

Man

ag

The producer-consumer problem with N messages

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip62

14.04.2016

32

Design choices for message passing (1)

• Option 1: Mailboxes– System maintains a buffer of sent, but not yet received,

nage

men

t

y , y ,messages

– Must specify the size of the mailbox ahead of time

– Sender will be blocked if the buffer is full

– Receiver will be blocked if the buffer is empty

and

Pro

cess

Man

63

Pro

cess

es a

Operating Systems Prof. Dr. Werner Filip2 - 66

• Option 2: No buffering– If Send happens first, the sending thread blocks

nage

men

t

Design choices for message passing (2)

– If Receive happens first, the receiving thread blocks

– Sender and receiver must Rendezvous (ie. meet)

– Both threads are ready for the transfer

– The data is copied / transmitted

– Both threads are then allowed to proceed

and

Pro

cess

Man

64

Pro

cess

es a

Operating Systems Prof. Dr. Werner Filip2 - 66

14.04.2016

33

Dining Philosophers (1)ge

men

tan

d P

roce

ss M

anag

• Philosophers eat/think• Eating needs 2 forks• Pick one fork at a time • How to prevent deadlock

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip65

Dining Philosophers (2)

gem

ent

and

Pro

cess

Man

ag

A nonsolution to the dining philosophers problemPro

cess

es

Operating Systems Prof. Dr. Werner Filip66

14.04.2016

34

Dining Philosophers (3)ge

men

tan

d P

roce

ss M

anag

Solution to dining philosophers problem (part 1)Pro

cess

es

Operating Systems Prof. Dr. Werner Filip2 - 6667

Dining Philosophers (4)

gem

ent

and

Pro

cess

Man

ag

Solution to dining philosophers problem (part 2)

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip68

14.04.2016

35

The Readers and Writers Problemge

men

tan

d P

roce

ss M

anag

A solution to the readers and writers problem

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip69

The Sleeping Barber Problem (1)

gem

ent

and

Pro

cess

Man

agP

roce

sses

Operating Systems Prof. Dr. Werner Filip70

14.04.2016

36

The Sleeping Barber Problem (2)ge

men

tan

d P

roce

ss M

anag

Solution to sleeping barber problem.

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip71

Resources (1)

• Examples of computer resources– printers

t d igem

ent

– tape drives

– tables

• Processes need access to resources in reasonable order

• Suppose a process holds resource A and requests B

and

Pro

cess

Man

ag

resource B– at same time another process holds B and requests A

– both are blocked and remain soPro

cess

es

Operating Systems Prof. Dr. Werner Filip72

14.04.2016

37

Resources (2)

• Deadlocks occur when …– processes are granted exclusive access to devices

gem

ent

– we refer to these devices generally as resources

• Preemptable resources– can be taken away from a process with no ill effects

• Nonpreemptable resources– will cause the process to fail if taken awayan

d P

roce

ss M

anag

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip73

Resources (3)

• Sequence of events required to use a resource1. request the resource

gem

ent

2. use the resource

3. release the resource

• Must wait if request is denied– requesting process may be blocked

and

Pro

cess

Man

ag

74

– may fail with error code

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

14.04.2016

38

Introduction to Deadlocks

• Formal definition:

• A set of processes is deadlocked if each process in the set is waiting for an event that only another process inge

men

t

set is waiting for an event that only another process in the set can cause

• Usually the event is release of a currently held resource

N f thand

Pro

cess

Man

ag

• None of the processes can …– run

– release resources

– be awakened

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip75

Four Conditions for Deadlock

1. Mutual exclusion condition• each resource assigned to one process or is available

Hold and wait conditiongem

ent

2. Hold and wait condition• process holding resources can request additional

resources

3. No preemption condition• previously granted resources cannot forcibly taken

away

and

Pro

cess

Man

ag

4. Circular wait condition• must be a circular chain of two or more processes• each is waiting for resource held by next member of

the chain

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip76

14.04.2016

39

Deadlock Modeling (1)

• Modeled with directed graphs

gem

ent

) i d A

and

Pro

cess

Man

ag

a) resource R assigned to process A

b) process B is requesting/waiting for resource S

c) process C and D are in deadlock over resources T and U

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip77

Deadlock Modeling (2)

Strategies for dealing with Deadlocks

1. just ignore the problem altogethergem

ent

1. just ignore the problem altogether

2. detection and recovery

3. dynamic avoidance• careful resource allocation

4. prevention ti f th f ditian

d P

roce

ss M

anag

• negating one of the four necessary conditions

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip78

14.04.2016

40

A B C

Deadlock Modeling (3)ge

men

tan

d P

roce

ss M

anag

How deadlock occursPro

cess

es

Operating Systems Prof. Dr. Werner Filip79

Deadlock Modeling (4)

gem

ent

and

Pro

cess

Man

ag

How deadlock can be avoided(o) (p) (q)P

roce

sses

Operating Systems Prof. Dr. Werner Filip80

14.04.2016

41

m Resource classes A1, ..., Am

R i i t E ( )gem

ent

Deadlock Detection Algorithm (1)

Data structures needed by deadlock detection algorithm

Resources in existence E = (e1, ..., em) ei - resources of class Ai

n Processes P1, ..., Pn Current allocation matrix (nm-matrix)

ij

m

c

cc

C ......

... 111

and

Pro

cess

Man

ag

cij - current number of resources of class Aj, allocated to process Pi

nmn

ij

cc ...1

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip81

gem

ent

Deadlock Detection Algorithm (2)

Availability vector A = (a1, ..., am) ai - number of unallocated resources of class Ai

n

cea

and

Pro

cess

Man

ag

j

ijii cea1

Request matrix rij - number of resources of class Aj

requested by process Pi

ij

m

r

rr

R ......

... 111

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

nmn rr ...1

82

Deadlock detection algorithm is based onComparison relation of vectors „ “:V W : for i = 1, 2, ..., m : vi wi .

14.04.2016

42

Deadlock Detection Algorithm (3)ge

men

t Deadlock detection algorithm:

1. Look for an unmarked process, Pi , for which the

and

Pro

cess

Man

ag i-th row of R is less than or equal to A.

2. If such a process is found, add the i-th row of C to A, mark the process, and go back to step 1.

3. If no such process exists, the algorithm terminates.

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

4. We have a deadlock situation if there areunmarked processes.

83

Deadlock Detection Algorithm (4)

gem

ent

and

Pro

cess

Man

ag

An example for the deadlock detection algorithmPro

cess

es

Operating Systems Prof. Dr. Werner Filip84

14.04.2016

43

Deadlock Detection Algorithm (5)ge

men

t Example

1. P3 can only be marked. Unallocated resources will be added to V

and

Pro

cess

Man

ag A1 = ( 2 1 0 0 ), R3 A1 → A2 = A1 + C3

A2 = ( 2 2 2 0 ) = ( 2 1 0 0 ) + ( 0 1 2 0 )

2. P2 can now be marked. Related unallocated resources will be added to V.

R2 A2 → A3 = A2 + C2

A3 = ( 4 2 2 1 ) = ( 2 2 2 0 ) + (2 0 0 1)

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip

3 ( ) ( ) ( )

3. Finally, P1 can be marked. That means, there is no deadlock situation.

R1 A3 → A4 = A3 + C1

A4 = ( 4 2 3 1 ) = ( 4 2 2 1 ) + (0 0 1 0)

85

Recovery from Deadlock (1)

• Recovery through preemption– take a resource from some other processge

men

t

p

– depends on nature of the resource

• Recovery through rollback– checkpoint a process periodically

– use this saved state

– restart the process if it is found deadlockedand

Pro

cess

Man

ag

p

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip86

14.04.2016

44

Recovery from Deadlock (2)

• Recovery through killing processes– crudest but simplest way to break a deadlock

gem

ent

– kill one of the processes in the deadlock cycle

– the other processes get its resources

– choose process that can be rerun from the beginning

and

Pro

cess

Man

agP

roce

sses

Operating Systems Prof. Dr. Werner Filip87

Attacking the Mutual Exclusion Condition

• Some devices (such as printer) can be spooled– only the printer daemon uses printer resourcege

men

t

y p p– thus deadlock for printer eliminated

• Not all devices can be spooled• Principle:

– avoid assigning resource when not absolutely necessary

f ibl t ll l i th

and

Pro

cess

Man

ag

– as few processes as possible actually claim the resource

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip88

14.04.2016

45

Attacking the Hold and Wait Condition

• Require processes to request resources before starting– a process never has to wait for what it needsge

men

t

a process never has to wait for what it needs

• Problems– may not know required resources at start of run– also ties up resources other processes could be using

and

Pro

cess

Man

ag

• Variation – process must give up all resources– then request all immediately neededP

roce

sses

Operating Systems Prof. Dr. Werner Filip89

Attacking the No Preemption Condition

• This is not a viable option

• Consider a process given the printergem

ent

p g p– halfway through its job

– now forcibly take away printer

– !!??

and

Pro

cess

Man

agP

roce

sses

Operating Systems Prof. Dr. Werner Filip90

14.04.2016

46

Attacking the Circular Wait Conditionge

men

t

(a) (b)

and

Pro

cess

Man

ag

• Normally ordered resources

• A resource graph

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip91

Summary – Deadlock Prevention

gem

ent

and

Pro

cess

Man

ag

Summary of approaches to deadlock prevention

Pro

cess

es

Operating Systems Prof. Dr. Werner Filip92

14.04.2016

47

Nonresource Deadlocks

• Possible for two processes to deadlock– each is waiting for the other to do some taskge

men

t

each is waiting for the other to do some task

• Can happen with semaphores– each process required to do a down() on two

semaphores (mutex and another)

– if done in wrong order, deadlock results

and

Pro

cess

Man

agP

roce

sses

Operating Systems Prof. Dr. Werner Filip93

14.04.2016

1

Chapter 3nt

Memory Management

mor

y M

anag

emen

Mem

Operating Systems Prof. Dr. Werner Filip 1

Memory Management

• Ideally programmers want memory that is– large

nt

– fast

– non volatile

• Memory hierarchy – small amount of fast, expensive memory – cache

mor

y M

anag

emen

– some medium-speed, medium price main memory

– gigabytes of slow, cheap disk storage

• Memory manager handles the memory hierarchy

Mem

Operating Systems Prof. Dr. Werner Filip 2

14.04.2016

2

Basic Memory Managementnt

mor

y M

anag

emen

Three simple ways of organizing memory- an operating system with one user process

Mem

Operating Systems Prof. Dr. Werner Filip 3

RAM – Random-Access Memory ROM – Read-Only Memory

Multiprogramming with Fixed Partitions

ntm

ory

Man

agem

en

• Fixed memory partitions– separate input queues for each partition– single input queue

Mem

Operating Systems Prof. Dr. Werner Filip 4

14.04.2016

3

Swapping (1)nt

mor

y M

anag

emen

Memory allocation changes as – processes come into memory– leave memory

Shaded regions are unused memory

Mem

Operating Systems Prof. Dr. Werner Filip 5

Swapping (2)

ntm

ory

Man

agem

en

a) Allocating space for growing data segmentb) Allocating space for growing stack & data

segment

Mem

Operating Systems Prof. Dr. Werner Filip 6

14.04.2016

4

Memory Management with Bit Mapsnt

a) Part of memory with 5 processes, 3 holesi k k h ll i im

ory

Man

agem

en

– tick marks show allocation units– shaded regions are free

b) Corresponding bit mapc) Same information as a list

Mem

Operating Systems Prof. Dr. Werner Filip 7

Dynamic Storage Allocation

• Algorithms for Allocation

Fi t Fitnt – First-Fit

– Best-Fit

– Worst-Fit

mor

y M

anag

emen

Mem

Operating Systems Prof. Dr. Werner Filip 8

14.04.2016

5

Dynamic Storage-Allocation Problem

How to satisfy a request of size n from a list of free holes?

• First Fit: Allocate the first hole that is big enoughnt • First-Fit: Allocate the first hole that is big enough.

• Best-Fit: Allocate the smallest hole that is big enough; must search entire list, unless ordered by size. Produces the smallest leftover hole.

• Worst-Fit: Allocate the largest hole; must also search

mor

y M

anag

emen

entire list. Produces the largest leftover hole.

Mem

Operating Systems Prof. Dr. Werner Filip 9

First-Fit and Best-Fit better than Worst-Fit in terms of speed and storage utilization.

Best-Fit vs. First-Fit

nt

• Memory sizes (holes) 1300 and 1200

• Requests: 1100, 1050, 250

mor

y M

anag

emen

– Request First-Fit Best-Fit

– 1300, 1200 1300, 1200

– 1100 200, 1200 1300, 100

– 1050 200, 150 250, 100

Mem

Operating Systems Prof. Dr. Werner Filip10

– 250 --- 0, 100

14.04.2016

6

ntLogical vs. Physical Address Space

• The concept of a logical address space that is bound to a separate physical address space is central to proper memory management

mor

y M

anag

emen central to proper memory management

– Logical address – generated by the CPU; also referred to as virtual address

– Physical address – address seen by the memory unit

• Logical and physical addresses are the same in

Mem

Operating Systems Prof. Dr. Werner Filip

compile-time and load-time address-binding schemes; logical (virtual) and physical addresses differ in execution-time address-binding scheme

11

nt

Memory-Management Unit (MMU)

• Hardware device that maps virtual to physical address

mor

y M

anag

emen

• In MMU scheme, the value in the relocation register is added to every address generated by a user process at the time it is sent to memory

• The user program deals with logical addresses;

Mem

Operating Systems Prof. Dr. Werner Filip

• The user program deals with logical addresses; it never sees the real physical addresses

12

14.04.2016

7

Virtual Memory - Paging nt

mor

y M

anag

emen

The position and function of the MMU

Mem

Operating Systems Prof. Dr. Werner Filip13

Paging

nt

• Logical address space of a process can be noncontiguous; process is allocated physical memory whenever the latter is available

mor

y M

anag

emen memory whenever the latter is available

• Divide physical memory into fixed-sized blocks called frames (size is power of 2, between 512 bytes and 8,192 bytes)

Mem

Operating Systems Prof. Dr. Werner Filip

• Divide logical memory into blocks of same size called pages

14

14.04.2016

8

Pagingnt

• Keep track of all free frames

mor

y M

anag

emen

• To run a program of size n pages, need to find nfree frames and load program

• Set up a page table to translate logical to physical addresses

Mem

Operating Systems Prof. Dr. Werner Filip

• Internal fragmentation

15

Paging

• Address generated by CPU divided into:– Page number (p) - index to page table

• page table contains base address of each page innt page table contains base address of each page in physical memory (frame)

– Page offset (d) - offset into page/frame

mor

y M

anag

emen

CPU p d f d

h i l

Mem

Operating Systems Prof. Dr. Werner Filip

page table

f

physicalmemory

16

14.04.2016

9

nt

7 6 5 4 3

15

14

13

12

11

60-64 K

56-60 K

52-56 K

48-52 K

44-48 K

28-32 K

24-28 K

20-24 K

16-20 K

12-16 K

Example

Paging Examplem

ory

Man

agem

en

20-24 K

16-20 K

12-16 K

8-12 K

4-8 K

2 1 0

10 9 8

7 6 5 4 3 2 1

40-44 K . . .

8-12 K

4-8 K

0-4 K

allocated frames

• logical 16-Bit-Adresses, • 64 KB logical address space• memory 32 KB• page/frame size 4 KB, • 16 logical pages, 8 frames

Mem

Operating Systems Prof. Dr. Werner Filip

0-4 K 0

Logical address 8 300 (= 8K + 108) mapped to physical address (24K + 108 =) 24 684

17

nt

access to logical address 8300

Paging Example

8 300 = ( 0010 0000 0110 1100 )2 ( 110 0000 0110 1100 )2 = 24 684

mor

y M

anag

emen 8 300 ( 0010 0000 0110 1100 )2 ( 110 0000 0110 1100 )2 24 684

. . .

1 0 0

. . .

1

P/A-Bit

1514

Mem

Operating Systems Prof. Dr. Werner Filip18

1 1 0

0 1 0

0 1 0

0

1

1

210

14.04.2016

10

Page Tables (1)nt

mor

y M

anag

emen

Internal operation of MMU with 16 4 KB pages

Mem

Operating Systems Prof. Dr. Werner Filip19

Page Tables (2)Second-level page tables

nt

Top-level page table

mor

y M

anag

emen

• 32 bit address with 2 page table fields

• Two-level page tables

Mem

Operating Systems Prof. Dr. Werner Filip20

Toframes

14.04.2016

11

nt

Access to logical address 4.206.596

Page Tables (3)

mor

y M

anag

emen

0 0 4 0 3 0 0 4 (hex) 0000 0000 0100 0000 0011 0000 0000 0100 (bin) 222

213 212

22 4.206.596 = 4.194.304 + 8192 + 4096 + 4 (dec) PT1 = 1 PT2 = 3 Offset = 4

Mem

Operating Systems Prof. Dr. Werner Filip21

10 Bit PT1 10 Bit PT2 12 Bit Offset → 220 4 KB pages

→ 210 * 210

* 212 = 2

32 = 4 GB

Page Tables (4)

ntm

ory

Man

agem

en

Typical page table entryMem

Operating Systems Prof. Dr. Werner Filip22

14.04.2016

12

TLBs – Translation Lookaside Buffersnt

mor

y M

anag

emen

23

A TLB to speed up paging

Mem

Operating Systems Prof. Dr. Werner Filip

Page Replacement Algorithms

• Page fault forces choice – which page must be removednt p g

– make room for incoming page

• Modified page must first be saved– unmodified just overwritten

mor

y M

anag

emen

• Better not to choose an often used page– will probably need to be brought back in soon

Mem

Operating Systems Prof. Dr. Werner Filip24

14.04.2016

13

Optimal Page Replacement Algorithm

• Replace page needed at the farthest point in futureOptimal but unrealizablent – Optimal but unrealizable

• Estimate by …– logging page use on previous runs of process

– although this is impractical

mor

y M

anag

emen

Mem

Operating Systems Prof. Dr. Werner Filip 25

nt

Optimal Page Replacement Algorithm

Example.: Assumption: 5 Pages und 3 Frames

mor

y M

anag

emen

Reference String: 0 1 2 3 0 1 4 0 1 2 3 4 Memory: 0 0 0 0 0 0 0 0 0 2 3 3 1 1 1 1 1 1 1 1 1 1 1 2 3 3 3 4 4 4 4 4 4 P P P P P P PReplaced Page 2 3 0 2

Mem

Operating Systems Prof. Dr. Werner Filip

Result: 7 Page Faults, 4 replaced pages

26

14.04.2016

14

Not Recently Used Page Replacement Algorithm

• Each page has Reference bit ( R ), Modified bit ( M )nt

– bits are set when page is referenced, modified

• Pages are classified– R=0, M=0 Class 0

– R=0, M=1 Class 1

– R=1, M=0 Class 2

– R=1 M=1 Class 3mor

y M

anag

emen

R 1, M 1 Class 3

• NRU removes page at random– from lowest numbered class

Mem

Operating Systems Prof. Dr. Werner Filip27

FIFO Page Replacement Algorithm

nt

First-In-First-Out (FIFO) Remove the page brought in the longest time ago.

mor

y M

anag

emen Reference String: 0 1 2 3 0 1 4 0 1 2 3 4

Memory: 0 0 0 3 3 3 4 4 4 4 4 4 1 1 1 0 0 0 0 0 2 2 2 2 2 2 1 1 1 1 1 3 3

P P P P P P P P PReplaced Page 0 1 2 3 0 1

Mem

Operating Systems Prof. Dr. Werner Filip

Result: 9 Page Faults, 6 replaced pages

28

14.04.2016

15

Belady's Anomalynt

mor

y M

anag

emen

• FIFO with 3 page frames• FIFO with 4 page frames• P's show which page references show page faults

Mem

Operating Systems Prof. Dr. Werner Filip29

FIFO Page Replacement Algorithm

nt

• FIFO is an obvious algorithm and simple to implement.

• Basic idea, maintain a list or queue of pages in the order in which they were paged into memory.

mor

y M

anag

emen they were paged into memory.

• On replacement, remove the one brought in the longest time ago.

• Why might it work? – Maybe the one brought in the longest ago is one we’re not using now.

• Why it might not work? – Maybe it’s not.

Mem

Operating Systems Prof. Dr. Werner Filip

– We have no real information to tell us if it’s being used or not.

• FIFO suffers from “Belady’s anomaly” – the fault rate might actually increase when the algorithm is given more memory -

- a bad property.

30

14.04.2016

16

Second Chance Page Replacement Algorithmnt

Second-Chance

Extension of FIFO

mor

y M

anag

emen „oldest“ page won't be replaced, if related R-Bit is set

Reference String: 0 1 2 3 0 1 4 0 1 2 3 4 Memory: 0 0 0 3 3 3 4 4 4 4 4 4 1 1 1 0 0 0 0 0 2 2 2

2 2 2 1 1 1 1 1 3 3

Mem

Operating Systems Prof. Dr. Werner Filip31

2 2 2 1 1 1 1 1 3 3 P P P P P P P P PReplaced Page

0 1 2 3 0 1

Result: 9 Page Faults, 6 replaced pages

Least Recently Used (LRU)

• Assume pages used recently will used again soon– throw out page that has been unused for longest time

nt

• Must keep a linked list of pages– most recently used at front, least at rear– update this list every memory reference !!

• Alternatively keep counter in each page table entrymor

y M

anag

emen

Alternatively keep counter in each page table entry– choose page with lowest value counter– periodically zero the counter

Mem

Operating Systems Prof. Dr. Werner Filip32

14.04.2016

17

nt

Least-Recently-Used (LRU) Reference String: 0 1 2 3 0 1 4 0 1 2 3 4

Least Recently Used (LRU)m

ory

Man

agem

en Reference String: 0 1 2 3 0 1 4 0 1 2 3 4 Memory: 01 02 03 31 32 33 41 42 43 21 22 23

11 12 13 01 02 03 01 02 03 31 32

21 22 23 11 12 13 11 12 13 41

P P P P P P P P P PReplaced Page 0 1 2 3 4 0 1 R lt 10 P F lt 7 l d

Mem

Operating Systems Prof. Dr. Werner Filip

Result: 10 Page Faults, 7 replaced pages

33

Simulating LRU in Software

ntm

ory

Man

agem

en

• The aging algorithm simulates LRU in software• Note 6 pages for 5 clock ticks, (a) – (e)

Mem

Operating Systems Prof. Dr. Werner Filip34

14.04.2016

18

Review of Page Replacement Algorithmsnt

• Optimal Not implementable, but useful as a benchmark

• NRU (Not Recently Used)

mor

y M

anag

emen

( y ) Very crude

• FIFO (First-In, First-Out) Might throw out important page

• Second chance Big improvement over FIFO

• LRU (Least recently Used)

Mem

Operating Systems Prof. Dr. Werner Filip

Excellent but difficult to implement exactly

• Aging Efficient algorithm that approximates LRU well

35

Page Size

Small page size• Advantagesnt g

– less internal fragmentation

– better fit for various data structures, code sections

– less unused program in memory

• Disadvantages– programs need many pages, larger page tables

mor

y M

anag

emen

Mem

Operating Systems Prof. Dr. Werner Filip36

14.04.2016

19

Cleaning Policy

• Need for a background process, paging daemoni di ll i t t t fnt – periodically inspects state of memory

• When too few frames are free– selects pages to replace using a replacement algorithm

mor

y M

anag

emen

Mem

Operating Systems Prof. Dr. Werner Filip37

Operating System Involvement with Paging

Four times when OS involved with paging1. Process creation

determine program sizent determine program size create page table

2. Process execution MMU reset for new process TLB flushed

3. Page fault time

mor

y M

anag

emen

determine virtual address causing fault swap target page out, needed page in

4. Process termination time release page table, pages

Mem

Operating Systems Prof. Dr. Werner Filip38

14.04.2016

20

Backing Storent

mor

y M

anag

emen

(a) Paging to static swap area(b) Backing up pages dynamically

Mem

Operating Systems Prof. Dr. Werner Filip39

Segmentation (1)

nt

A compiler has many tables that are built up as compilation proceeds, possibly including:

mor

y M

anag

emen

• The source text being saved for the printed listing (on batch systems).

• The symbol table – the names and attributes of variables.

• The table containing integer, floating-point constants used.

Mem

Operating Systems Prof. Dr. Werner Filip40

• The parse tree, the syntactic analysis of the program.

• The stack used for procedure calls within the compiler.

14.04.2016

21

Segmentation (2)nt

mor

y M

anag

emen

• One-dimensional address space with growing tables• One table may bump into another

Mem

Operating Systems Prof. Dr. Werner Filip41

Segmentation (3)

ntm

ory

Man

agem

en

Allows each table to grow or shrink, independently

Mem

Operating Systems Prof. Dr. Werner Filip42

14.04.2016

22

Segmentation (4)nt

mor

y M

anag

emen

Comparison of paging and segmentation

Mem

Operating Systems Prof. Dr. Werner Filip43

Implementation of Pure Segmentation

ntm

ory

Man

agem

en

(a) - (d) Development of checkerboarding(e) Removal of the checkerboarding by compaction

Mem

Operating Systems Prof. Dr. Werner Filip44

14.04.2016

1

Chapter 4

File Systems

Fil

e S

yste

ms

Operating Systems Prof. Dr. Werner Filip1

Long-term Information Storage

1. Must store large amounts of data

2. Information stored must survive the termination of the process using it

3 Multiple processes must be able toFil

e S

yste

ms

3. Multiple processes must be able to access the information concurrently

Operating Systems Prof. Dr. Werner Filip2

14.04.2016

2

File NamingF

ile

Sys

tem

s

Typical file extensions.

Operating Systems Prof. Dr. Werner Filip3

File Structure

Fil

e S

yste

ms

• Three kinds of files– byte sequence– record sequence– tree

Operating Systems Prof. Dr. Werner Filip4

14.04.2016

3

File TypesF

ile

Sys

tem

s

(a) An executable file (b) An archiveOperating Systems Prof. Dr. Werner Filip

5

File Access

• Sequential access– read all bytes/records from the beginning

cannot jump around could rewind or back up– cannot jump around, could rewind or back up

– convenient when medium was magnetic tape

• Random access– bytes/records read in any order

– essential for data base systems

– read can beFil

e S

yste

ms

– read can be …• move file marker (seek), then read or …

• read and then move file marker

Operating Systems Prof. Dr. Werner Filip6

14.04.2016

4

File AttributesF

ile

Sys

tem

s

Possible file attributesOperating Systems Prof. Dr. Werner Filip

7

File Operations

1. Create 7. Append

8 S k2. Delete

3. Open

4. Close

5. Read

8. Seek

9. Get attributes

10. Set Attributes

11. Rename

Fil

e S

yste

ms

6. Write

Operating Systems Prof. Dr. Werner Filip8

14.04.2016

5

Single-Level Directory Systems

• A single level directory systemFil

e S

yste

ms

– contains 4 files– owned by 3 different people, A, B, and C

Operating Systems Prof. Dr. Werner Filip9

Two-level Directory Systems

Fil

e S

yste

ms

Letters indicate owners of the directories and files

Operating Systems Prof. Dr. Werner Filip10

14.04.2016

6

Hierarchical Directory SystemsF

ile

Sys

tem

s

A hierarchical directory system

Operating Systems Prof. Dr. Werner Filip11

Path Names

Fil

e S

yste

ms

A UNIX directory tree

Operating Systems Prof. Dr. Werner Filip12

14.04.2016

7

Directory Operations

1. Delete 5. Readdir

2. Opendir

3. Closedir

4. Create

6. Rename

7. Link

8. Unlink

Fil

e S

yste

ms

Operating Systems Prof. Dr. Werner Filip13

File System Implementation

Fil

e S

yste

ms

A possible file system layout

MBR – Master Boot Record

Operating Systems Prof. Dr. Werner Filip14

14.04.2016

8

Implementing Files (1)F

ile

Sys

tem

s

(a) Contiguous allocation of disk space for 7 files(b) State of the disk after files D and F have been removed

Operating Systems Prof. Dr. Werner Filip15

Implementing Files (2)

Fil

e S

yste

ms

Storing a file as a linked list of disk blocks

Operating Systems Prof. Dr. Werner Filip16

14.04.2016

9

Implementing Files (3)F

ile

Sys

tem

s

Linked list allocation using a file allocation table in RAM

Operating Systems Prof. Dr. Werner Filip17

Implementing Files (4)

Fil

e S

yste

ms

An example I-node

Operating Systems Prof. Dr. Werner Filip18

14.04.2016

10

Implementing Directories

(a) A simple directoryFil

e S

yste

ms

(a) A simple directoryfixed size entriesdisk addresses and attributes in directory entry

(b) Directory in which each entry just refers to an I-node

Operating Systems Prof. Dr. Werner Filip19

Shared Files (1)

Fil

e S

yste

ms

File system containing a shared fileOperating Systems Prof. Dr. Werner Filip

20

14.04.2016

11

Shared Files (2)F

ile

Sys

tem

s

(a) Situation prior to linking

(b) After the link is created

(c) After the original owner removes the file

Operating Systems Prof. Dr. Werner Filip21

Shared Files (3)

Two directory entries pointing to the same I-Node

Hard Link

Fil

e S

yste

ms

y p g

name2

I-Node 100 Directory Entries

name1

100

100

.

.

.

Operating Systems Prof. Dr. Werner Filip22

14.04.2016

12

Shared Files (4)

Pathname of the original file stored in a separate file.

Soft Link

Fil

e S

yste

ms

name2

I-Node 200 I-Node 100 Directory Entries

name1

200

100

.

.

.

.

.

/home/filip/ work/name1

Operating Systems Prof. Dr. Werner Filip23

.

Free-Space Management (1)

• Bitmap– Very compact on disk

Expensive to search

Fil

e S

yste

ms

– Expensive to search

– Supports contiguous allocation

• Free list– Linked list of free blocks

• Each block contains pointer to next free block

Operating Systems Prof. Dr. Werner Filip

p

– Only head of list needs to be cached in memory

– Very fast to search and allocate

– Contiguous allocation very difficult

24

14.04.2016

13

Free-Space Management (2)

• Bit vector (n blocks)

0 1 2 n-1

bit[i] =

0 block[i] free

1 block[i] occupied

Fil

e S

yste

ms

Operating Systems Prof. Dr. Werner Filip25

Free-Space Management (3)

Fil

e S

yste

ms

(a) Storing the free list on a linked list(b) A bit map

Operating Systems Prof. Dr. Werner Filip26

14.04.2016

14

Free-Space Management (4)

• Bit map requires extra space

– Example:

block size = 212 bytes

disk size = 230 bytes (1 gigabyte)

n = 230/212 = 218 bits (or 32K bytes)

• Easy to get contiguous files

Fil

e S

yste

ms

• Linked list (free list)

– Cannot get contiguous space easily

– No waste of space

Operating Systems Prof. Dr. Werner Filip27

Free-Space Management (5)

• Need to protect:

– Pointer to free list

– Bit map• Must be kept on disk• Copy in memory and disk may differ• Cannot allow for block[i] to have a situation where bit[i] = 1 in

memory and bit[i] = 0 on disk

– Solution:Fil

e S

yste

ms

Solution:• Set bit[i] = 1 in disk• Allocate block[i]• Set bit[i] = 1 in memory

Operating Systems Prof. Dr. Werner Filip28

14.04.2016

15

Free-Space Management (6)

• Linked list of free blocks– Not necessarily in order!

• Cache first few free blocks

Fil

e S

yste

ms

Cache first few free blocks in memory

• Head of list must be stored both– On disk– In memory

Operating Systems Prof. Dr. Werner Filip

• Each block must be written to disk when freed

29

File System Performance

Fil

e S

yste

ms

a) I-nodes placed at the start of the diskb) Disk divided into cylinder groups

– each with its own blocks and I-nodes

Operating Systems Prof. Dr. Werner Filip30

14.04.2016

16

CD-ROM File Systems

Bytes

Fil

e S

yste

ms

y

The ISO 9660 directory entry

Operating Systems Prof. Dr. Werner Filip31

The MS-DOS File System

Fil

e S

yste

ms

The MS-DOS directory entry

Operating Systems Prof. Dr. Werner Filip32

14.04.2016

17

The MS-DOS File SystemF

ile

Sys

tem

s

• Maximum partition for different block sizes• The empty boxes represent forbidden combinations• FAT - File Allocation Table

Operating Systems Prof. Dr. Werner Filip33

The Windows 98 File System

Bytes

Th t d d MOS DOS

Fil

e S

yste

ms

The extended MOS-DOS

directory entry used in Windows 98

Operating Systems Prof. Dr. Werner Filip34

14.04.2016

18

The UNIX V7 File System F

ile

Sys

tem

s

UNIX V7 directory entry

Operating Systems Prof. Dr. Werner Filip35

The UNIX V7 File System

boot

II--nodesnodes blocksblocks

Fil

e S

yste

ms

link count

uid

gid

size

addresses of first10 blocks

UNIX I-node

Operating Systems Prof. Dr. Werner Filip36

single indirect block

double indirect block

triple indirect block

14.04.2016

19

The UNIX V7 File System

size

addresses of first10 blocks

Fil

e S

yste

ms

single indirect block

double indirect block

triple indirect block

UNIX I-node

Operating Systems Prof. Dr. Werner Filip37

The UNIX V7 File System

Fil

e S

yste

ms

The steps in looking up /usr/ast/mbox

Operating Systems Prof. Dr. Werner Filip38

14.04.2016

20

Goals of Protection

• Operating system consists of a collection of objects

Protection and Security (1)F

ile

Sys

tem

s

(hardware or software)

• Each object has a unique name and can be accessed through a well-defined set of operations.

• Protection problem – to ensure that each object is

Operating Systems Prof. Dr. Werner Filip39

p jaccessed correctly and only by those processes that are allowed to do so.

Guiding Principles of Protection

Protection and Security (2)

• Principle of least privilege

Fil

e S

yste

ms

• Principle of least privilege– Programs, users and systems should be given just

enough privileges to perform their tasks

• Separate policy from mechanismMechanism: the stuff built into the OS to make

Operating Systems Prof. Dr. Werner Filip40

– Mechanism: the stuff built into the OS to make protection work

– Policy: the data that says who can do what to whom

14.04.2016

21

Protection and Security (3)

Domain Structure

• Access-right = <object-name, rights-set>where rights set is a subset of all valid operations that can

Fil

e S

yste

ms

where rights-set is a subset of all valid operations that can be performed on the object.

• Domain = set of access-rights

Operating Systems Prof. Dr. Werner Filip41

Protection and Security (4)

Conceptual Representation – Access Matrix

• View protection as a matrix (access matrix)

Fil

e S

yste

ms • Rows represent domains

• Columns represent objects

• Access(i, j) defines a set of operations that a i i D i k

Operating Systems Prof. Dr. Werner Filip42

process, executing in Domaini, can invoke on Objectj

14.04.2016

22

Protection and Security (5)

Access Matrix

Fil

e S

yste

ms

Operating Systems Prof. Dr. Werner Filip43

• Columns are access control lists (ACLs)• Associated with each object

• Rows are capabilities• Associated with each user, group, or domain

Protection and Security (6)

Unix & Linux

Fil

e S

yste

ms

• System comprises many domains: – Each user

– Each group

– Kernel/System

Operating Systems Prof. Dr. Werner Filip44

• (Windows has even more domains than this!)

14.04.2016

23

Protection and Security (6)

Unix & Linux

• Each file has owner and group

Fil

e S

yste

ms • Permissions set by owner

– read, write, execute

– owner, group, other

• Only owner, root can change permissions– This privilege cannot be delegated or shared

rwx rwxrwx

owner group other

Operating Systems Prof. Dr. Werner Filip45

p g g

• Set-user-id bits

Protection and Security (7)

Unix/Linux Matrix

file1 file 2 file 3 device domain

Fil

e S

yste

ms User/Domain 1 r rx rwx – enter

User/Domain 2 r x rx rwx –

User/Domain 3 rw – – – –

Operating Systems Prof. Dr. Werner Filip46

• Columns are access control lists (ACLs)• Associated with each object

• Rows are capabilities• Associated with each user or each domain

14.04.2016

24

Practicalities

• At run-time…Wh t d th OS k b t th ?

Protection and Security (8)F

ile

Sys

tem

s

– What does the OS know about the user?

– What does the OS know about the resources?

• What is the cost of checking and enforcing?– Access to the data

– Cost of searching for a match

Operating Systems Prof. Dr. Werner Filip47

• Impractical to implement full Access Matrix– Size

– Access controls disjoint from both objects and domains

Protection and Security (9)

Access Control Lists

Fil

e S

yste

ms

Operating Systems Prof. Dr. Werner Filip48

Use of access control lists of manage file access

14.04.2016

25

Protection and Security (10)

Capabilities

Fil

e S

yste

ms

Operating Systems Prof. Dr. Werner Filip49

Each process has a capability list

ACLs vs. Capabilities

• Access Control List: Focus on resourcesG d if l b

Protection and Security (11)

Fil

e S

yste

ms

– Good if resources greatly outnumber users– Can be implemented with minimal caching– Can be attached to objects (e.g., file metadata)

– Good when the user who creates a resource has authority over it

• Capability System: Focus on users

Operating Systems Prof. Dr. Werner Filip50

Capability System: Focus on users– Good if users greatly outnumber resources– Lots of information caching is needed– Good when a system manager has control over all

resources

14.04.2016

26

Both are needed

• ACLs for files and other proliferating resources

Protection and Security (12)F

ile

Sys

tem

s • Capabilities for major system functions

• The common OSs offer BOTH– Linux emphasizes an ACL model

• provides good control over files and resources that are file-like

Operating Systems Prof. Dr. Werner Filip51

– Windows 2000/XP emphasize Capabilities• provides good control over access to system functions (e.g.

creating a new user, or doing a system backup…)

• Access control lists for files

…and good management, too!

• What do we need to know to set up a new user or to

Protection and Security (13)

Fil

e S

yste

ms

change their rights?

• …to set up a new resource or to change the rights of its users?

• …Who has the right to set/change access rights?

Operating Systems Prof. Dr. Werner Filip52

• No OS allows you to implement all the possible policies easily.

14.04.2016

27

Enforcing Access Control• User level privileges must always be less than OS

privileges!

Protection and Security (14)F

ile

Sys

tem

s

– For example, a user should not be allowed to grab exclusive control of a critical device

– or write to OS memory space

• …and the user cannot be allowed to raise his privilege level!

Operating Systems Prof. Dr. Werner Filip53

• The OS must enforce it…and the user must not be able to bypass the controls

• In most modern operating systems, the code which manages the resource enforces the policy

• No user can interrupt it while it is runningWi d Li ti l i t t t ll

Protection and Security (15)

(Traditional) Requirements – System Call Code

Fil

e S

yste

ms

• Windows, Linux routinely interrupt system calls

• No user can feed it data to make it • violate access control policies• stop serving other users

• No user can replace or alter any system call code• Except your average virus

Operating Systems Prof. Dr. Werner Filip54

• Except your average virus

• No user can add functionality to the OS!• Except dynamically loaded device drivers

14.04.2016

1

Chapter 5

Input/Output

Inpu

t/O

utpu

t

Operating Systems Prof. Dr. Werner Filip1

Overview

• OS controls I/O devices => Issue commands,

H dl i t t

Inpu

t/O

utpu

t

Handles interrupts,

Handles errors

• Provide easy to use interface to devices Hopefully device independent

• First look at hardware, then software

Operating Systems Prof. Dr. Werner Filip2

Emphasize software

Software structured in layers

Look at disks

14.04.2016

2

I/O Devices

• Two types of I/O devices - block, character

• Block - can read blocks independently of one th

Inpu

t/O

utpu

t

another Hard disks, CD-ROMs, USB sticks

• Character - accepts characters without regard to block structure Printers, mice, network interfaces

• Not everything fits, e.g. clocks don’t fit

Operating Systems Prof. Dr. Werner Filip3

• Division allows for OS to deal with devices in device independent manner File system deals with blocks

Principles of I/O Hardware

Inpu

t/O

utpu

t

Some typical device – network and data base ratesOperating Systems Prof. Dr. Werner Filip

4

14.04.2016

3

Device Controllers

• I/O devices have components:– mechanical component – electronic component

• The electronic component is the device controller– may be able to handle multiple devices

• Controller's tasks– convert serial bit stream to block of bytes– perform error correction as necessaryIn

put/

Out

put

– perform error correction as necessary– make available to main memory

Operating Systems Prof. Dr. Werner Filip5

• Controller has registers which OS can write and read

W i i d d i

Memory Mapped I/O (1)

Inpu

t/O

utpu

t

• Write - gives command to device

• Read - learn device status……

• Devices have data buffer which OS can read/write (e.g. video RAM, used to display pixels on a screen)

Operating Systems Prof. Dr. Werner Filip6

14.04.2016

4

Memory-Mapped I/O (2)In

put/

Out

put

(a) A single-bus architecture(b) A dual-bus memory architecture

Operating Systems Prof. Dr. Werner Filip7

• CPU COULD request data one byte at a time from I/O controller

Direct Memory Access (DMA)

Inpu

t/O

utpu

t • Big waste of time, use DMA

• DMA controller on mother-board; normally one controller for multiple devices

• CPU reads/writes to registers in controller Memory address register

Operating Systems Prof. Dr. Werner Filip8

Memory address register

Byte count register

Control registers-I/O port, direction of transfer, transfer units (byte/word), number of bytes to transfer in a burst

14.04.2016

5

• Controller reads a block into its memory

C t h k

When DMA is not usedIn

put/

Out

put

• Computes checksum

• Interrupts OS

• Sends byte at a time to memory

Operating Systems Prof. Dr. Werner Filip9

Direct Memory Access (DMA)

Inpu

t/O

utpu

t

Operation of a DMA transfer

Operating Systems Prof. Dr. Werner Filip10

14.04.2016

6

Interrupts RevisitedIn

put/

Out

put

Bus

H i t t h

Operating Systems Prof. Dr. Werner Filip11

How interrupts happen.Connections between devices and interrupt controller actually use interrupt lines on the bus rather than dedicated wires.

Goals of I/O Software (1)

• Device independence– programs can access any I/O device

– without specifying device in advance

· (floppy, hard drive, or CD-ROM)

• Uniform naming– name of a file or device a string or an integer

– not depending on which machineInpu

t/O

utpu

t

• Error handling– handle as close to the hardware as possible

Operating Systems Prof. Dr. Werner Filip12

14.04.2016

7

Goals of I/O Software (2)

• Synchronous vs. asynchronous transfers– blocked transfers vs. interrupt-drivenp

• Buffering– data coming off a device cannot be stored in final

destination

• Sharable vs. dedicated devices– disks are sharableIn

put/

Out

put

– tape drives would not be

Operating Systems Prof. Dr. Werner Filip13

I/O Software Layers

Inpu

t/O

utpu

t

Layers of the I/O Software System

Operating Systems Prof. Dr. Werner Filip14

14.04.2016

8

Interrupt Handlers

• Interrupt handlers are best hidden– have driver starting an I/O operation block until interrupt notifies of completion

• Interrupt procedure does its task– then unblocks driver that started it

F ll i b f d i

Inpu

t/O

utpu

t

• Following steps must be performed in software after interrupt completed

Operating Systems Prof. Dr. Werner Filip15

Device Drivers (1)

Inpu

t/O

utpu

t

• Logical position of device drivers is shown here• Communications between drivers and device controllers

goes over the busOperating Systems Prof. Dr. Werner Filip

16

14.04.2016

9

Device Drivers (2)

• Driver contains code specific to the device

• Supplied by manufacturer

Inpu

t/O

utpu

t • Installed in the kernel

• User space might be better place

• Why? Bad driver can mess up kernel

• Need interface to OS block and character interfaces

procedures which OS can call to invoke driver (e g read a block)

Operating Systems Prof. Dr. Werner Filip17

procedures which OS can call to invoke driver (e.g. read a block)

Device Drivers (3)

• Checks input parameters for validity

• Abstract to concrete translation (block number to cylinder, head, track, sector)

Inpu

t/O

utpu

t • Check device status. Might have to start it.

• Puts commands in device controller’s registers

• Driver blocks itself until interrupt arrives

• Might return data to caller

• Does return status information

Operating Systems Prof. Dr. Werner Filip18

• The end

• Drivers should be re-entrant

• OS adds devices when system (and therefore driver) is running

14.04.2016

10

User-Space I/O SoftwareIn

put/

Out

put

Layers of the I/O system and the main functions of each layer

Operating Systems Prof. Dr. Werner Filip19

Disk Hardware (1)

• Disk drives are addressed as large 1-dimensional arrays of logical blocks, where the logical block is the smallest unit of transfer

Inpu

t/O

utpu

t

logical block is the smallest unit of transfer. • The 1-dimensional array of logical blocks is

mapped into the sectors of the disk sequentially:

– Sector 0 is the first sector of the first track on the outermost cylinder.

Operating Systems Prof. Dr. Werner Filip20

y– Mapping proceeds in order through that track, then the

rest of the tracks in that cylinder, and then through the rest of the cylinders from outermost to innermost.

14.04.2016

11

Disk Hardware (2)

Moving-head Disk Mechanism

Inpu

t/O

utpu

t

Operating Systems Prof. Dr. Werner Filip21

Disk Hardware (3)

Inpu

t/O

utpu

t

k

Operating Systems Prof. Dr. Werner Filip22

A: TrackB: Geometrical sectorC: Track sectorD: Cluster

14.04.2016

12

Disk Hardware (4)In

put/

Out

put

Disk parameters for the original IBM PC floppy disk and a Western Digital WD 18300 hard disk

Operating Systems Prof. Dr. Werner Filip23

Disk Formatting (1)

Inpu

t/O

utpu

t

A disk sectorECC – error correcting code

Operating Systems Prof. Dr. Werner Filip24

14.04.2016

13

Disk Formatting (2)

N i t l i

Inpu

t/O

utpu

t

• No interleaving• Single interleaving• Double interleaving

Operating Systems Prof. Dr. Werner Filip25

High level format

• Partitions-for more then one OS on same disk

i h b d i h

Inpu

t/O

utpu

t

• Pentium-sector 0 has master boot record with partition table and code for boot block

• Pentium has 4 partitions - can have both Windows and Unix

• In order to be able to boot, one sector has to be

Operating Systems Prof. Dr. Werner Filip26

marked as active

14.04.2016

14

High level format for each partition

• master boot record in sector 0

Inpu

t/O

utpu

t • boot block program

• free storage admin (bitmap or free list)

• root directory

• empty file system

• indicates which file system is in the partition

Operating Systems Prof. Dr. Werner Filip27

• indicates which file system is in the partition (in the partition table)

• The operating system is responsible for using hardware efficiently — for the disk drives, this means having a fast access time and disk bandwidth.

Disk Scheduling (1)

Inpu

t/O

utpu

t • Access time has two major components:– Seek time is the time for the disk are to move the heads to the

cylinder containing the desired sector.– Rotational latency is the additional time waiting for the disk to

rotate the desired sector to the disk head.

• Minimize seek time seek distance

Operating Systems Prof. Dr. Werner Filip28

Minimize seek time seek distance.

• Disk bandwidth is the total number of bytes transferred, divided by the total time between the first request for service and the completion of last transfer.

14.04.2016

15

Disk Scheduling (2)

• There are many sources of disk I/O request:– OS

– System processes

Inpu

t/O

utpu

t – Users processes

• I/O request includes input/output mode, disk address, memory address, number of sectors to transfer.

• OS maintains queue of requests, per disk or device.

Operating Systems Prof. Dr. Werner Filip29

• Idle disk can immediately work on I/O request, busy disk means work must queue:– Optimization algorithms only make sense when a queue exists.

Disk Arm Scheduling

Moving-head Disk Mechanism

Inpu

t/O

utpu

t

Operating Systems Prof. Dr. Werner Filip30

14.04.2016

16

Disk Arm Scheduling Algorithms (1)

• Time required to read or write a disk block determined by 3 factors

1. Seek time

2. Rotational delay

3. Actual transfer time

• Seek time dominatesInpu

t/O

utpu

t

• Error checking is done by controllers

Operating Systems Prof. Dr. Werner Filip31

Disk Arm Scheduling Algorithms (2)

Inpu

t/O

utpu

t

Operating Systems Prof. Dr. Werner Filip32

14.04.2016

17

Disk Arm Scheduling Algorithms (3)

• Note that drive controllers have small buffers and can manage a queue of I/O requests (of varying “depth”).

Inpu

t/O

utpu

t

g q q ( y g p )

• Several algorithms exist to schedule the servicing of disk I/O requests.

• The analysis is true for one or many platters.

• We illustrate them with an I/O request queue

(cylinders are between 0-199):

Operating Systems Prof. Dr. Werner Filip33

queue = 98, 183, 37, 122, 14, 124, 65, 67

head starts at 53

Disk Arm Scheduling Algorithms (4)

First-Come-First-Served (FCFS)

• Do accesses in the order in which they are presented to

Inpu

t/O

utpu

t

y pthe disk

• This is very fair to processes

• This is very simple to implement

• Approximates random accesses to disk

– gives rated, average latency for every read

Operating Systems Prof. Dr. Werner Filip34

– will have large average seeks between each access

• Not a good policy

14.04.2016

18

18312298676553 37 14 124

Disk Arm Scheduling Algorithms (5)

queue = 98, 183, 37, 122, 14, 124, 65, 67

head starts at 53

Inpu

t/O

utpu

t 45

85+

146+

85+

108+

110+

Operating Systems Prof. Dr. Werner Filip

First-Come-First-Served (FCFS)

Illustration shows total head movement of 640 cylinders.

35

59+

2+

640=

Disk Arm Scheduling Algorithms (6)

Shortest Seek First (SSF)

• Selects the request with the minimum distance from the

Inpu

t/O

utpu

t

• Selects the request with the minimum distance from the current head position.

• It’s based in favor of the middle cylinders requests.

Operating Systems Prof. Dr. Werner Filip36

14.04.2016

19

Disk Arm Scheduling Algorithms (7)

183122986765 53 37 14 124

queue = 98, 183, 37, 122, 14, 124, 65, 67

head starts at 53

Inpu

t/O

utpu

t 12

2+

30+

23+

84+

24+

Shortest Seek First (SSF) disk scheduling algorithm

Operating Systems Prof. Dr. Werner Filip

236=

2+

59+

37

Illustration shows total head movement of 236 cylinders.

Disk Arm Scheduling Algorithms (8)

Elevator Scan

• The disk arm starts at the first I/O request on the disk, and

Inpu

t/O

utpu

t

The disk arm starts at the first I/O request on the disk, and moves toward the last I/O request on the other end, servicing requests until it gets to the other extreme I/O request on the disk, where the head movement is reversed and servicing continues.

• It moves in both directions until both last I/O requests;

Operating Systems Prof. Dr. Werner Filip38

It moves in both directions until both last I/O requests; more inclined to serve the middle cylinder requests.

14.04.2016

20

Disk Arm Scheduling Algorithms (9)

183122986765533714 124

queue = 98, 183, 37, 122, 14, 124, 65, 67

head starts at 53

Inpu

t/O

utpu

t 16

23+

51+

2+

31+

24+

Elevator algorithm (elevator scan)

Operating Systems Prof. Dr. Werner Filip

208=

2+

59+

39

Illustration shows total head movement of 208 cylinders.

18312298676553 37 14 124

Disk Arm Scheduling Algorithms (10)

queue = 98, 183, 37, 122, 14, 124, 65, 67

head starts at 53

Inpu

t/O

utpu

t 12

2+

31+

24+

2+

59+

Elevator algorithm (elevator scan)

Operating Systems Prof. Dr. Werner Filip

322=

169+

23+

40

Illustration shows total head movement of 322 cylinders.

14.04.2016

21

Error HandlingIn

put/

Out

put

• A disk track with a bad sector• Substituting a spare for the bad sector• Shifting all the sectors to bypass the bad one

Operating Systems Prof. Dr. Werner Filip41

14.04.2016

1

Multiple Processor Systems

Chapter 6em

s

Multiple Processor Systems

• Multiprocessors • Multicomputers • Distributed systemspl

e P

roce

ssor

Sys

te

Distributed systems

Mul

tip

Operating Systems Prof. Dr. Werner Filip1

Multiprocessor Systems

ems

• Continuous need for faster computersple

Pro

cess

or S

yste

• Continuous need for faster computers– shared memory model– message passing multiprocessor– wide area distributed system

Mul

tip

Operating Systems Prof. Dr. Werner Filip2

14.04.2016

2

Multiprocessors

Definition:

ems

A computer system in which two or more CPUs share full access to a commonRandom-Access Memory (RAM).

ple

Pro

cess

or S

yste

Mul

tip

Operating Systems Prof. Dr. Werner Filip3

Multiprocessor Hardware (1)

ems

ple

Pro

cess

or S

yste

4

Bus-based multiprocessorsMul

tip

Operating Systems Prof. Dr. Werner Filip

14.04.2016

3

Multiprocessor Hardware (2)em

spl

e P

roce

ssor

Sys

te

• UMA Multiprocessor using a crossbar switch (Uniform Memory Access)

Mul

tip

Operating Systems Prof. Dr. Werner Filip5

Multiprocessor Hardware (3)

• UMA multiprocessors using multistage switching networks can be built from 2x2 switchesem

s

switches

ple

Pro

cess

or S

yste

(a) 2x2 switch (b) Message format

Mul

tip

Operating Systems Prof. Dr. Werner Filip6

14.04.2016

4

Multiprocessor Hardware (4)em

spl

e P

roce

ssor

Sys

te

• Omega Switching Network

Mul

tip

Operating Systems Prof. Dr. Werner Filip7

Multiprocessor Hardware (5)

Non-Uniform Memory Access (NUMA) Multiprocessor Characteristicsem

s p

1. Access to remote memory via commands

- LOAD- STORE

2 A t t l th t l lple

Pro

cess

or S

yste

2. Access to remote memory slower than to local

3. Single address space visible to all CPUsMul

tip

Operating Systems Prof. Dr. Werner Filip8

14.04.2016

5

Multiprocessor Hardware (6)em

spl

e P

roce

ssor

Sys

te

(a) 256-node directory based multiprocessor(b) Fields of 32-bit memory address(c) Directory at node 36

Mul

tip

Operating Systems Prof. Dr. Werner Filip9

Multiprocessor OS Types (1)

ems

Bus

ple

Pro

cess

or S

yste

Each CPU has its own operating systemMul

tip

Operating Systems Prof. Dr. Werner Filip10

14.04.2016

6

Multiprocessor OS Types (2)em

s

Bus

ple

Pro

cess

or S

yste

Master-Slave multiprocessorsMul

tip

Operating Systems Prof. Dr. Werner Filip11

Multiprocessor OS Types (3)

ems

Busple

Pro

cess

or S

yste

• Symmetric Multiprocessors (SMP)– SMP multiprocessor model

Mul

tip

Operating Systems Prof. Dr. Werner Filip12

14.04.2016

7

Multiprocessor Synchronization (1)em

spl

e P

roce

ssor

Sys

te

TSL (test-and-set) instruction can fail if bus already lockedMul

tip

Operating Systems Prof. Dr. Werner Filip13

Multiprocessor Synchronization (2)

ems

ple

Pro

cess

or S

yste

Multiple locks used to avoid cache thrashing

Mul

tip

Operating Systems Prof. Dr. Werner Filip14

14.04.2016

8

Multiprocessor Synchronization (3)

Spinning versus Switching

ems

• In some cases CPU must wait– waits to acquire ready list

• In other cases a choice exists– spinning wastes CPU cycles

– switching uses up CPU cycles alsople

Pro

cess

or S

yste

switching uses up CPU cycles also

– possible to make separate decision each time locked mutex encounteredM

ulti

p

Operating Systems Prof. Dr. Werner Filip15

Multiprocessor Scheduling (1)

ems

ple

Pro

cess

or S

yste

• Timesharing– note use of single data structure for scheduling

Mul

tip

Operating Systems Prof. Dr. Werner Filip16

14.04.2016

9

Multiprocessor Scheduling (2)em

s

S h iple

Pro

cess

or S

yste

• Space sharing– multiple threads at same time across multiple CPUsM

ulti

p

Operating Systems Prof. Dr. Werner Filip17

Multiprocessor Scheduling (3)

ems

ple

Pro

cess

or S

yste

• Problem with communication between two threads– both belong to process A– both running out of phase

Mul

tip

Operating Systems Prof. Dr. Werner Filip18

14.04.2016

10

Multiprocessor Scheduling (4)

• Solution: Gang Scheduling

ems

1. Groups of related threads scheduled as a unit (a gang)

2. All members of gang run simultaneously

• on different timeshared CPUs

3 All gang members start and end time slices togetherple

Pro

cess

or S

yste

3. All gang members start and end time slices together

Mul

tip

Operating Systems Prof. Dr. Werner Filip19

Multiprocessor Scheduling (5)

ems

ple

Pro

cess

or S

yste

Gang Scheduling

Mul

tip

Operating Systems Prof. Dr. Werner Filip20

14.04.2016

11

Multicomputers

• Definition:Tightly-coupled CPUs that do not share em

s

g y p C Umemory

• Also known as

– cluster computersple

Pro

cess

or S

yste

cluster computers

– clusters of workstations (COWs)Mul

tip

Operating Systems Prof. Dr. Werner Filip21

Multicomputer Hardware (1)

ems

ple

Pro

cess

or S

yste

• Interconnection topologies(a) single switch(b) ring(c) grid

(d) double torus(e) cube(f) hypercube

Mul

tip

Operating Systems Prof. Dr. Werner Filip22

14.04.2016

12

Multicomputer Hardware (2)em

spl

e P

roce

ssor

Sys

te

• Switching scheme– store-and-forward packet switching

Mul

tip

Operating Systems Prof. Dr. Werner Filip23

Multicomputer Hardware (3)

ems

ple

Pro

cess

or S

yste

Network interface boards in a multicomputer

Mul

tip

Operating Systems Prof. Dr. Werner Filip24

14.04.2016

13

Low-Level Communication Software (1)

• If several processes running on node – need network access to send packets …

ems p

• Map interface board to all process that need it

• If kernel needs access to network …

• Use two network boardsone to user space one to kernelpl

e P

roce

ssor

Sys

te

– one to user space, one to kernel

Mul

tip

Operating Systems Prof. Dr. Werner Filip25

Low-Level Communication Software (2)

ems

ple

Pro

cess

or S

yste

Node to Network Interface Communication• Use send & receive rings• coordinates main CPU with on-board CPU

Mul

tip

Operating Systems Prof. Dr. Werner Filip26

14.04.2016

14

User Level Communication Software

• Minimum servicesprovided

(a) Blocking send call

ems

– send and receive commands

• These are blocking

ple

Pro

cess

or S

yste

(synchronous) calls

(b) Nonblocking send call

Mul

tip

Operating Systems Prof. Dr. Werner Filip27

Remote Procedure Call (1)

ems

ple

Pro

cess

or S

yste

• Steps in making a remote procedure call– the stubs are shaded gray

Mul

tip

Operating Systems Prof. Dr. Werner Filip28

14.04.2016

15

Remote Procedure Call (2)

Implementation Issues

ems

• Cannot pass pointers– call by reference becomes copy-restore (but might fail)

• Weakly typed languages– client stub cannot determine size

• Not always possible to determine parameter typesple

Pro

cess

or S

yste

Not always possible to determine parameter types

• Cannot use global variables– may get moved to remote machine

Mul

tip

Operating Systems Prof. Dr. Werner Filip29

Distributed Shared Memory (1)

ems

ple

Pro

cess

or S

yste

• Note layers where it can be implemented– hardware– operating system– user-level software

Mul

tip

Operating Systems Prof. Dr. Werner Filip30

14.04.2016

16

Distributed Shared Memory (2)

Replication

( ) P di ib d 4ems

(a) Pages distributed on 4 machines

(b) CPU 0 reads page 10

ple

Pro

cess

or S

yste

(c) CPU 1 reads page 10

Mul

tip

Operating Systems Prof. Dr. Werner Filip31

Distributed Shared Memory (3)

ems

ple

Pro

cess

or S

yste

• False Sharing

• Must also achieve sequential consistency

Mul

tip

Operating Systems Prof. Dr. Werner Filip32

14.04.2016

17

Multicomputer Scheduling Load Balancing (1)em

s

Process

ple

Pro

cess

or S

yste

• Graph-theoretic deterministic algorithm

Mul

tip

Operating Systems Prof. Dr. Werner Filip33

Load Balancing (2)

ems

ple

Pro

cess

or S

yste

• Sender-initiated distributed heuristic algorithm– overloaded sender

Mul

tip

Operating Systems Prof. Dr. Werner Filip34

14.04.2016

18

Load Balancing (3)em

spl

e P

roce

ssor

Sys

te

• Receiver-initiated distributed heuristic algorithm– under loaded receiver

Mul

tip

Operating Systems Prof. Dr. Werner Filip35

Distributed Systems (1)

ems

ple

Pro

cess

or S

yste

Comparison of three kinds of multiple CPU systemsMul

tip

Operating Systems Prof. Dr. Werner Filip36

14.04.2016

19

Distributed Systems (2)em

spl

e P

roce

ssor

Sys

te

Achieving uniformity with middleware

Mul

tip

Operating Systems Prof. Dr. Werner Filip37

Network Hardware (1)

Computer

ems

(a) (b)

ple

Pro

cess

or S

yste

• Ethernet(a) classic Ethernet(b) switched Ethernet

Mul

tip

Operating Systems Prof. Dr. Werner Filip38

14.04.2016

20

Network Hardware (2)em

spl

e P

roce

ssor

Sys

te

The Internet

Mul

tip

Operating Systems Prof. Dr. Werner Filip39

Network Services and Protocols (1)

ems

ple

Pro

cess

or S

yste

Network Services

Mul

tip

Operating Systems Prof. Dr. Werner Filip40

14.04.2016

21

Network Services and Protocols (2)em

spl

e P

roce

ssor

Sys

te

• Internet Protocol (IP)

• Transmission Control Protocol (TCP)

• Interaction of protocols

Mul

tip

Operating Systems Prof. Dr. Werner Filip41

Document-Based Middleware (1)

ems

ple

Pro

cess

or S

yste

• The Web– a big directed graph of documents

Mul

tip

Operating Systems Prof. Dr. Werner Filip42

14.04.2016

22

Document-Based Middleware (2)

How the browser gets a page

1. Asks DNS for IP address

ems

2. DNS replies with IP address

3. Browser makes connection

4. Sends request for specified page

5. Server sends file

6 TCP connection releasedple

Pro

cess

or S

yste

6. TCP connection released

7. Browser displays text

8. Browser fetches, displays images

Mul

tip

Operating Systems Prof. Dr. Werner Filip43

File System-Based Middleware (1)

ems

(a) (b)

ple

Pro

cess

or S

yste

• Transfer Models(a) upload/download model

(b) remote access model

Mul

tip

Operating Systems Prof. Dr. Werner Filip44

14.04.2016

23

File System-Based Middleware (2)em

s

Naming Transparencyple

Pro

cess

or S

yste

Naming Transparencya) Two file server

b) Clients have same view of file system

c) Alternatively, clients with different view

Mul

tip

Operating Systems Prof. Dr. Werner Filip45

File System-Based Middleware (3)

ems

ple

Pro

cess

or S

yste

• Semantics of File sharing– (a) single processor gives sequential consistency– (b) distributed system may return obsolete value

Mul

tip

Operating Systems Prof. Dr. Werner Filip46

14.04.2016

24

File System-Based Middleware (4)em

spl

e P

roce

ssor

Sys

te

• AFS – Andrew File System– workstations grouped into cells– note position of venus and vice

Client's view

Mul

tip

Operating Systems Prof. Dr. Werner Filip47