You are on page 1of 7

Process Synchronization Notes

Why Synchronization?

What could happen because of Shared Memory?

• Final Value of Shared Variable depends

• On the Order of Execution of Instructions

• On which instruction the process is preempted

Race Condition

• Situation when several processes access and manipulate the same data

• O/P depends on the order in which the accesses to the data took place.

Critical Section

• It is the part of the program where shared resources are accessed.

Synchronization

• Ensure only one process manipulates the shared data at a time

Solution to Critical Section Problem

• Any solution should satisfy the following requirements

• Mutual Exclusion

• No more than one process in critical section at a given time

• Progress

• When no process is in the critical section, any process that requests enter
into the Critical Section must be permitted without any delay

• No starvation (bounded wait)

Page 1 of 7
• There is an upper bound on the number of times a process enters the critical
section, while another is waiting

• process should not wait infinitely in order to gain access into the Critical
Section

Software Based Synchronization Solutions

Software Solution - 1

Software Solution – 2

Page 2 of 7
Software Solution – 3

Deadlock situation in Solution - 3

Software Solution – 4 (Peterson’s Solution)

Page 3 of 7
Peterson’s solution works efficiently for two processes

To solve synchronization problem when there are multiple processes in a system

 Bakery Algorithm

Hardware Based Synchronization Solutions

Why the Previous Software Solution Failed?

• two set of instructions written in S/W.

• How to ensure No Context Switch between them?

• In some processors, dedicated instructions are there to do this.

Hardware Solution 1: Test and Set Instruction

Page 4 of 7
Hardware Solution 2: xchg Instruction

High Level Constructs for solving Critical Section Problems (using Instructions like xchg)

• Spinlocks

• Mutex

• Semaphore

• Monitor

High Level Construct1: Spinlocks

Page 5 of 7
• Two functions

• acquire(&locked)

• release(&locked)

• One process will acquire the lock and the other will wait in a loop repeatedly checking if the
lock is available

• The lock becomes available when the former process releases it

Issues with Spinlocks

 Busy Waiting

High Level Construct2: Mutex

Issue with Mutex

 Thundering Herd Problem

Producer Consumer Problem

Page 6 of 7
Producer – Consumer Problem (Solution using Mutex)

Issue with Producer – Consumer Problem (Solution using Mutex)

 Lost wakeup()

High Level Construct3: Semaphore

 Shared Resource
 Atomic functions to store/access the wakeup calls
o down/wait
o up/signal
 2 Types
o Counting Semaphore
o Binary Semaphore

Page 7 of 7

You might also like