1. Chapter 5 Concurrency: Mutual Exclusion and Synchronization
Operating Systems: Internals and Design Principles
Chapter 5 Concurrency: Mutual Exclusion and Synchronization
Seventh Edition
By William Stallings

2. Cooperating Processes
Independent process cannot affect or be affected by the execution of another process.
Cooperating process can affect or be affected by the execution of another process
Advantages of process cooperation
Information sharing
Computation speed-up via parallel sub-tasks
Modularity by dividing system functions into separate processes
Convenience - even an individual may want to edit, print and compile in parallel

3. Concurrent Process
Operating System design is concerned with the management of processes and threads:
Multiprogramming
multiple processes on a uniprocessor
Multiprocessing
multiple processes on a multiprocessor
Distributed Processing
Multiple processes on distributed processors

4. Principle of Concurrency
Interleaving and overlapping
can be viewed as examples of concurrent processing
both present the same problems
In uni-processor, basic characteristics of
multiprogramming − the relative speed of execution of processes cannot be predicted
depends on activities of other processes
the way the OS handles interrupts
scheduling policies of the OS
Interleave: insert pages, typically blank ones, between the pages using uniprocessor system.
Overlapped process: on multi processor system same or different process can be executed at the same time.

5. Terminologies
Synchronization — using atomic (indivisible) operations to ensure cooperation between Processes/threads
Mutual exclusion — ensures that only one thread does a particular activity at a time .All other threads are excluded from doing that activity
Critical section (region) — code that only one thread can execute at a time (e.g.,code that modifies shared data)
Lock — mechanism that prevents another thread from doing something:
Lock before entering a critical section
Unlock when leaving a critical section

6. Mutual Exclusion
How to implement Mutual Exclusion Implementation??

7. Mutual Exclusion
Lock ( acquire )
Lock ( Release )

8. Requirements for ME Must be enforced
A process that halts must do so without interfering with other processes
No deadlock or starvation
A process must not be denied access to a critical section when there is no other process using it
No assumptions are made about relative process speeds or number of processes
A process remains inside its critical section for a finite time only

9. Implementation of ME Only 2 processes, P1 and P2
General structure of process Pi (other process Pj)
do {
entry section
critical section
exit section
remainder section
} while (1);
Processes may share some common variables to synchronize their actions.

10. Initial Attempt do Process Pi Shared variables:
int turn; initially turn = 0
turn - i  Pi can enter its critical section
do Process Pi {
while (turn != i) ;
critical section
turn = j; //j == 1-i
remainder section
} while (1);
Satisfies mutual exclusion, but not progress – requires strict alternation of processes
If turn == 0 and P1 is ready to enter its critical section, it can not do so even though P0 is in its remainder section
1-process must have alternate chances to execute CS.
2-if process fails in its critical section or even outside the critical section?
2nd attempt: both enter their critical sections…..Worst!

11. Dekker’s algorithm (1965) Process P2 Boolean flag[1] == flag[2]==false
do {
flag [2]:= TRUE;
while(flag [1]
if(turn == 1)
{ flag[2]=false;
While (turn ==1 )
do_nothing;
flag[2]=true }
critical section
flag [2] = FALSE;
turn=1;
remainder section
} while (TRUE);
Boolean flag[1] == flag[2]==false
Int turn=1;
Process P1
do {
flag [1]:= TRUE; while (flag [2] )
if(turn == 2)
{ flag[1]=false;
While (turn==2)
do_nothing;
flag[1]=true }
critical section
flag [1] = FALSE;
turn=2;
remainder section
} while (TRUE);

12. Peterson’s algorithm (1981)
while (true) {
t1_in_crit = true;
turn = 2;
while (t2_in_crit == true && turn != 1)
/* do nothing */
… critical section of code …
t1_in_crit = false;
… other non-critical code … }
t2 ( ) {
while (true) {
t2_in_crit = true;
turn = 1;
while (t1_in_crit == true && turn != 2)
/* do nothing */
… critical section of code …
t2_in_crit = false;
… other non-critical code … }

13. Semaphores – Dijkstra (1965)
A variable that has an integer value upon which only three operations are defined:
May be initialized to a nonnegative integer value
The Wait(); operation decrements the value
The Signal(); operation increments the value
There are two types of semaphores: Counting Semaphore and Binary Semaphore.
Counting Semaphore can be used for mutual exclusion and conditional synchronization.
Binary Semaphore is specially designed for mutual exclusion.

14. Semaphores – Dijkstra (1965)
Synchronization tool that does not require busy waiting (spinlock).
Easier to generalize to more complex problems
When one process modifies the semaphore value, no other process can simultaneously modify that same semaphore value
Semaphore S
initialized to a non-negative integer value
wait operation decrements the semaphore value (P – proberen:to test)
If the value becomes negative then the process is blocked
signal operation increments the semaphore value (V- verhogen:to increment)
If the value is not positive then a process blocked by a wait is unblocked
A queue is used to hold the processes waiting on the semaphore and they are removed in a FIFO order
Strong semaphore specifies the order in which processes are removed from the queue and guarantees freedom from starvation, a weak semaphore does not specify an order and may be subject to starvation

15. Semaphore and ME

16. Deadlock & Starvation P0 P1
Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes – resource acquisition and release
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);
Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended (LIFO queue)

17. Producer/Consumer Problem
General Situation:
one or more producers are generating data and placing these in a buffer
a single consumer is taking items out of the buffer one at time
only one producer or consumer may access the buffer at one time
The Problem:
ensure that the producer can’t add data into full buffer and consumer can’t remove data from an empty buffer

18. Reader writer problem (Readers have priority)

19. Dining Philosophers
5 philosophers live together, and spend most of their lives thinking and eating(primarily spaghetti)
They all eat together at a large table, which is set with 5
plates and 5 forks
To eat, a philosopher goes to his or her assigned place, and
uses the two forks on either side of the plate to eat
spaghetti
When a philosopher isn’t eating, he or she is thinking

20. Dining Philosophers Shared data semaphore chopstick[5];
Problem:
Processes are competing for exclusive access to a limited number of resources
Philosophers eat/think
Eating needs 2 chopsticks
Pick up one chopstick at a time
How to prevent deadlock
Shared data
semaphore chopstick[5];
Initially all values are 1

21. Monitors
Programming language construct that provides equivalent functionality to that of semaphores and is easier to control
Implemented in a number of programming languages
including Concurrent Pascal, Pascal-Plus, Modula-2, Modula-3, and Java
Has also been implemented as a program library
Software module consisting of one or more procedures, an initialization sequence, and local data

22. Monitors

23. Monitors
Local data variables are accessible only by the monitor’s procedures and not by any external procedure
Process enters monitor by invoking one of its procedures
Only one process may be executing in the monitor at a time

24. Figures: Problem Solution Using a Monitor

25. Message Passing
When processes interact with one another two fundamental requirements must be satisfied:
Message Passing is one approach to providing both of these functions
works with distributed systems and shared memory multiprocessor and uni-processor systems
synchronization
to enforce mutual exclusion
communication
to exchange information

26. Message Passing
The actual function is normally provided in the form of a pair of primitives:
send (destination, message)
receive (source, message)
A process sends information in the form of a message to another process designated by a destination
A process receives information by executing the receive primitive, indicating the source and the message

27. Blocking Send, Blocking Receive
Both sender and receiver are blocked until the message is delivered
Sometimes referred to as a rendezvous
Allows for tight synchronization between processes
Thus, both the sender and receiver can be blocking or nonblocking. Three combinations are common, although any particular system will usually have only one or two combinations implemented:
• Blocking send, blocking receive: Both the sender and receiver are blocked until the message is delivered; this is sometimes referred to as a rendezvous . This combination allows for tight synchronization between processes.

28. Nonblocking Send Non-blocking send, non-blocking receive
Non-blocking send, blocking receive
sender continues on but receiver is blocked until the requested message arrives
most useful combination
sends one or more messages to a variety of destinations as quickly as possible
example -- a service process that exists to provide a service or resource to other processes
Non-blocking send, non-blocking receive
neither party is required to wait
Nonblocking send, blocking receive: Although the sender may continue on, the receiver is blocked until the requested message arrives. This is probably the most useful combination. It allows a process to send one or more messages to a variety of destinations as quickly as possible. A process that must receive a message before it can do useful work needs to be blocked until such a message arrives. An example is a server process that exists to provide a service or resource to other processes.
• Nonblocking send, nonblocking receive: Neither party is required to wait.
The nonblocking send is more natural for many concurrent programming tasks. For example, if it is used to request an output operation, such as printing, it allows the requesting process to issue the request in the form of a message and then carry on. One potential danger of the nonblocking send is that an error could lead to a situation in which a process repeatedly generates messages. Because there is no blocking to discipline the process, these messages could consume system resources, including processor time and buffer space, to the detriment of other processes and the OS. Also, the nonblocking send places the burden on the programmer to determine that a message has been received: Processes must employ reply messages to acknowledge receipt of a message.
For the receive primitive, the blocking version appears to be more natural for many concurrent programming tasks. Generally, a process that requests a message will need the expected information before proceeding. However, if a message is lost, which can happen in a distributed system, or if a process fails before it sends an anticipated message, a receiving process could be blocked indefinitely. This problem can be solved by the use of the nonblocking receive . However, the danger of this approach is that if a message is sent after a process has already executed a matching receive , the message will be lost. Other possible approaches are to allow a process to test whether a message is waiting before issuing a receive and
allow a process to specify more than one source in a receive primitive. The latter approach is useful if a process is waiting for messages from more than one source
and can proceed if any of these messages arrive.

29. Message Format

30. Sending Messages Addressing

31. Indirect addressing
Messages are sent to a shared data structure consisting of queues that can temporarily hold messages
Queues are referred to as mailboxes
One process sends a message to the mailbox and the other process picks up the message from the mailbox
Allows for greater flexibility in the use of messages

32. Message passing & ME

33. Summary Operating system themes are: Mutual Exclusion Semaphores
Messages
Useful for the enforcement of mutual exclusion discipline
Operating system themes are:
Multiprogramming, multiprocessing, distributed processing
Fundamental to these themes is concurrency
issues of conflict resolution and cooperation arise
Mutual Exclusion
Condition in which there is a set of concurrent processes, only one of which is able to access a given resource or perform a given function at any time
One approach involves the use of special purpose machine instructions
Semaphores
Used for signaling among processes and can be readily used to enforce a mutual exclusion discipline
Chapter 5 Summary.