FALLSEM2023-24 BCSE303L TH VL2023240100787 2023-06-01 Reference-Material-I

Module 4
Concurrency
Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 1 / 79

Interprocess Communication
Concurrency is the execution of a set of multiple instruction sequences at the

same time.
This occurs when there are several process threads running in parallel.
These threads communicate with the other threads through a concept of shared
memory or through message passing.

Processes within a system may be independent or cooperating.

Cooperating process is one that can affect or be affected by other processes
executing in the system
Reasons for cooperating processes;
Information sharing
Computation speedup
Modularity
Convenience
Cooperating processes need Interprocess Communication (IPC)
Two models of IPC;
(1) Shared memory
(2) Message passing

Processes within a system may be independent or cooperating.

Cooperating process is one that can affect or be affected by other processes
executing in the system
Reasons for cooperating processes;
Information sharing
Computation speedup
Modularity
Convenience
Cooperating processes need Interprocess Communication (IPC)
Two models of IPC;
(1) Shared memory
(2) Message passing

Figure 1 : Communication models

Paradigm for cooperating processes: producer process produces information
that is consumed by a consumer process.
The Producer process creates an item and adds it to the shared buffer.
The Consumer process takes items out of the shared buffer and consumes
them.
Certain conditions must be met by the Producer and the Consumer processes
to have consistent data synchronization;
The Producer process must not produce an item if the shared buffer is full.
The Consumer process must not consume an item if the shared buffer is empty.
Access to the shared buffer must be mutually exclusive;
That is, at any given instance, only one process should be able to access the
shared buffer and make changes to it.

Two variations:
(1) unbounded-buffer
(2) bounded-buffer
Unbounded-buffer: places no practical limit on the size of the buffer
Producer never waits
Consumer waits if there is no buffer to consume
Bounded-buffer: assumes that there is a fixed buffer size
Producer must wait if all buffers are full
Consumer waits if there is no buffer to consume

Figure 2 : Code for the producer process
Figure 3 : Code for the consumer process

Suppose that we wanted to provide a solution to the consumer-producer prob-

lem that fills all the buffers.
We can do so by having an integer counter that keeps track of the number of
full buffers.
Initially, counter is set to 0.
The integer counter is incremented by the producer after it produces a new
buffer.
The integer counter is decremented by the consumer after it consumes a buffer.

IPC - Shared Memory: An area of memory shared among the processes that
wish to communicate.
The communication is under the control of the users processes not the oper-
ating system.
Major issues is to provide mechanism that will allow the user processes to
synchronize their actions when they access shared memory.

IPC - Message Passing: Processes communicate with each other without re-
sorting to shared variables
IPC facility provides two operations:
(1) send(message)
(2) receive(message)
The message size is either fixed or variable

If processes P and Q wish to communicate, they need to:

Establish a communication link between them
Exchange messages via send/receive
Implementation issues:
How are links established?
Can a link be associated with more than two processes?
How many links can be there between every pair of communicating processes?
What is the capacity of a link?
Is the size of a message that the link can accommodate fixed or variable?
Is a link unidirectional or bi-directional?

Implementation of Communication Link
Logical
Direct or indirect
Synchronous or asynchronous
Automatic or explicit buffering

Direct Communication
Processes must name each other explicitly;
send(P, message) - send a message to process P
receive(Q, message) - receive a message from process Q
Properties of communication link
Links are established automatically
A link is associated with exactly one pair of communicating processes
Between each pair there exists exactly one link
The link may be unidirectional

Indirect Communication
Messages are directed and received from mailboxes (also referred to as ports)
Each mailbox has a unique id
Processes can communicate only if they share a mailbox
Properties of communication link
Link established only if processes share a common mailbox
A link may be associated with many processes
Each pair of processes may share several communication links
Link may be unidirectional or bi-directional

Operations;
Create a new mailbox (port)
Send and receive messages through mailbox
Delete a mailbox
Primitives are defined as;
send(A, message) - send a message to mailbox A
receive(A, message) - receive a message from mailbox A

Mailbox sharing
P1 , P2 , and P3 share mailbox A
P1 , sends; P2 and P3 receive
Who gets the message?

Mailbox sharing
P1 , P2 , and P3 share mailbox A
P1 , sends; P2 and P3 receive
Who gets the message?
Solutions:
Allow a link to be associated with at most two processes
Allow only one process at a time to execute a receive operation
Allow the system to select arbitrarily the receiver. Sender is notified who the
receiver was.

Synchronization:
Message passing may be either blocking or non-blocking
Blocking is considered synchronous
Blocking send - the sender is blocked until the message is received
Blocking receive - the receiver is blocked until a message is available
Non-blocking is considered asynchronous
Non-blocking send - the sender sends the message and continue
Non-blocking receive - the receiver receives a valid message or null message

Buffering: Queue of messages attached to the link.

Implemented in one of three ways;
Zero capacity: no messages are queued on a link.
Sender must wait for receiver
Bounded capacity: finite length of n messages.
Sender must wait if link is full
Unbounded capacity: infinite length.
Sender never waits

Synchronization

Synchronization
Processes can execute concurrently

May be interrupted at any time, partially completing execution
Concurrent access to shared data may result in data inconsistency
Race Condition - Shared variable
Maintaining data consistency requires mechanisms to ensure the orderly exe-
cution of cooperating processes

Synchronization

Synchronization
Several processes access and manipulate the same data concurrently and out-
come of the execution depends on the particular order in which the access
takes place.
To guard against the race condition, we need to ensure that processes be
synchronized.

Synchronization
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
Figure 4 : Race condition when assigning a pid

Synchronization
Critical Section Problem: Consider a system consisting of n processes, {P0 , P1

. . . , Pn−1 }
Each process has a segment of code, called a critical section, in which the
process may be changing common variables, updating a table, writing a file,
so on.
The important feature of the system is that, when one process is executing in
its critical section, no other process is to be allowed to execute in its critical
section.
That is, no two processes are executing in their critical sections at the same
time.

The critical section problem is to design a protocol that the processes can use
to cooperate.
Each process must request permission to enter its critical section in entry
section.
The section of code implementing this request is entry section.
The critical section may be followed by an exit section, then remainder sec-
tion(remaining code).
Figure 5 : General structure of a typical process

Synchronization
A solution to the critical section problem must satisfy the following three re-
quirements;
Mutual Exclusion: If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections.
If one process is executing inside critical section then the other process must
not enter in the critical section.
Progress: If no process is executing in its critical section and some processes wish
to enter their critical sections, then only those processes that are not executing
in their remainder sections can participate in the decision on which will enter
its critical section next, and this selection cannot be postponed.
Progress means that if one process doesn’t need to execute into critical section
then it should not stop other processes to get into the critical section.
Bounded Waiting: 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.
The process must not be endlessly waiting for getting into the critical section.

Peterson’s Solution

A classic software based solution to the critical section problem is Petersons

Solution.
Peterson’s Solution is restricted to two processes that alternate execution be-
tween their critical sections and remainder sections.
It requires two data items to be shared between the two processes;
Let call the process Pi and Pj

The variable turn indicates whose turn it is to enter its critical section.
That is, if turn == i, then process Pi is allowed to execute in its critical
section.
The flag array is used to indicate if a process is ready to enter its critical
section.
That is, if flag [i] is true, this value indicates that Pi is ready to enter its critical
section.

To enter the critical section, process Pi first set flag [i] to be true and then
sets turn to the value j, thereby asserting that if the other process wishes to
enter the critical section, it can do so.
If both processes try to enter at the same time, turn will be set to both i and
j at roughly the same time.
Only one of these assignments will last; the other will occur but will be over-
written immediately.
The eventual value of turn decides which of the two processes is allowed to
enter its critical section first.

The properties are;

(1) Mutual exclusion is preserved
(2) The progrss requirement is satisfied
(3) The bounded-waiting requirement is met
Property1: Mutual Exclusion:
The process Pi , enters its critical section only if either
flag [j] = false or turn == i
If both processes can be executing in their critical sections at the same time,
then
flag [0] == flag [1] == true
These two observations implies 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.

Property 2 & 3:
The 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
If Pj is not ready to enter its critical section, then
flag [j] = false, and Pi can enter its critical section.
If Pj has set flag [j] to true and also executing in its while statement, then
either turn == i or turn == j
If turn == i , then Pi will enter the critical section and 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 Pi 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 atmost
one entry by Pj (bounded waiting).

Bakery Algorithm

Bakery Algorithm
Bakery Algorithm: Synchronization between more than two processes.

Bakery Algorithm
Processes numbered 0 to N − 1
num is an array of N integers.
Each entry corresponds to a process(initially 0)

Bakery Algorithm

Bakery Algorithm

Mutex Locks

Mutex Locks
Operating System designers build higher-level software tools to solve the

critical-section problem. The simplest of the tools is the Mutex(Mutual
exclusion) Lock.
A Mutex lock has a boolean variable available whose value indicates if the
lock is available or not.
If the lock is available, a call to acquire() succeeds, and the lock is then
considered unavailable.
A process that attempts to acquire an unavailable lock is blocked until the
lock is released.

Mutex Locks
Mutex lock is used to protect critical sections and thus prevent race conditions.
That is, a process must acquire the lock before entering a critical section; it
releases the lock when it exists the critical section.
The acquire() function acquires the lock, and the release() function releases
the lock as in Figure6
Figure 6 : Solution to the critical-section problem using mutex locks

Mutex Locks
The definition of acquire() is as follows;
The definition of release() is as follows;

Mutex Locks

Mutex Locks

Semaphores

Semaphores
Semaphore is a technique to manage concurrent process by using a simple

integer value, which is known as a Semaphore S.
Semaphore is simply a variable which is non negative and shared between
threads.
This variable is used to solve the critical section problem and to achieve process
synchronization in the multiprocessing environment.

Semaphores
A Semaphore S is an integer variable that, apart from initialization, is accessed

only through two standard atomic operations;
wait() and signal().
All modifications to the integer value of the semaphore in the wait() and
signal() operations must be executed atomically.
That is, when one process modifies the semaphore value, no other process can
simultaneously modify that same semaphore value.

Semaphores
The definition of wait() is as follows;
The definition of signal() is as follows;

Types of Semaphores
Binary Semaphore: The value of a binary semaphore can range only between
0 and 1.
On some systems, binary semaphores are known as mutex locks, as they are
the locks that provide mutual exclusion.
Counting Semaphore: Its value can range over an unrestriced domain.
It is used to control access to a resource that has multiple instances.

Classical Synchronization Problems

Classical problems used for testing newly proposed synchronization schemes

Bounded Buffer Problem
Readers and Writers Problem
Dining Philosophers Problem

Bounded Buffer Problem(Producer-Consumer Problem) is one of the classic

problem of synchronization.
There is a buffer of n slots and each slot is capable of storing one unit of data.
There are two processes running, producer and consumer, which are operating
on the buffer.

The producer tries to insert data into an empty slot of the buffer.
The consumer tries to remove data from a filled slot in the buffer.
Problems in bounded buffer

The producer must not insert data when the buffer is full.
The consumer must not remove data when the buffer is empty.
The producer and consumer should not insert and remove data simultaneously.

The producer and consumer processes share the following data structures;

The code for the producer process is shown in Figure7
Figure 7 : The structure of the producer process

The code for the consumer process is shown in Figure8
Figure 8 : The structure of the consumer process

Figure 9 : Bounded buffer problem

Readers-Writers Problem: A database is to be shared among several concurrent

processes.
Some of these processes may want only to read the database, whereas others
may want to update the database(read and write).
Distinguish between these two types of processes by referring to the former as
Readers and to the latter as Writers.
If two readers access the shared data simultaneously, no adverse effects will
result.
However, if a writer and some other thread(either a reader or writer) access
the database simultaneously, chaos may ensue.
To ensure that these difficulties do not rise, we require that the writers have
exclusive access to the shared database while writing to the database.
This synchronization problem is referred to as the readers-writers problem.

Using two semaphores and an integer variable

The code for the writer process is shown in Figure10
Figure 10 : The structure of the writer process

The code for the reader process is shown in Figure11
Figure 11 : The structure of the reader process

Figure 12 : Readers-Writers Problem

Dining-Philosophers Problem: Consider five philosophers who spend their lives
thinking and eating.
The philosophers share a circular table surrounded by five chairs, each belong-
ing to one philosopher.
In the center of the table is a bowl of rice and the table is laid with five single
chopsticks as in Figure13.
Figure 13 : The situation of the dining philosophers

Figure 14 : The state of philosophers

Figure 15 : The situation of the dining philosophers

One simple solution is to represent each fork or chopstick with a semaphore.

A philosopher tries to grab a chopstick by executing a wait() operation on that
semaphore.
He releases his chopstick by executing the signal() operation on the appropriate
semaphores.
Thus, the shared data are;
semaphore chopstick[5];
where all the elements of chopstick are initialized to 1.

Figure 16 : The structure of philosopher i

This solution guarantees that no two neighbors are eating simultaneously, it
could create a deadlock.
Suppose that all five philosophers become hungry simultaneously and each
grabs their left chopstick.
All the elements of chopstick will now be equal to 0.
When each philosopher tries to grab his right chopsticks, he will be delayed
forever.

Possible remedies to avoid deadlock;

Allow at most four philosophers to be sitting simultaneously at the table.
Allow a philosopher to pick up his chopsticks only if both chopsticks are avail-
able.
Use an asymmetric solution; that is, an odd philosopher picks up first his left
chopstick and then his right chopstick, whereas an even philosopher picks up
his right chopstick and then his left chopstick.

Monitors

Monitors
Timing errors can occur when either mutex locks or semaphores are used.
One strategy for dealing with such errors is to incorporate simple synchroniza-
tion tools as high-level language construct, the monitor type.
A high level abstraction that provides a convenient and effective mechanism
for process synchronization.
A monitor type presents a set of programmer defined operations that provide
mutual exclusion within the monitor.

The monitor type also contains the declaration of variables whose value define
the state of an instance of that type, along with the bodies of procedures or
functions that operate on those variables.
Figure 17 : Syntax of a monitor

A procedure defined within a monitor can access only those variables declared
locally within the monitor and its formal parameters.
Similarly, the local varaibles of a monitor can be accessed by only the local
procedures.
The monitor construct ensures that only one process at a time is active within
the monitor.

Condition Construct: The only operation that can be invoked on a condition
variable are wait() and signal().
condition x, y ;
The operation x.wait() means that the process invoking this operation is sus-
pended until another process invokes x.signal()
The x.signal() operation resumes exactly one suspended process.

Figure 18 : Schematic view of a monitor

Thank you
&
Queries

FALLSEM2023-24 BCSE303L TH VL2023240100787 2023-06-01 Reference-Material-I

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FALLSEM2023-24 BCSE303L TH VL2023240100787 2023-06-01 Reference-Material-I

Uploaded by

Copyright:

Available Formats

Module 4

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 1 / 79

Concurrency is the execution of a set of multiple instruction sequences at the

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 2 / 79

Processes within a system may be independent or cooperating.

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 3 / 79

Processes within a system may be independent or cooperating.

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 4 / 79

Figure 1 : Communication models

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 5 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 6 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 7 / 79

Figure 3 : Code for the consumer process

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 8 / 79

Suppose that we wanted to provide a solution to the consumer-producer prob-

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 9 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 10 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 11 / 79

If processes P and Q wish to communicate, they need to:

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 12 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 13 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 14 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 15 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 16 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 17 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 17 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 18 / 79

Buffering: Queue of messages attached to the link.

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 19 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 20 / 79

Processes can execute concurrently

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 21 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 22 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 23 / 79

Figure 4 : Race condition when assigning a pid

Critical Section Problem: Consider a system consisting of n processes, {P0 , P1

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 25 / 79

Figure 5 : General structure of a typical process

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 26 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 27 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 28 / 79

A classic software based solution to the critical section problem is Petersons

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 29 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 30 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 34 / 79

The properties are;

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 35 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 36 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 37 / 79

Bakery Algorithm: Synchronization between more than two processes.

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 38 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 39 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 40 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 41 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 42 / 79

Operating System designers build higher-level software tools to solve the

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 43 / 79

Figure 6 : Solution to the critical-section problem using mutex locks

The definition of acquire() is as follows;

The definition of release() is as follows;

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 45 / 79

Dr.S.Thamizharasan, Assistant Professor/SCOPE CSE303L - Operating Systems 46 / 79