Contentfilip/bsy/OS-SS-2016.pdf · 14.04.2016 1 Lecture Operating Systems SS 2016 Prof. Dr. Werner...
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
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