Process Synchronization -1.ppt

Process Synchronization
 Background
 The Critical-Section Problem
 Peterson’s Solution
 Synchronization Hardware
 Semaphores
 Classic Problems of Synchronization
 Monitors
 Synchronization Examples
 Atomic Transactions

Objectives
 To introduce the critical-section problem, whose solutions can be used
to ensure the consistency of shared data
 To present both software and hardware solutions of the critical-section
problem
 To introduce the concept of an atomic transaction and describe
mechanisms to ensure atomicity

Background
 Concurrent access to shared data may result in data inconsistency
 Maintaining data consistency requires mechanisms to ensure the
orderly execution of cooperating processes
 Suppose that we wanted to provide a solution to the consumer-
producer problem that fills all the buffers. We can do so by having an
integer count that keeps track of the number of full buffers. Initially,
count is set to 0. It is incremented by the producer after it produces a
new buffer and is decremented by the consumer after it consumes a
buffer.

Producer
while (count == BUFFER.SIZE)
; // do nothing
// add an item to the buffer
buffer[in] = item;
in = (in + 1) % BUFFER.SIZE;
++count;

Consumer
while (count == 0)
; // do nothing
// remove an item from the
buffer item = buffer[out];
out = (out + 1) % BUFFER.SIZE;
--count;

Race Condition
• When more than one process is executing the same code or
accessing the same memory or any shared variable in that
condition there is a possibility that the output or the value of the
shared variable is wrong so for that all the processes doing the
race to say that my output is correct this condition known as a
race condition. In this Example Shared = 5, Both Process p1 and
P2 using this variable concurrently so we are getting wrong
result.

Race Condition
 count++ could be implemented as
register1 = count
register1 = register1 + 1
count = register1
 count-- could be implemented as
register2 = count
register2 = register2 - 1
count = register2
 Consider this execution interleaving with “count = 5” initially:
T0: producer execute register1 = count {register1 = 5}
T1: producer execute register1 = register1 + 1 {register1 = 6}
T2: consumer execute register2 = count {register2 = 5}
T3: consumer execute register2 = register2 - 1 {register2 = 4}
T4: producer execute count = register1 {count = 6 }
T5: consumer execute count = register2 {count = 4}

Solution to Critical-Section Problem
1. Mutual Exclusion - If process Pi is executing in its critical section, then
no other processes can be executing in their critical sections.
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 processes that will enter the critical section next
cannot be postponed indefinitely.
3. 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.

Structure of a Typical Process

Critical Section solution
Using Lock
• This is a Software Mechanism implemented in
User mode.
• A Lock variable lock is used. Two values of lock
can be possible, either 0 or 1. Lock value 0
means that the critical section is vacant while
the lock value 1 means that it is occupied.
• A process which wants to get into the critical
section first checks the value of the lock
variable. If it is 0 then it sets the value of lock as
1 and enters into the critical section, otherwise it
waits.

Critical Section solution using Lock
Entry Section →
While (lock= = 1);
Lock = 1;
//Critical Section
Exit Section →
Lock =0;
 The lock variable mechanism doesn't guarantee
the mutual exclusion.

Using Test and set
• Hardware instructions that help in the effective solution of
critical section problems.
• 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.
• processes can enter one by one. Progress is also
ensured.
• 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.

Using Test and set
//Shared variable lock initialized to false
boolean lock;
while(1)
{
while (TestAndSet(&lock));
critical section
lock = false;
remainder section
}
boolean TestAndSet (boolean *target)
{
boolean r = *target;
target = true;
return r;
}

Turn Variable
(Strict Alteration)
• Turn Variable or Strict Alternation Approach is the software
mechanism.
• It is a busy waiting solution which can be implemented only for two
processes.
• In this approach, A turn variable is used which is actually a lock.
• For Process 1
while (turn ! = i);
Critical Section
turn = j;
• For Process 2
while (turn ! = j);
Critical Section
turn = i ;

Process Synchronization -1.ppt

Types of Semaphores
The two common kinds of semaphores are
• Counting semaphores
• Binary semaphores.
Counting Semaphore Binary Semaphore
No mutual exclusion Mutual exclusion
Any integer value Value only 0 and 1
Provide a set of Processes It has a mutual exclusion mechanism.
Counting Semaphore vs. Binary Semaphore

Mutex
A mutex provides mutual exclusion, either producer or consumer can
have the key (mutex) and proceed with their work. As long as the buffer
is filled by producer, the consumer needs to wait, and vice versa.
Binary Semaphore Mutex
Its functions based up on signalling
mechanism
Its functions based up on locking mechanism
The thread which is having higher priority
than current thread can also release binary
semaphore and take lock.
The thread which has acquired mutex can only release
Mutex when it exits from critical section.
Semaphore value is changed according to
wait () and signal () operations.
Mutex values can be modified just as locked or
unlocked.
Multiple number of threads can acquire binary
semaphore at a time concurrently.
Only one thread can acquire mutex at a time
They are faster than mutex because any
other thread/process can unlock binary
semaphore.
They are slower than binary semaphores because only
thread which has acquired must release the lock.
If you have number of instances for resource
it is better to use Binary semaphore.
If you have single instance for resource it is better to
use mutex.
Difference between binary semaphore and mutex :

Semaphore
• It is a mechanism that can be used to provide synchronization of
tasks.
• Semaphores are integer variables.
two atomic operations, wait and signal that are used for process
synchronization.
P(), Down, Wait (Entry)
V(), Up, Signal or post or release (Exit)
• The wait or Down operation decrements the value of its argument S,
if it is positive. If S is negative or zero, then no operation is
performed.
• The signal operation increments the value of its argument S.

Classical Problems of Synchronization
 Bounded-Buffer Problem
 Readers and Writers Problem
 Dining-Philosophers Problem
These problems are used for testing nearly every newly proposed
synchronization scheme.
 https://www.youtube.com/watch?v=hrmx1nwqKxs //Classical problem

Initial values
• Mutex = 1;
• Full = 0;
• Empty=n;
To solve the problem occurred above of race condition, we are
going to use Binary Semaphore and Counting Semaphore

Producer Code- solution
void producer( void )
{
down ( empty );
down(S);
Produce_item(item P)
buffer[ in ] = item P;
in = (in + 1)mod n
up(S);
up(full);
}
Consumer Code- solution
void consumer(void)
{
down (full );
down(S);
itemC = buffer[ out ];
out = ( out + 1 ) mod n;
up(S);
up(empty);
}

READERS WRITERS PROBLEM
The readers-writers problem is a classical problem of process
synchronization, it relates to a data set such as a file that is shared
between more than one process at a time. Among these various
processes, some are Readers - which can only read the data set; they
do not perform any updates, some are Writers - can both read and write
in the data sets.
Case Process 1 Process 2 Allowed / Not
Allowed
Case 1 Writing Writing Not Allowed
Case 2 Reading Writing Not Allowed
Case 3 Writing Reading Not Allowed
Case 4 Reading Reading Allowed
Mutex=1;
Readcount=0;
Write=1;

Reader Code Writer Code
wait (mutex);
readcount ++; // on each entry of reader
increment readcount
if (readcount == 1)
{
wait (write);
}
signal(mutex);
--READ THE FILE?
wait(mutex);
readcount --
; // on every exit of reader decrement rea
dcount
if (readcount == 0)
{
signal (write);
}
signal(mutex);
wait(write);
WRITE INTO THE FILE
signal(write);

THE DINING PHILOSOPHERS PROBLEM
The dining philosopher's problem is the classical problem of
synchronization which says that Five philosophers are sitting around
a circular table and their job is to think and eat alternatively.

Dining Philosophers Problem Solution Using Semaphore
Void Philosopher
{
while(1)
{
take_chopstick[i];
take_chopstick[ (i+1) % 5] ;
. .
. EATING THE NOODLE
.
put_chopstick[i] );
put_chopstick[ (i+1) % 5] ;
.
. THINKING
}
}
void Philosopher
{
while(1)
{
wait( take_chopstickC[i] );
wait( take_chopstickC[(i+1) % 5] ) ;
. .
. EATING THE NOODLE
.
signal( put_chopstickC[i] );
signal( put_chopstickC[ (i+1) % 5] ) ;
.
. THINKING
}
}

Disadvantages of Semephore
• There could be a situation of priority inversion where the
processes with low priority get access to the critical section than
those with higher priority.
• Semaphore programming is complex, and there is a risk that
mutual exclusion will not be achieved.
• The wait() and signal() methods must be conducted correctly to
avoid deadlocks.

Monitor
• It is a synchronization technique that enables threads to mutual
exclusion and the wait() for a given condition to become true.
• It is an abstract data type. It has a shared variable and a collection
of procedures executing on the shared variable.
• A process may not directly access the shared data variables, and
procedures are required to allow several processes to access the
shared data variables simultaneously.
• At any particular time, only one process may be active in a monitor.
Other processes that require access to the shared variables must
queue and are only granted access after the previous process
releases the shared variables.

Syntax:
The syntax of the monitor may be used as:
monitor {
//shared variable declarations
data variables;
Procedure P1() { ... }
Procedure P2() { ... }
.
.
.
Procedure Pn() { ... }
Initialization Code() { ... }
}

Process Synchronization -1.ppt

More Related Content

Similar to Process Synchronization -1.ppt (20)

Recently uploaded (20)

Process Synchronization -1.ppt