Lecture Week 6 Process Synchronisation.pptx

Silberschatz, Galvin and Gagne ©2018
Operating System Concepts – 10th
Edition
Chapter 6: Process
Synchronization

6.2 Silberschatz, Galvin and Gagne ©2018
Edition
Outline
 Background
 The Critical-Section Problem
 Peterson’s Solution
 Hardware Support for Synchronization
 Mutex Locks
 Semaphores
 Monitors
 Liveness
 Evaluation

Edition
Objectives
 Describe the critical-section problem and illustrate a
race condition
 Illustrate hardware solutions to the critical-section
problem using memory barriers, compare-and-swap
operations, and atomic variables
 Demonstrate how mutex locks, semaphores,
monitors, and condition variables can be used to
solve the critical section problem
 Evaluate tools that solve the critical-section problem
in low-, Moderate-, and high-contention scenarios

Edition
Background
 Processes can execute concurrently
• May be interrupted at any time, partially completing execution
 Concurrent access to shared data may result in data
inconsistency
 Maintaining data consistency requires mechanisms to ensure the
orderly execution of cooperating processes.
 An operating system is a software that manages all applications
on a device and basically helps in the smooth functioning of our
computer.
 Because of this reason, the operating system has to perform
many tasks, and sometimes simultaneously. This isn't usually a
problem unless these simultaneously occurring processes use a
common resource.

Edition
Example
 Consider a bank that stores the account balance of each customer in the
same database.
 All processes occur at the same time, ie, Process 1 Withdraws $500,
Process 2 Deposits $500 & Process 3 Checks Balance from the same
memory location therefore there is high probability of erroneous balances.
 To avoid this kind of data inconsistency process synchronization in os is
very helpful.
Bank
Balance
=
$1000
Process 1
Withdraw
$500
Process 2
Deposit
$500
Process 3
Check
Balance

Edition
RACE CONDITION
Watch Video Here on Race Conditio
n

Edition
Process Synchronization
 Process Synchronization is the coordination of execution of multiple
processes in a multi-process system to ensure that they access shared
resources in a controlled and predictable manner, without interfering with
each other and to prevent the possibility of inconsistent data due to
concurrent access.
 It aims to resolve the problem of race conditions and other synchronization
issues in a concurrent system.
 To achieve this, various synchronization techniques such as semaphores,
monitors, and critical sections are used.

Edition
Race Condition
 When more than one process is either running the same code or
modifying the same memory or any shared data, there is a risk that the
result or value of the shared data may be incorrect because all
processes try to access and modify this shared resource.
 Thus, all the processes race to say that my result is correct. This
condition is called the race condition.
 Since many processes use the same data, the results of the processes
may depend on the order of their execution.
 This is mostly a situation that can arise within the critical section.
 In the critical section, a race condition occurs when the end result of
multiple thread executions varies depending on the sequence in which
the threads execute.
 Now the question arises that how to handle a race condition.
 We can tackle this problem by implementing logic in the critical section
like only one process at a time can access the critical section and this
section is called the atomic section.

Edition
Race Condition
 Processes P0 and P1 are creating child processes using the fork()
system call
 Race condition on kernel variable next_available_pid which
represents the next available process identifier (pid)
 Unless there is a mechanism to prevent P0 and P1 from accessing the
variable next_available_pid the same pid could be assigned to
two different processes!

Edition
Critical Section Problem
 Consider system of n processes {p0, p1, … pn-1}
 A Critical Section is a code segment that accesses shared
variables and has to be executed as an atomic action.
 It means that in a group of cooperating processes, at a given point
of time, only one process must be executing its critical section.
 If any other process also wants to execute its critical section, it
must wait until the first one finishes.
 The entry to the critical section is mainly handled by wait() function
while the exit from the critical section is controlled by the signal()
function.
 Critical section problem is to design protocol to solve this
 Each process must ask permission to enter critical section in entry
section, may follow critical section with exit section, then
remainder section.

Edition
Critical Section
 General structure of process Pi

Edition
Critical Section
 What happens if we remove the critical
section?
 So if we remove a critical section, all the
processes can access and modify shared
data at the same time so we can not
guarantee that the outcome will be true.

Edition
Critical-Section Problem (Cont.)
1. Mutual Exclusion - If process Pi is executing in its critical section,
then no other processes can be executing in their critical sections. Out
of a group of cooperating processes, only one process can be in its
critical section at a given point of time.
2. Progress - If no process is executing in its critical section and there
exist some processes that wish to enter their critical section, then the
selection of the process that will enter the critical section next cannot
be postponed indefinitely.
 If no process is in its critical section, and if one or more threads want to
execute their critical section then any one of these threads must be
allowed to get into its critical section.
 The decision of which process will enter the critical section will be
taken by only those processes that are not executing in the remaining
section.
There are basically three rules which need to be followed to solve
critical section problems.

Edition
Critical-Section Problem (Cont.)
3. Bounded Waiting - Starvation means a process keeps waiting forever
to access the critical section but never gets a chance. No starvation is
also known as Bounded Waiting.
• A bound must exist on the number of times that other processes
are allowed to enter their critical sections after a process has made
a request to enter its critical section and before that request is
granted
• Assume that each process executes at a nonzero speed
• A process should not wait forever to enter inside the critical
section.
• When a process submits a request to access its critical section,
there should be a limit or bound, which is the number of other
processes that are allowed to access the critical section before it.
• After this bound is reached, this process should be allowed to
access the critical section.
There are basically three rules which need to be followed to solve
critical section problems.

Edition
Solutions to Critical Section Problem
• Peterson’s solution
• Do not work well on modern computer architectures
Software Solution
• Memory Barriers
• Hardware Instructions
• Compare-and-swap instruction & atomic variables
Hardware Solution
• Requiring that a process acquire a lock before entering a critical section
and release the lock on exiting the critical section
Mutex Locks
• A binary value that indicates if the lock is available or not, a semaphore has an
integer value and can therefore be used to solve a variety of synchronization
problems.
Semaphores

Edition
Interrupt-based Solution
 Entry section: disable interrupts
 Exit section: enable interrupts
 Will this solve the problem?
 Unfortunately, this solution is not as feasible in a multiprocessor
environment.
 Disabling interrupts on a multiprocessor can be time consuming, since
the message is passed to all the processors.
 This message passing delays entry into each critical section, and
system efficiency decreases.
 Also consider the effect on a system’s clock if the clock is kept updated
by interrupts.
• What if the critical section is code that runs for an hour?
• Can some processes starve – never enter their critical section.
• What if there are two CPUs?

Edition
Software Solution 1
 Two process solution
 Assume that the load and store machine-language
instructions are atomic; that is, cannot be interrupted
 The two processes share one variable:
• int turn;
 The variable turn indicates whose turn it is to enter the
critical section
 initially, the value of turn is set to i

Edition
Algorithm for Process Pi
while (true){
while (turn = = j);
/* critical section */
turn = j;
/* remainder section */
}

Edition
Correctness of the Software Solution
 Mutual exclusion is preserved
Pi enters critical section only if:
turn = i
and turn cannot be both 0 and 1 at the same time
 What about the Progress requirement?
 What about the Bounded-waiting requirement?

Edition
Peterson’s Solution
 Two process solution
 Assume that the load and store machine-language
instructions are atomic; that is, cannot be interrupted
 The two processes share two variables:
• int turn;
• boolean flag[2]
 The variable turn indicates whose turn it is to enter the
critical section
 The flag array is used to indicate if a process is ready to
enter the critical section.
• flag[i] = true implies that process Pi is ready!

Edition
Algorithm for Process Pi
while (true){
flag[i] = true;
turn = j;
while (flag[j] && turn = = j)
;
flag[i] = false;
}

Edition
Correctness of Peterson’s Solution
 To prove property 1, we note that each Pi enters its critical section
only
if either flag[j] == false or turn == i.
 Also note that, if both processes can be executing in their critical
sections at the same time, then flag[0] == flag[1] == true.
 These two observations imply that P0 and P1 could not have
successfully executed their while statements at about the same time,
since the value of turn can be either 0 or 1 but cannot be both.
 Hence, one of the processes—say, Pj —must have successfully
executed the while statement, whereas Pi had to execute at least one
additional statement (“turn == j”).
 However, at that time, flag[j] == true and turn == j, and this condition
will persist as long as Pj is in its critical section; as a result, mutual
exclusion is preserved

Edition
 To prove properties 2 and 3, we note that a process Pi can be
prevented from entering the critical section only if it is stuck in the
while loop with the condition flag[j] == true and turn == j; this loop is
the only one possible.
 If Pj is not ready to enter the critical section, then flag[j] == false, and
Pi can enter its critical section.
 If Pj has set flag[j] to true and is also executing in its while statement,
then either turn == i or turn == j. If turn == i, then Pi will enter the
critical section. If turn == j, then Pj will enter the critical section.
 However, once Pj exits its critical section, it will reset flag[j] to false,
allowing Pi to enter its critical section. If Pj resets flag[j] to true, it must
also set turn to i.
 Thus, since Pi does not change the value of the variable turn while
executing the while statement, Pi will enter the critical section
(progress) after at most one entry by Pj (bounded waiting).

Edition
 Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
Pi enters CS only if:
either flag[j] = false or turn = i
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met

Edition
Peterson’s Solution and Modern Architecture
 Although useful for demonstrating an algorithm, Peterson’s
Solution is not guaranteed to work on modern architectures.
• To improve performance, processors and/or compilers may
reorder operations that have no dependencies
 Understanding why it will not work is useful for better
understanding race conditions.
 For single-threaded this is ok as the result will always be the same.
 For multithreaded the reordering may produce inconsistent or
unexpected results!

Edition
Modern Architecture Example
 Two threads share the data:
boolean flag = false;
int x = 0;
 Thread 1 performs
while (!flag)
;
print x
 Thread 2 performs
x = 100;
flag = true
 What is the expected output?
100

Edition
Modern Architecture Example (Cont.)
 However, since the variables flag and x are independent
of each other, the instructions:
flag = true;
x = 100;
for Thread 2 may be reordered
 If this occurs, the output may be 0!

Edition
Peterson’s Solution Revisited
 The effects of instruction reordering in Peterson’s Solution
 This allows both processes to be in their critical section at the same
time!
 To ensure that Peterson’s solution will work correctly on modern
computer architecture we must use Memory Barrier.

Edition
Synchronization Hardware
 Many systems provide hardware support for implementing the
critical section code.
 Uniprocessors – could disable interrupts
• Currently running code would execute without preemption
• Generally too inefficient on multiprocessor systems
 Operating systems using this not broadly scalable
 We will look at the following forms of hardware support:
1. Memory Barriers
2. Hardware instructions
3. Atomic variables

Edition
Memory Barrier
 Memory model are the memory guarantees a computer
architecture makes to application programs.
 Memory models may be either:
• Strongly ordered – where a memory modification of one
processor is immediately visible to all other processors.
• Weakly ordered – where a memory modification of one
processor may not be immediately visible to all other
processors.
 A memory barrier is an instruction that forces any change in
memory to be propagated (made visible) to all other processors.

Edition
Memory Barrier Instructions
 When a memory barrier instruction is performed, the system
ensures that all loads and stores are completed before any
subsequent load or store operations are performed.
 Therefore, even if instructions were reordered, the memory barrier
ensures that the store operations are completed in memory and
visible to other processors before future load or store operations
are performed.
 Note that memory barriers are considered very low-level
operations and are typically only used by kernel developers when
writing specialized code that ensures mutual exclusion.

Edition
Memory Barrier Example
 Returning to the example of slides 6.17 - 6.18
 We could add a memory barrier to the following instructions
to ensure Thread 1 outputs 100:
 Thread 1 now performs
while (!flag)
memory_barrier();
print x
 Thread 2 now performs
x = 100;
memory_barrier();
flag = true
 For Thread 1 we are guaranteed that that the value of flag
is loaded before the value of x.
 For Thread 2 we ensure that the assignment to x occurs
before the assignment flag.

Edition
Hardware Instructions
 Special hardware instructions that allow us to either
test-and-modify the content of a word, or to swap the
contents of two words atomically (uninterruptedly.)
• Test-and-Set instruction
• Compare-and-Swap instruction

Edition
The test_and_set Instruction
 Definition
boolean test_and_set (boolean
*target)
{
boolean rv = *target;
*target = true;
return rv:
}
 Properties
• Executed atomically
• Returns the original value of passed parameter
• Set the new value of passed parameter to true

Edition
Solution Using test_and_set()
 Shared boolean variable lock, initialized to false
 Solution:
do {
while (test_and_set(&lock))
; /* do nothing */
lock = false;
} while (true);
 Does it solve the critical-section problem?

Edition
Solution Using test_and_set()
 Here, the shared variable is lock which is initialized to false.
 TestAndSet(lock) algorithm works in this way – it always returns
whatever value is sent to it and sets lock to true.
 The first process will enter the critical section at once as
TestAndSet(lock) will return false and it’ll break out of the while
loop.
 The other processes cannot enter now as lock is set to true and
so the while loop continues to be true. Mutual exclusion is
ensured.
 Once the first process gets out of the critical section, lock is
changed to false. So, now the other processes can enter one by
one. Progress is also ensured.
 However, after the first process, any process can go in. There is
no queue maintained, so any new process that finds the lock to
be false again can enter. So bounded waiting is not ensured.

Edition
The compare_and_swap Instruction
 Definition
int compare_and_swap(int *value, int expected, int new_value)
{
int temp = *value;
if (*value == expected)
*value = new_value;
return temp;
}
 Properties
• Executed atomically
• Returns the original value of passed parameter value
• Set the variable value the value of the passed parameter
new_value but only if *value == expected is true. That is, the
swap takes place only under this condition.

Edition
Solution using compare_and_swap
 Shared integer lock initialized to 0;
 Solution:
while (true){
while (compare_and_swap(&lock, 0, 1) != 0)
; /* do nothing */
lock = 0;
}
 Does it solve the critical-section problem?

Edition
Bounded-waiting with compare-and-swap
 Swap algorithm is a lot like the TestAndSet algorithm.
 Instead of directly setting lock to true in the swap function, key is set
to true and then swapped with lock.
 First process will be executed, and in while(key), since key=true ,
swap will take place and hence lock=true and key=false.
 Again next iteration takes place while(key) but key=false , so while
loop breaks and first process will enter in critical section.
 Now another process will try to enter in Critical section, so again
key=true and hence while(key) loop will run and swap takes place so,
lock=true and key=true (since lock=true in first process).
 Again on next iteration while(key) is true so this will keep on executing
and another process will not be able to enter in critical section.
 Therefore Mutual exclusion is ensured.
 Again, out of the critical section, lock is changed to false, so any
process finding it gets t enter the critical section. Progress is ensured.
 However, again bounded waiting is not ensured for the very same
reason.

Edition
Atomic Variables
 Typically, instructions such as compare-and-swap are used
as building blocks for other synchronization tools.
 It is important to note that although atomic variables provide
atomic updates, they do not entirely solve race conditions in
all circumstances.
 One tool is an atomic variable that provides atomic
(uninterruptible) updates on basic data types such as
integers and booleans.
 For example:
• Let sequence be an atomic variable
• Let increment() be operation on the atomic variable
sequence
• The Command:
increment(&sequence);
ensures sequence is incremented without interruption:

Edition
Mutex Locks
 Previous solutions are complicated and generally inaccessible to
application programmers
 OS designers build software tools to solve critical section problem
 Simplest is mutex lock
• Boolean variable indicating if lock is available or not
 Protect a critical section by
• First acquire() a lock
• Then release() the lock
 Calls to acquire() and release() must be atomic
• Usually implemented via hardware atomic instructions such as
compare-and-swap.
 But this solution requires busy waiting
• This lock therefore called a spinlock

Edition
Mutex Locks – Busy Waiting
 While a process is in its critical section, any other process that tries to
enter its critical section must loop continuously in the call to acquire().
 This continual looping is clearly a problem in a real multiprogramming
system, where a single CPU core is shared among many processes.
 Busy waiting also wastes CPU cycles that some other process might
be able to use productively
 The type of mutex lock we have been describing is also called a
spinlock because the process “spins” while waiting for the lock to
become available

Edition
Solution to CS Problem Using Mutex Locks
while (true) {
acquire lock
critical section
release lock
remainder section
}

Edition
Semaphore
 Synchronization tool that provides more sophisticated ways (than
Mutex locks) for processes to synchronize their activities.
 A semaphore is a signaling mechanism, and a process can signal a
process that is waiting on a semaphore.
 This differs from a mutex in that the mutex can only be notified by the
process that sets the shared lock.
 Semaphores make use of the wait() and signal() functions for
synchronization among the processes.
 There are two kinds of semaphores: Counting & Binary

Edition
Semaphore (Cont.)
 Counting semaphore – integer value can range over
an unrestricted domain
 Binary semaphore – integer value can range only
between 0 and 1
• Same as a mutex lock
 Can implement a counting semaphore S as a binary
semaphore
 With semaphores we can solve various synchronization
problems

Edition
Binary Semaphore
 Binary Semaphores can only have one of two values: 0 or 1. Because
of their capacity to ensure mutual exclusion, they are also known as
mutex locks.
 A single binary semaphore is shared between multiple processes.
 When the semaphore is set to 1, it means some process is working on
its critical section, and other processes need to wait, and if the
semaphore is set to 0, that means any process can enter the critical
section.
 Hence, whenever the binary semaphore is set to 0, any process can
then enter its critical section by setting the binary semaphore to 1.
When it has completed its critical section, it can reset the binary
semaphore to 0, enabling another process to enter it.

Edition
Counting Semaphore
 Counting Semaphores can have any value and are not limited to a
certain area. They can be used to restrict access to a resource that
has a concurrent access limit.
 Initially, the counting semaphores are set to the maximum amount of
processes that can access the resource at a time.
 Hence, the counting semaphore indicates that a process can access
the resource if it has a value greater than 0. If it is set to 0, no other
process can access the resource. Hence,
 When a process wants to use that resource, it first checks to see if the
value of the counting semaphore is more than zero.
 If yes, the process can then proceed to access the resource, which
involves reducing the value of the counting semaphore by one.
 When the process completes its critical section code, it can increase
the value of the counting semaphore, making way for some other
process to access it.
 We use the functions WAIT() and SIGNAL() to control the semaphore

Edition
Monitors
 A high-level abstraction that provides a convenient and effective
mechanism for process synchronization
 Abstract data type, internal variables only accessible by code within
the procedure
 Only one process may be active within the monitor at a time
 Pseudocode syntax of a monitor:
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
procedure P2 (…) { …. }
procedure Pn (…) {……}
initialization code (…) { … }
}

Edition
Schematic view of a Monitor
A monitor is an additional "superstructure"
over a mutex.

Edition
Liveness
 Processes may have to wait indefinitely while trying to acquire a
synchronization tool such as a mutex lock or semaphore.
 Waiting indefinitely violates the progress and bounded-waiting criteria
discussed at the beginning of this chapter.
 Liveness refers to a set of properties that a system must satisfy to
ensure processes make progress.
 Indefinite waiting is an example of a liveness failure.

Edition
 Deadlock – two or more processes are waiting indefinitely for an
event that can be caused by only one of the waiting processes
 Let S and Q be two semaphores initialized to 1
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
... ...
signal(S); signal(Q);
signal(Q); signal(S);
 Consider if P0 executes wait(S) and P1 wait(Q). When P0 executes
wait(Q), it must wait until P1 executes signal(Q)
 However, P1 is waiting until P0 execute signal(S).
 Since these signal() operations will never be executed, P0 and P1 are
deadlocked.
Liveness

Edition
 Other forms of deadlock:
 Starvation – indefinite blocking
• A process may never be removed from the semaphore queue in
which it is suspended
 Priority Inversion – Scheduling problem when lower-priority process
holds a lock needed by higher-priority process
• Solved via priority-inheritance protocol
Liveness

Edition
 Software solutions to the critical-section problem, such as Peterson’s
solution, do not work well on modern computer architectures.
 Hardware support for the critical-section problem includes memory
barriers; hardware instructions, such as the compare-and-swap
instruction; and atomic variables.
 A mutex lock provides mutual exclusion by requiring that a process
acquire a lock before entering a critical section and release the lock on
exiting the critical section.
 Semaphores, like mutex locks, can be used to provide mutual
exclusion. However, whereas a mutex lock has a binary value that
indicates if the lock is available or not, a semaphore has an integer
value and can therefore be used to solve a variety of synchronization
problems.
 A monitor is an abstract data type that provides a high-level form of
process synchronization. A monitor uses condition variables that allow
processes to wait for certain conditions to become true and to signal
one another when conditions have been set to true.
 Solutions to the critical-section problem may suffer from liveness
problems, including deadlock
Summary

Lecture Week 6 Process Synchronisation.pptx

More Related Content

Similar to Lecture Week 6 Process Synchronisation.pptx (20)

Recently uploaded (20)

Lecture Week 6 Process Synchronisation.pptx