Course Overview Principles of Operating Systems

1
Course OverviewPrinciples of Operating Systems

• Introduction
• Computer System Structures
• Operating System Structures
• Processes
• Process Synchronization
• Deadlocks
• CPU Scheduling

• Memory Management
• Virtual Memory
• File Management
• Security
• Networking
• Distributed Systems
• Case Studies
• Conclusions

2
Chapter Overview Process Synchronization

• Motivation
• Objectives
• Concurrency
• Synchronization Problems
• Race Conditions
• Critical Sections
• Mutual Exclusion
• Synchronization Methods
• Hardware
• Semaphores
• Monitors

• Synchronization Patterns
• Bounded Buffer
• Readers-Writers
• Dining Philosophers
• Important Concepts and Terms
• Chapter Summary

3
Motivation

• several processes exist simultaneously in a
  system
• co-existing processes may interfere with each
  others execution
• incorrect calculations,decrease in
  efficiency,deadlock
• processes may cooperate within the same task
• the activities of cooperating processes need to
  be coordinated
• the use of shared resources must be coordinated
• the separation of independent activities in
  processes may lead to higher performance and more
  convenient use

4
Objectives

• recognize potential problems with the
  coordination of activities for several processes
  (cooperation or resource sharing)
• know how to use synchronization methods to
  prevent problems
• be aware of the advantages and problems of
  different synchronization methods
• be familiar with some fundamental synchronization
  patterns

5
Process Synchronization

• the activities of several concurrent processes
  are synchronized
• access to common resources is coordinated

6
Importance of Synchronization

• prevention and elimination of race conditions,
  deadlocks and starvation
• serious ramifications can occur otherwise (Therac
  25)
• data integrity/consistency
• collaboration
• efficiency

Son 97
2
2 An Investigation of the Therac-25 Accidents
7
Concurrency

• several processes are active at the same time
• between their start and finish operations
• each process must make some progress
• multitasking, multiprogramming
• process multiplexing the CPU switches between
  different processes
• to the human user, these processes seem to be
  executed simultaneously
• multiprocessing
• several processes are executed simultaneously by
  multiple processing elements (CPUs)

8
Resource Types

• shared several processes can utilize them
  simultaneously
• exclusive only one process at a time
• preemptible can be taken away from a process,
  given to another, and returned to the old process
• non-preemptible one process must finish before
  another can use the resource

9
Synchronization Problems

• race conditions
• the exact timing in the execution of concurrent
  processes is critical
• critical sections
• part of a program that must be protected from
  interference
• usually resolved via mutual exclusion
• mutual exclusion
• the usage of resources by processes is restricted
• usually only one process may use one instance of
  a resource

10
Race Conditions

• the final result of an activity involving shared
  resources depends on the timing of processes
• caused by
• the division of activities into several separate
  operations (multitasking on a single CPU)
• simultaneous operations on shared resources in
  multiprocessor systems
• race conditions may happen only very rarely
• coincidence of the interruption of an operation
  and manipulation of shared resources by another
  process
• very difficult to detect and reproduce

11
Example Race Conditions

• procedure for a character echo function

procedure echo var out, in character begin inp
ut (in, keyboard) out in output (out,
display) end.
Stallings 98
12
Example Race Conditions

• two processes A and B use the echo procedure
• implicitly shared variables out, in
• no restrictions on modifications of the variables

Process A . input (in, keyboard) . out
in output (out, display) . .
Process A . input (in, keyboard) out
in . output (out, display) .
Stallings 98
13
Example Race Conditions

• problem
• the value of the shared variable in depends on
  the exact timing between the two processes
• undesired results (the same value is echoed by
  both processes)
• solution
• control access to shared resources
• here protect shared variables by allowing only
  one process at a time in the procedure echo
• echo is an example for a critical section

14
Handling of Race Conditions

• guarantee the correct sequence of execution
  through process synchronization mechanisms
• relies on the correct use of these mechanisms by
  the processes
• delay the execution of one process
• improper, but frequently used hack, often
  depending on hardware specifics like processor
  speed

15
Critical Sections

• several processes cooperate on a task by sharing
  resources
• a critical section is a segment of code in which
  a process utilizes some shared resources, and no
  other process may interfere
• execution of critical sections must be mutually
  exclusive in time
• there may be different critical sections for
  different sets of shared resources
• a protocol us required to guarantee that only one
  process is in the critical section

16
Critical Section Diagram
repeat
other code
exit section
other code
until false
17
Critical Section Requirements

• solutions for the critical section problem must
  satisfy
• mutual exclusion
• if one process is executing in its critical
  section, then no other processes can execute in
  their critical sections
• progress
• processes wishing to enter their critical
  sections must come to a decision eventually
• bounded waiting
• after a process has made a request to enter its
  critical section, only a finite number of other
  processes may go first
• assumptions
• processes execute at non-zero speed
• no assumptions on their relative speed

18
Two-Process Solutions

• critical section problem with only two processes
• shared Boolean or integer variables for
  synchronization
• Algorithm 1
• turn variable to switch between the two
  processes
• Algorithm 2
• flag variable for each process to indicate that
  it wants to enter its critical section
• Algorithm 3
• combination of the above two

19
Algorithm 1

• processes P0 and P1 share a common variable turn
  initialized to 0 or 1.
• if turn 0 then process P0 enters critical
  section
• if turn 1 then process P1 enters critical
  section

20
Diagram of Algorithm 1
repeat
other code
other code
until false
21
Evaluation Algorithm 1

• Requirements satisfied?
• mutual exclusion
• yes, only one process is allowed in its critical
  section
• progress
• no, requires strict alternation
• bounded waiting
• yes, exactly one waiting period is required

22
Algorithm 2

• an array flag of two elementsflag0 and
  flag1 indicates if a process wants to enter
  its critical section
• if flagi is true, then Pi is ready to enter its
  critical section
• elements of the array flag are initialized to
  false

Son 97
30
Silberschatz Galvin, 1998
23
Diagram of Algorithm 2
repeat
other code
flagi true while flagj do no-op
other code
until false
24
Problems with Algorithm 2

• Problem What happens if P0 sets flag0 to true
  and P1 sets flag1 to true before they get into
  their while statement?
• Answer Infinite loop within while statements
• depends too much on the exact timing of the two
  processes
• not very likely, but may happen

Son 97
32
Silberschatz Galvin, 1998
25
Evaluation Algorithm 2

• Requirements satisfied?
• mutual exclusion
• yes, only one process is allowed in its critical
  section
• progress
• no, endless loop in the entry sections possible
  if both processes set their flags simultaneously
• switching the order of the two instructions in
  the entry section is not a solution, it will lead
  to mutual exclusion problems
• bounded waiting
• yes, a process sets flag in the exit section such
  that the other can continue

26
Algorithm 3

• combination of algorithms 1 2
• designed to meet all three mutual exclusion
  requirements
• processes share two Boolean variables
• turn
• the array flag

Son 97
33
Silberschatz Galvin, 1998
27
Diagram of Algorithm 3
repeat
other code
flagi true turn j while (flagj and
turn j) do no-op
other code
until false
28
Algorithm 3 - Visualization
Process i Process j
flagi true turn j
flagj true turn i
the expression (flagi and turn i) is
false enters critical section flagj false
executing no-op until the expression (flagj
and turn j) becomes false
enters critical section
flagi false
29
Analysis of Algorithm 3

• a process Pi can enter its critical section only
  if
• flagj false (the other process doesnt want
  to enter its critical section), or
• turn i (the other process wants to enter its
  critical section, but set the turn variable to
  process Pi )
• the two processes cannot be both in their while
  loops because turn can either be true or
  false, but not both
• in its exit section, a process resets its flag
  variable, thus permitting the other process entry

Son 97
36
Silberschatz Galvin, 1998
30
Evaluation Algorithm 3

• Requirements satisfied?
• mutual exclusion
• yes
• progress
• yes
• bounded waiting
• yes
• algorithm 3 is a satisfactory solution for the
  two-process critical section problem
• how can this algorithm be extended to n processes?

31
Multiple-Process Critical Section

• critical section problem with n processes
• one solution utilizes the bakery algorithm
• customers pick a number when they enter the
  store, and are served according to the value of
  their numbers
• each process calculates a number when it wants to
  enter the critical section
• based on the maximum number already assigned
• process with the lowest number gets served first
• If two processes have the same number, then the
  process with the lower process id gets served
  first

Son 97
37
Silberschatz Galvin, 1998
32
Bakery Algorithm

• designed with distributed systems in mind
• relies on two arrays of variables
• choosing array0..n-1 of Boolean
• indicates that a process is calculating its
  number
• number array0..n-1 of integer
• used as identifier for processes
• under certain circumstances, two processes may
  have the same number (if they arrive at the same
  time)

Son 97
38
Silberschatz Galvin, 1998
33
Code Bakery Algorithm
repeat
critical section
numberi 0
other code
until false
40
34
Mutual Exclusion

• requires that only one process performs
  operations on shared resources
• if two processes attempt to access a shared
  resource simultaneously, one will have to wait
• necessary for the protection of critical sections

35
Handling Mutual Exclusion

• protect access to resources through
  synchronization mechanisms
• implicit synchronization for many cases through
  the use of system calls
• not sufficient, since many system calls are
  reentrant

36
Implementing Mutual Exclusion

• hardware
• special instructions
• OS
• data structures and operations provided by the
  OS, e.g. via system calls
• programming language
• constructs at the language level (e.g. rendezvous
  in Ada)
• application
• application programmer must take care of it
• all solutions usually involve critical sections

37
H/W Mutual Exclusion

• special machine instructions that do two steps
  indivisibly
• test_and_set test a value if it is false set it
  to true, else leave it as false
• exchange swap the values of two variables

test_and_set
exchange
while (test_and_set(lock)) do no-op critical
section lock false
key true repeat exchange(lock, key) until
(key false) critical section lock false
38
Characteristics

• hardware-based mutual exclusion
• advantages
• can be used by a single- or multi-processor
  systems (with shared memory)
• simple, easy to verify
• supports multiple critical sections
• disadvantages
• often busy waiting is used
• starvation is possible
• deadlock is possible (especially with priorities)

39
Disabling Interrupts

• interrupts are disabled during the time period
  when mutual exclusion is required
• without interrupts no process switching can occur
• somewhat dangerous one process can hold up the
  whole system
• endless loop
• waiting for resources
• used in special-purpose systems with limited
  hardware

40
OS Mutual Exclusion

• mechanisms to handle mutual exclusion are
  provided by the operating system
• semaphores, mutexes, monitors, rendezvous, etc.
• available to user processes via system calls
• provided in most modern OSs

41
Programming Language Mutual Exclusion

• mutual exclusion mechanisms are built into the
  programming language
• rendezvous in Ada, monitors in Pascal/Modula
• often relies implicitly on OS mechanisms

42
Application Mutual Exclusion

• implemented by the application programmer
• difficult to do right
• frequently practically impossible to test
  sufficiently
• very inefficient
• usually relies on busy waiting

43
Dangers of Mutual Exclusion

• solutions to the mutual exclusion problem may
  lead to
• starvation
• deadlock
• inefficiency

44
Starvation

• indefinite postponement of a process
• a process never gets a resource because the
  resource is allocated to other processes
• higher priority
• consequence of scheduling algorithm
• frequent solution aging
• the longer a process waits for a resource, the
  higher its priority until it eventually has the
  highest priority among the competing processes

45
Deadlock

• several processes are waiting for an event that
  never occurs because it only can be caused by one
  of the waiting processes
• example process A waits for process B, and
  process B waits for process A
• in real life, deadlock is usually resolved by
  applying politeness or common sense processes
  dont have common sense, they stick to their
  programs

46
Example Deadlocks

• studying students both students need the
  textbook and the course notes to study, but there
  is only one copy of each
• consider the following situation

• Student A
• get coursenotes
• get textbook
• study
• release textbook
• release coursenotes

• Student B
• get textbook
• get coursenotes
• study
• release coursenotes
• release textbook

47
Synchronization Methods

• hardware
• semaphores
• monitors

48
Hardware

• based on special instructions like test_and_set,
  exchange
• often in combination with interrupts
• sometimes used as basis for OS synchronization
  mechanisms

49
Semaphores

• used to solve synchronization problems among n
  processes
• fundamental synchronization tool used in many
  operating systems
• integer variable that can be accessed only via
  two atomic operations
• wait
• signal
• frequently used for mutual exclusion
• mutex as special semaphore

Son 97
2
Silberschatz Galvin, 1998
50
Semaphore Usage - Example

• goal force P2 to execute after P1
• common semaphore synch to synchronize the
  operations of the two concurrent processes
• wait, signal utilized to delay P2 until P1 is
  done
• synch initialized to 0

Son 97
5
Silberschatz Galvin, 1998
51
Example Semaphore
P1 P2
since synch 0, must stay idle until signal from
P1 wait(synch)
process 1 statements
signal(synch)
received signal from P1
done executing
process 2 statements
6
52
Semaphore mutex
repeat
other code
wait(mutex)
critical section
signal(mutex)
other code
until false
53
Busy Waiting

• if P2 has to wait for P1, P2 loops continuously
  until P1 is done
• Most mutual exclusion solutions result in busy
  waiting
• Solution P2 blocks itself wakes up via wakeup
  operation

Son 97
8
Silberschatz Galvin, 1998
54
Analysis

• each semaphore has an integer value and a list of
  associated processes
• when a process blocks itself on a semaphore, it
  is added to a queue of waiting processes
• The signal operation on a semaphore removes a
  process from the queue and wakes the process up

55
Declaration and Operations
type semaphore record value integer L
list of process end
wait(S) S.value S.value - 1 if S.value lt
0 then begin -- add this process to S.L
block end signal(S) S.value S.value 1
if S.value lt 0 then begin -- remove next
process from S.L wakeup(P) end
Silberschatz Galvin, 1998
56
Critical Sections and Semaphores

• operations on semaphores must be atomic
• we must ensure that no two processes can execute
  wait and signal on the same semaphore at the same
  time
• uni-processor system
• hardware support such that transactions are
  atomic
• utilize interrupts during the time wait and
  signal are executing
• multiprocessor system
• hardware support is expensive for multiple CPUs
• employ software algorithms if hardware
  instructions are not available

57
Deadlock with Semaphores

• semaphores must be used with care

P0 P1
wait(S)
wait(Q)

wait(S)
wait(Q)
P0 is waiting for P1 to execute signal(Q)
P1 is waiting for P0 to execute signal(S)
Both processes are in a deadlock!
Silberschatz Galvin, 1998
58
Binary Semaphores

• Binary semaphores - semaphores in which their
  integer values can only be either 0 or 1
• used by 2 or more processes to ensure only one
  can enter critical section

Son 97
16
4 "Modern Operating Systems"
59
Example Semaphores

• Three processes all share a resource on which
• one draws an A
• one draws a B
• one draws a C
• Implement a form of synchronization so that A B C
  appears in this sequence

Process A Process B Process C think() think(
) think() draw_A() draw_B() draw_C()
60
Example Semaphores
no semaphores
think() draw_A()
think() draw_B()
A
B
?
think() draw_C()
C
61
Example Semaphores
no semaphores
think() draw_A()
think() draw_B()
A
B
think() draw_C()
C
62
Example Semaphores
no semaphores
think() draw_A()
think() draw_B()
A
B
A
think() draw_C()
C
63
Example Semaphores
no semaphores
think() draw_A()
think() draw_B()
A
B
C
think() draw_C()
C
64
Example Semaphores
no semaphores
think() draw_A()
think() draw_B()
A
B
B
think() draw_C()
C
65
Example Semaphores
Semaphore b 0, c 0
Process A Process B Process C think() b.wait(
) c.wait() draw_A() think() think() b.sign
al() draw_B() draw_C() c.signal()
66
Example Semaphores
Semaphore b 0, c 0
A
B
think() draw_A() b.signal()
b.wait() think() draw_B() c.signal()
C
c.wait() think() draw_C()
67
Example Semaphores
Semaphore b -1, c -1
A
B
think() draw_A() b.signal()
b.wait() think() draw_B() c.signal()
C
c.wait() think() draw_C()
68
Example Semaphores
Semaphore b 0, c -1
A
B
think() draw_A() b.signal()
b.wait() think() draw_B() c.signal()
A
C
c.wait() think() draw_C()
69
Example Semaphores
Semaphore b 0, c 0
A
B
think() draw_A() b.signal()
b.wait() think() draw_B() c.signal()
B
C
c.wait() think() draw_C()
70
Example Semaphores
Semaphore b 0, c 0
A
B
think() draw_A() b.signal()
b.wait() think() draw_B() c.signal()
C
C
c.wait() think() draw_C()
71
Monitors

• a high level synchronization construct
• programmer - defined operators
• access to internal data structures only via
  special procedures
• provides a software solution to synchronization
  problems

Son 97
2
4 "Modern Operating Systems"
72
Properties of Monitors

• ensures that only one process at a time can be
  active within the monitor
• programming language construct
• monitor procedures treated differently by the
  compiler
• compiler and OS are responsible for mutual
  exclusion, not the programmer
• less prone to errors than semaphores
• somewhat limited in its simple form

73
Monitor Diagram
shared data
...
entry queue
operations
initialization code
Silberschatz Galvin, 1998
74
Monitor Syntax - 1
type monitor - name monitor variable
declarations procedure entry P1 (...) begin
... end procedure entry P2 (...) begin ...
end . . procedure entry Pn
(...) begin ... end
Son 97
5
Silberschatz Galvin, 1998
75
Monitor Syntax - 2
begin initialization code end.
The representation of a monitor type cannot be
used directly by various processes This
supports local variable usage
Son 97
6
Silberschatz Galvin, 1998
76
A Problem with Monitors

• Problem need a way for processes to block
  themselves when they cannot proceed
• Solution condition variables

Son 97
7
4 "Modern Operating Systems"
77
Condition Variables

• variable that can be used with two operations
• x.wait suspends the process until it is invoked
  by another process, and
• x.signal releases exactly one process from the
  affiliated waiting queue

Son 97
8
4 "Modern Operating Systems"
78
Monitor Diagram
shared data
condition variable queues
...
entry queue
operations
initialization code
Silberschatz Galvin, 1998
79
Monitor Drawbacks

• only usable in a few programming languages
• solves mutual exclusion problem only for CPUs
  that all have access to common memory not
  designed for distributed systems

Son 97
23
4 "Modern Operating Systems"
80
Synchronization Patterns

• bounded buffer
• readers-writers
• dining philosophers

81
Bounded Buffer

• also known as the consumer-producer problem
• two processes (one producer, one consumer) share
  a common, fixed-size buffer
• producer places information into the buffer
• consumer takes it out

82
Diagram
Producer
16
46
27
67
Consumer
16
83
Problem Producer-Consumer

• the producer wants to place a new item into the
  buffer, but the buffer is already full
• consumer wants to consume an item, but the buffer
  is empty
• Solution producer/consumer goes to sleep, wakes
  up when the consumer has emptied one or more
  items, or when the producer has produced items
• vice-versa (if buffer is empty, consumer goes to
  sleep)

84
Implications

• Race conditions may occur
• wakeup call might be lost
• producer will eventually fill buffer and then go
  to sleep
• consumer will also sleep
• both will sleep forever

85
Diagram of Problem(s)
Producer
5
47
67
16
27
Buffer is full producer sleeps
Consumer
nothing
Buffer is empty consumer sleeps
Son 97
6
86
Solution Techniques

• Semaphores
• Event Counters
• Monitors
• Message-Passing

87
Semaphore Solution
Producer Process
repeat ... -- produce an item in
nextp ... wait(empty)
wait(mutex) ... -- add nextp to
buffer ... signal(mutex)
signal(full) until false
Silberschatz Galvin, 1998
88
Semaphore Solution
Consumer Process
repeat wait(full) wait(mutex) ...
-- remove an item from buffer to nextc ...
signal(mutex) signal(empty) ... --
consume the item in nextc ... until false
Silberschatz Galvin, 1998
89
Semaphore Solution
Producer Process Consumer Process
wait(full) wait(mutex)
-- produce an item in nextp
wait(empty) wait(mutex)
-- remove an item from buffer to nextc
-- add nextp to buffer
signal(mutex) signal(empty)
signal(mutex) signal(full)
-- consume the item in nextc
producer done!
consumer done!
Son 97
90
Readers-Writers

• concurrent processes share a file, record, or
  other resources
• some may read only (readers), some may write
  (writers)
• two concurrent reads have no adverse effects
• problems if
• concurrent reads and writes
• multiple writes

91
Readers-Writers Diagram
P1 P2 P1 P2
read read read write
File
File
No problem Problem!
Son 97
92
Nature of Problem

• race conditions may occur if the resource is
  modified by two processes simultaneously
• Solution mutual exclusion techniques
• may result in starvation, deadlock

Son 97
4
Silberschatz Galvin, 1998
93
Solution via Semaphores

• two semaphores are used
• mutex, rc - counter
• readers have priority over writers
• writers must wait until readers are done
• mutual exclusion is accomplished

Son 97
7
4 "Modern Operating Systems"
94
Another Solution via Semaphores
Reader Process
wait(mutex) readcount readcount 1 if
readcount 1 then wait(wrt) signal(mutex)
... -- reading is performed
... wait(mutex) readcount readcount - 1
if readcount 0 then signal(wrt) signal(mut
ex)
Writer Process
wait(wrt) ... -- writing is
performed ... signal(wrt)
Silberschatz Galvin, 1998
95
Dining Philosophers

• five philosophers sit at a round table - thinking
  and eating
• each philosopher has one chopstick
• five chopsticks total
• a philosopher needs two chopsticks to eat
• philosophers must share chopsticks to eat
• no interaction occurs while thinking

96
Diagram
P1
P2
P5
P3
P4
Son 97
3
Silberschatz Galvin, 1998
97
Nature of Problem

• Problem
• starvation
• a philosopher may never get the two chopsticks
  necessary to eat
• deadlocks
• two neighboring philosophers may try to eat at
  same time
• Solution
• utilize semaphores to prevent deadlocks and/or
  starvation

Son 97
4
Silberschatz Galvin, 1998
98
Faulty Solution
var chopstick array 0..4 of semaphore
repeat wait(chopsticki) wait(chopsticki 1
mod 5) ... -- eat ... signal(chopsticki)
signal(chopsticki 1 mod 5) ... --
think ... until false
Silberschatz Galvin, 1998
99
Analysis of Previous Solution

• Each chopstick is represented by a semaphore
• Advantages
• guarantees that no two neighbors will attempt to
  eat at the same time
• Problems
• possibility of creating a deadlock
• if all philosophers try to eat at same time

100
Outline of a Correct Solution

• One semaphore per philosopher
• must solve deadlock and starvation problem
• deadlock solution
• a philosopher is allowed to pick up chopsticks
  only if both are available
• this requires careful coordination (e.g. critical
  sections)
• does not automatically resolve starvation

Son 97
12
4 "Modern Operating Systems"
101
Important Concepts and Terms

• binary semaphore
• bounded buffer problem
• bounded waiting
• concurrency
• condition variable
• consumer
• exchange instruction
• integer semaphore
• critical section
• deadlock
• dining philosophers
• monitor
• mutex
• mutual exclusion

• producer
• progress
• protected variable
• race condition
• readers
• remote procedure call
• rendezvous
• semaphore
• signal operation
• starvation
• synchronization
• test-and-set instruction
• wait operation
• writers

102
Chapter Summary

• the synchronization of processes is one of the
  key problems in operating systems
• cooperation between processes
• sharing of resources
• synchronization applies to threads as well
• race conditions, critical sections, and mutual
  exclusion must be resolved
• hardware, OS, programming language, and
  application program solutions are available
• often trade-off between efficiency, safety, ease
  of use