Process Synchronisation – Part ½

Lecture 4

Soumyabrata DEV
https://soumyabrata.dev/
Concurrent Execution

2
Concurrent execution

• Concurrent execution refers to the simultaneous execution of

multiple tasks or processes in a computer system, allowing them to
progress independently and appear as if they are running
concurrently.
• Concurrent execution is valuable because it can enhance system
performance, responsiveness, and resource utilization.
• It allows computers to efficiently handle multiple tasks, such as
running multiple applications simultaneously, responding to user
input, and managing background processes.

3
Concurrent execution
Concurrent execution can be achieved via different ways:

1.Multi-Core Processors: In systems with multi-core processors, each core can

execute its own set of instructions independently. This allows multiple
threads or processes to run in parallel, making use of the available cores.
2.Time-Sharing: In time-sharing systems, the CPU rapidly switches between
executing different processes or threads. Each process is allocated a small
time slice (time quantum) during which it can execute. This gives the illusion
of concurrent execution, even on single-core processors.
3.Parallel Processing: In specialized computing environments, tasks can be
divided into smaller sub-tasks that can be executed in parallel on multiple
processors or cores. This approach is used in scientific computing,
simulations, and high-performance computing.
4.Concurrency Control: In database systems and other applications,
concurrent execution refers to multiple users or processes accessing and
modifying shared resources, such as a database. Concurrency control
mechanisms ensure that these operations occur in a controlled and orderly
manner to prevent data inconsistencies.

4
Concurrent Execution

• Concurrent Execution is when two processes are executing at the

same time

• Each cooperative processes may affect the execution of the other

process

5
 Concurrent Execution Example
sic Example of Concurrent Execution

int A;
Process 1 Process 2
A = 1; A = 2;
if(A == 1) if(A == 2)
printf(“Process 1 wins”); printf(“Process 2 wins”);

Variable A is shared by the two processes

When the two processes are run concurrently on one 6
Concurrent Execution Example

• The variable A is shared by both processes

• When both processes are run concurrently on one processor, which

one "wins"?
• the outcome of the concurrent execution depends on which assignment
takes place first (race condition)

7
What about threads?

• If we replace the processes with threads the outcome will be still the
same

8
Atomic Operations

• Is it possible to get a different value in the variable A if we try and

execute the two assignments statements at the same time?

• E.g. A = 1 and A = 2 happen at the same time

9
Atomic Operations

• It is not possible.

• References and assignments are all atomic in the CPU

• This means all read and write operations happen as a single step

10
Atomic Operations

• An atomic operation cannot be interrupted

• This is to prevent illogical things happening

11
Atomic Instructions

• This atomicity is provided by hardware

• Higher-level constructs are not atomic in general

• A higher-level construct is any sequence of two or more instructions

12
Higher-Level Example
Higher-level of Concurrent Execution
Example

int B;
Process 1 Process 2
B = 0; B = 0;
while(B < 10) B++; while(B > −10) B– –;
printf(“Process 1 finished”); printf(“Process 2 finished”);

Ê Variable
Variable B isBshared
is shared
post increments/decrements (“B++”, “B– –”) are atomic
Ê But increments and decrements are atomic
Are there race conditions in this example?
Ê Will the process finish?
will the processes finish?
13
 Higher-level
Higher-Level Example
Example of Concurrent Execution

int B;
Process 1 Process 2
B = 0; B = 0;
while(B < 10) B++; while(B > −10) B– –;
printf(“Process 1 finished”); printf(“Process 2 finished”);

Ê The while
Variable sections above are not atomic
B is shared
post increments/decrements (“B++”, “B– –”) are atomic
Ê The process theoretically might never reach
Are there race conditions in this example?
10willorthe-10
processes finish?

14
 Higher-level
Higher-Level Example
Example of Concurrent Execution

int B;
Process 1 Process 2
B = 0; B = 0;
while(B < 10) B++; while(B > −10) B– –;
printf(“Process 1 finished”); printf(“Process 2 finished”);
Ê Process synchronisation is all about
Variable B is shared
making high-level constructs
post increments/decrements behave
(“B++”, “B– –”) are atomic
atomically
Are there race conditions in this example?
will the processes finish?

15
Mutual Exclusion & Critical
Section

16
What are these?
Mutual Exclusion and Critical Section are concepts related to
concurrent programming and synchronization in operating systems:
Mutual Exclusion (Mutex):
• Definition: Mutual exclusion is a fundamental concept that ensures
that only one process or thread accesses a shared resource or enters
a critical section at a time, preventing concurrent access by multiple
entities.

Critical Section:
• Definition: A critical section is a portion of code within a program
where shared resources are accessed, and data may be modified. It's
a region of code that should be executed atomically, meaning that no
other process or thread should be able to access it simultaneously.

17
The Milk Problem

• Two flat mates sharing a fridge

• They want to have at most one bottle of milk in the fridge at any time

18
 Possible Events

Time Flatmate A Flatmate B

10:00 Check the fridge: NO MILK
10:05 Walk to Shop Check the fridge: NO MILK
10:10 Arrive at the shop; buy Walk to Shop
milk
10:15 Arrive home; put milk in Arrive at the shop; buy milk
fridge
10:20 Arrive home; put milk in fridge
TOO MUCH MILK

19
The Milk Problem

• The reason for this problem is that the behaviour of

A and B is not atomic

• To solve this problem A and B must synchronise

(cooperate)

20
Important Definitions

• Synchronisation: ensuring proper cooperation among

processes (or threads), by relying on atomic operations

• Mutual exclusion (ME): ensuring that only one process

at a time holds or modifies a shared resource
• ME ensures atomicity

• Critical section (CS): a section of code in a program in

which shared resources are manipulated

Mutual exclusion in a critical section requires

serialisation of process access to the critical section

21
Critical Section

22
Milk Problem

• The critical section is

• Check fridge, go shopping, put milk in fridge

• Mutual exclusion:
• Only let one flatmate do this at a time

23
Locking and Mutual Exclusion

• Achieving mutual exclusion in a critical section

always involve some sort of locking mechanism

• Locking is where we prevent someone else for

doing something with the shared resource

24
Locking Rules

•Locking involves three rules:

1. You must lock before you enter a critical

section

2. You must unlock when leaving a critical section

3. You must wait when trying to enter critical

section if it is locked

25
Milk Problem Lock

1. Leave note before going shopping (“gone

shopping”)

2. Remove note after shopping

3. Don’t go shopping if note has been left

26
Milk Problem (1st Solution Attempt)

• Let both A and B execute (in a closed loop)

if(no_milk) {
if(no_note) {
put note;
buy milk;
remove note;
}
}

27
Milk Problem (1st Solution Attempt)

• Mutual exclusion is not guaranteed

• A and B could execute "if(no_note)" before the note is put
on the fridge

• This is really hard to debug

• It might work most of the time but occasionally fail

28
Milk Problem (2nd Attempt)

• As a workaround, let us change the meaning of the

note:

• B buys if there is a note

• A buys if there is no note

29
Milk Problem (2nd Attempt)

Process A Process B
if(no_note) { if(note) {
if(no_milk) { if(no_milk) {
buy milk; buy milk;
add note; remove note;
} }
} }

30
Milk Problem (2nd Attempt)

• Is the critical section mutually exclusive?

• Yes, but what happens if B goes on holidays?

• A cannot buy any milk!

31
Milk Problem (2nd Attempt)

• We have the same problem if B is very slow

• The relative speed of processes can be an issue

• Processes taking turns to be in the critical section

• This means that the same flatmate cannot buy milk twice
in a row

32
Milk Problem (3rd Attempt)

• In order to try to avoid the last issue, let us use two notes (note_A
and note_B) and some basic courtesy protocol
• Each process can now examine each other’s status, but not modify it.

33
Milk Problem (3rd Attempt)

Process A Process B
put note_A; put note_B;
if(no_note_B) { if(no_note_A) {
if(no_milk) if(no_milk)
{ {
buy milk; buy milk;
} }
} }
remove note_A; remove note_B;

34
Milk Problem (3rd Attempt)

• Does this work?

• Better than before.

• Relative speed is still an issue
• What happens if they both leave notes at the exact same time?

35
Milk Problem (4th Attempt)

• Two processes use slightly different code

• One process stays the same as before
• The other waits until the note is removed

36
Process A Process B

put note_A; put note_B;

if(no_note_B) { if(no_note_A) {
if(no_milk) if(no_milk) {
buy milk; buy milk;
} else { }
while(note_B){ }
} % note_B is now removed remove note_B;
if(no_milk)
buy milk;
}
remove note_A;

37
Milk Problem (4th Attempt)

• Is this a solution?
• It was actually the first solution ever given to the mutual exclusion problem
• But it is not satisfactory

38
Issues with the Solution

• The solution is complicated and just for this problem

• We need to pay careful attention to make sure that it really works
• A similar solution might not be good for more complex problems

39
Issues with the Solution

• The solution is asymmetric

• Not everybody is performing the same steps

• The solution is not scalable

• How would we make it work for more people sharing milk

• The solution is inefficient

• While A is waiting it is consuming processor time
• Called busy-waiting

40
Consequence

• Because of the problems with the 4th solution, it is necessary to have

standard synchronisation mechanisms in an operating system

• These can automatically fulfill some minimum requirements

41
Requirements for True Solution for Critical Section (CS)

1. Mutual exclusion
• One process at most inside the CS at any time

2. Bounded waiting (no starvation)

• A process attempting to enter its CS will eventually do so

3. Progress
• A process executing outside a CS cannot prevent another process from
entering it

• If several processes are attempting to enter a CS at the same time the

decision on which one goes in cannot be indefinitely postponed

• A process can't stay inside its CS forever (or exit in there)

42
Requirements for True Solution for CS

• These conditions are necessary and sufficient for process

synchronisation
• Provided that basic operations are atomic

• No assumptions are made about:

• number of processes,
• relative speed of processes,
• or underlying hardware

43
Desirable Properties of a Mutual Exclusion (ME) Mechanism

• Simple

• Systematic and easy to use

• E.g. just bracket the critical section

• Easy to maintain
• Efficient
• Does not use a lot of resources while waiting
• No busy-waiting

• Overhead due to entering and leaving critical sections has to be small

• At least smaller than the work inside it

• Scalable:
• It should work when many threads share the critical section

44
Implementations

There are three basic mechanisms for implementing mutual

exclusion in critical sections

1. Semaphores
• Simple, but hard to program with
• Very low level

2. Monitors
• Higher level mechanism
• Requires higher-level programming languages

3. Messages
• Synchronisation without shared memory
• Uses IPC messages instead
45
 Thank you!

See you next class!

25 September, Monday, 8am to 9:35am, TB3-202

46