Process Synchronization

Instructor
Mr. S.Christalin Nelson
Process Synchronization

Motivation (1/5)
• Cooperating processes concurrently access to shared data
– Use threads (directly share a logical address space) or Use
files/messages
• Concurrent & Parallel execution contribute to data
inconsistency (issues in integrity of data)
– Concurrent (CPU scheduler performs context switching),
Parallel (Processes execute in separate processing cores)
– Solution: Orderly execution of cooperating processes
4/1/2022 Instructor: Mr.S.Christalin Nelson 3 of 68

Motivation (2/5)
• Bounder buffer allows processes to share memory
– Producer-consumer problem
• Original solution: Allow at most BUFFER SIZE − 1 items in buffer
at same time.
• Modified Solution: Include 'count' to track no. of full buffers
– Initially, set count = 0
– Producer increments count after it produces a new buffer
– Consumer decrements count after it consumes a buffer
4/1/2022 Instructor: Mr.S.Christalin Nelson
Will modified solution work is
processes execute concurrently?
NO
4 of 68

Motivation (3/5)
• Analysis on a typical machine
– Consider register1 & register2 => local CPU registers
– Implementation with low-level statements
• counter++ could be implemented as
– register1 = counter;
– register1 = register1 + 1;
– counter = register1
• counter-- could be implemented as
– register2 = counter;
– register2 = register2 - 1;
– counter = register2
– Understanding concurrent execution of high-level statements
• It is equivalent to a sequential execution were lower-level
statements can be interleaved in some arbitrary order but order
within each high-level statement is preserved

Motivation (4/5)
• Analysis on a typical machine (contd.)
– Consider: count = 5, Following interleaving occurs
• S0: producer execute register1 = counter {register1 = 5}
• S1: producer execute register1 = register1 + 1 {register1 = 6}
• S2: consumer execute register2 = counter {register2 = 5}
• S3: consumer execute register2 = register2 - 1 {register2 = 4}
• S4: producer execute counter = register1 {count = 6 }
• S5: consumer execute counter = register2 {count = 4}
– Note:
• Incorrect Result: 4 buffers are full
• Actual Result: 5 buffers are full
If S4 happens after S5, how
many buffers are full?
6
Both processes
manipulate 'counter'
concurrently
6 of 68

Motivation (5/5)
• Race condition
– A situation where several processes access & manipulate same
data concurrently & the result depends on particular order in
which the access takes place
– Solution:
• Allow only one process to manipulate ‘counter’ at a time
• i.e Process synchronization is required

General structure of a typical Process
• Process can be divided into sections
– Entry section - Seek permission to enter critical section
– Critical Section (CS)
• Each process has a segment of code (CS) during which they may
change common variables, update table, write file, etc.
• When one process is in its CS, no other process may be in their CS
(Mutual exclusion)
– More challenging with preemptive kernels
– Exit & Remainder section
• Critical section problem: Designing a protocol to solve this

Satisfying requirements of a Solution
• Mutual Exclusion
– If a process is executing in its CS, then no other processes can
be executing in their CS
• Progress
– If no process is executing in its CS & there exist some processes
that wish to enter to their CS, then selection of process that
will enter CS cannot be postponed indefinitely
• Bounded Waiting
– There is a bound/limit on no. of times that other processes are
allowed to enter their CS after a process has made a request to
enter its CS & before that request is granted
• Assume: Each process executes at a nonzero speed
• No assumption concerning relative speed of ‘n’ processes

Kernel-mode processes (1/2)
• Many kernel-mode processes may be active in OS at a time
& kernel code is subject to possible race conditions
• Example
– Kernel data structure that maintains a list of open files
• List is modified when a new file is opened or closed
• If 2 processes were to open files simultaneously, the separate
updates to this list could result in a race condition
– Other kernel data structures prone to possible race conditions
• DS that maintains memory allocation
• DS that maintain process lists
• DS that handles Interrupts

Kernel-mode processes (2/2)
• Approaches used to handle critical sections in OS
– Non-Preemptive kernels
• Free from race conditions on kernel data structures
– Preemptive kernels
• More responsive
• Suitable for real-time programming
• Difficult to design for SMP architectures

Overview
• Software-based solution
• Provides a good algorithmic description
• Illustrates some complexities involved in designing software
while addressing the requirements of mutual exclusion,
progress, and bounded waiting
• Assume LOAD and STORE instructions are atomic and cannot
be interrupted
• Does not guarantee to work correctly on all architectures

Algorithm (1/5)
• Restricted to two processes that alternate execution
between their CS & remainder sections
– i.e. Pi & Pj (other 1-i processes)
• Structure of a process
Entry section
Exit section
15 of 68

Algorithm (2/5)
• Processes share two data items
– int turn
• Denotes the process which can enter its CS
• Pi enters CS => Set “turn == i”
– boolean flag[2]
• Denotes the process which is ready to enter its CS
• Pi is ready to enter CS => Set “flag[i] == true”
• Before Pi to enters its CS
– Set flag[i] = true
– Set turn = j
• Asserts Pj to enter CS if required
• Eventual value of 'turn' determines which process is allowed first
to enter its CS

Algorithm (3/5)
• Provable that
– Mutual exclusion is preserved
– Progress requirement is satisfied
– Bounded-waiting requirement is met

Algorithm (4/5)
• Proof of Property 1 (Mutual Exclusion)
– Each Pi can enter its CS if flag[j] == false or turn == i
– Both processes can be executing in their CSs at same time, if
flag[0] == flag[1] == true
• P0 & P1 cannot successfully execute their while statements at
about same time since turn == 0 or 1 (cannot be both)
– Hence, one of the processes (say Pj) must have successfully
executed while statement
– Whereas Pi had to execute at least one more statement (“turn == j”)
– Now, flag[j] == true & turn == j. This condition persists as Pj is in CS
– Hence mutual exclusion is preserved

Algorithm (5/5)
• Proof of Properties 2 & 3 (Progress & Bounded waiting)
– Pj is not ready to enter CS, set flag[j] == false. Then, Pi can
enter its CS
– Pj is ready to enter CS, set flag[j] == true & is also executing in
its while statement
– Pj will enter CS, eventually turn == j
• Else Pi will enter CS (turn == i)
– Pj exits CS, reset flag[j] == false. Then, Pi can enter CS
– Pj wants to enter CS again, resets flag[j] == true, it also sets
turn == i
• Now, Pi does not change value of turn while executing while
statement & hence Pi will enter CS (progress) after at most one
entry by Pj (bounded waiting)
• Pi can be prevented from entering CS only if it is stuck in while
loop with flag[j] == true & turn == j

Lock based solution to CS problem
• Locks protect the Critical regions
• Advanced and Complicated
• Available for kernel developers & application programmers
• Examples
– Hardware-based
• Systems have simple hardware instructions
• Hardware features makes programming task easier and improve
system efficiency
• Complicated & generally inaccessible to application programmers
– Software-based APIs

Single-processor environment
• Prevent interrupts from occurring while a shared variable
was being modified
– Executes current sequence of instructions without preemption
– Unexpected modifications is not made to the shared variable
– Adopted with non-preemptive kernels

Multiprocessor environment (1/4)
• Preventing interrupts is infeasible
– Time consuming since message is passed to all processors
• Message passing delays entry into each CS & system efficiency
decreases
– System’s clock need interrupts for being updated
• Modern machines have special atomic hardware instructions
– Example
• If 2 xyx() instructions are executed simultaneously on different
CPUs, they will be executed sequentially in some arbitrary order
without being interrupted
• 3 Algorithms
Non-interruptable
unit
23 of 68

Single-processor environment (2/4)
• Algorithm-1
– Mutual Exclusion with test_and_set()

• Algorithm-2
– Mutual Exclusion with compare_and_swap()

• Algorithm-3
– Mutual Exclusion, Bounded wait & Progress with test_and_set()

Mutex locks (1/2)
• Mutually Exclusive Lock
• Software-based solution to protect CS (i.e. prevent race
conditions)
• Process should
– Acquire lock before entering CS – acquire()
• If lock available -> acquire (lock unavailable for other processes)
• If lock unavailable -> blocked till available (i.e. busy waiting)
– Lock is termed as “Spinlock”
» Adv. if process held for short time & no context switch
– Releases lock when exiting CS – release()

Mutex locks (2/2)
• Note: acquire() & release() should be performed atomically

Usage (1/3)
• Dijkstra (1963) invented a variable ‘S’ named semaphore
accessed by atomic operations, wait() & signal()
• Types
– Binary semaphore
• Value: 0 or 1 (locked/unlocked, unavailable/available)
– Counting semaphore
• Value: Ranges over an unrestricted domain
• Control access to a given resource with a finite no. of instances
• Example
– Initialize count = No. of resources available
– Process wishing to use a resource -> wait(S) & decrements count
» When count==0, all resources are being used. i.e. Process
wishing to use a resource will block until count>0
– Process releasing a resource -> signal(S) & increments count

Usage (2/3)

Usage (3/3)
• Solving Synchronization Problem
– Case: Concurrent processes P1 & P2 has statement S1 & S2
respectively. S1 should be completed before S2.
• P1 and P2 share a common Semaphore (S)
• P1 and P2 are defined as follows:
//P1
S1;
signal(S);
//P2
wait(S);
S2;
33 of 68

Implementation (1/2)
• Operation with modified wait(), signal(), block() & wakeup()
– P1 & P2 share Semaphore(S) -> S has waiting queue -> P1 is
executing -> P2 executes wait(S) & instead of busy waiting, it
executes block() to block itself & enter waiting queue (waiting
state) -> CPU scheduler can select P3 to execute -> P1 executes
signal(S) -> P2 executes wakeup() changes to ready state &
placed in ready queue -> CPU may or may not switch from P3
to P2 (depends on scheduling algorithm)
• Semaphore operations should be atomic
– Single processor environment: Disable/Enable Interrupts
– SMP environment: compare_and_swap() or spinlocks
– Note: Busy waiting is not completely eliminated. Moved from
ES to CS.

Implementation (2/2)

Occurrence of Deadlock & Starvation
• Deadlock
– Two or more processes wait indefinitely for an event that can
be caused only by one of the waiting processes. i.e. signal()
• All processes belong to same set
– Example: P1 & P2 share semaphores S & Q set to value=1
• Starvation
– Two or more processes get blocked indefinitely in a semaphore
implemented as LIFO
//P1
wait(S);
wait(Q);
.
.
.
signal(S);
signal(Q);
//P2
wait(Q);
wait(S);
.
.
.
signal(Q);
signal(S);
36 of 68

Priority Inversion (1/2)
• Low-priority process holds lock needed by high-priority proc.
• Scenarios (Consider 3 processes with priority L < M < H)
– L runs (not in CS) -> H needs to run -> H preempts L -> H runs ->
H releases control -> L resumes & runs
– L runs in CS -> H needs to run (not in CS) -> H preempts L -> H
runs & completes -> H releases control -> L resumes & runs
– L runs in shared CS -> H also needs to run in shared CS -> H
waits for L to complete CS -> L completes -> H enters CS & runs
– L runs in shared CS -> H also needs to run in shared CS -> H
waits for L to complete CS -> M interrupts L & starts to run ->
M completes & releases control -> L resumes & runs till end of
CS -> L completes & release control -> H enters CS & runs
• Note: Neither L nor H share CS with M
No Priority inversion ...tasks
are running as per design!!
Priority inversion 37 of 68

Priority Inversion (2/2)
• Solved via priority-inheritance protocol
– L runs in shared CS -> H also needs to run in shared CS -> L
inherits priority of H at time when H starts pending for CS -> H
waits for L to complete CS -> M need to run -> M cannot
interrupts L -> M waits for L -> L completes & release control ->
L goes back to its old priority -> H enters CS -> M waits for H ->
H completes & release control -> M runs

At a Glance
• Bounded-Buffer Problem
• Readers-Writers Problem
• Dining-Philosophers Problem

Bounded-Buffer Problem (1/2)

Bounded-Buffer Problem (2/2)

Readers-Writers Problem (1/5)
• Problem: A writer & some other process (reader or writer)
access shared data simultaneously
– Solution: Writers have exclusive access (reader-writer lock)
• Variations
– First readers–writers problem
• No reader be kept waiting unless a writer has already obtained
permission to use shared object
– i.e. No reader should wait for other readers to finish simply because
a writer is waiting (Writers starve)
– Second readers–writers problem
• Once a writer is ready, that writer perform its write ASAP
– i.e. If a writer is waiting to access the shared object, no new readers
may start reading (Readers starve)

Reader-Writers Problem (2/5)
• Solution to first readers-writers problem
– Reader processes share the following data structures:
• semaphore rw_mutex = 1;
– Common to both reader & writer
» Used by first or last reader that enters or exits CS (Not used by
readers who enter/exit while other readers are in their CS)
» mutex semaphore for writer
• semaphore mutex = 1;
– Ensure mutual exclusion when read_count is updated
• int read_count = 0;
– no. of processes currently reading

• Solution to first readers-writers problem (contd.)

– Reader–writer locks
• Specify mode (read or write access) while acquiring lock
– Read mode - Process wishes only to read, multiple processes can
concurrently acquire
– Write mode - Process wishes to modify, only one process may
acquire (exclusive lock)
• Set-up Overhead: Reader-writer lock > Semaphores or mutual-
exclusion locks
– Compensated by increased Concurrency with multiple readers
– Used by applications when
• It is easy to identify processes which only read shared data &
only write shared data
• No. of Readers > Writers

Dining-Philosophers Problem (1/4)
Consider 5 philosophers who spend their lives
thinking & eating.
When thinking, a philosopher does not interact with
colleagues.
From time to time, a philosopher gets hungry & tries
to pick up 2 closest chopsticks.
A philosopher may pick up only one chopstick at a
time & cannot pick up a chopstick that is already in
the hand of a neighbor.
A hungry philosopher eats without releasing the
chopsticks, only when having both chopsticks at same
time.
When finished eating, a philosopher puts down both
chopsticks & starts thinking again.
48 of 68

• Allocation of several resources among several processes in a
deadlock-free & starvation-free manner
• Solution: Represent each chopstick with a shared semaphore
– semaphore chopstick[5] = {1};
– A philosopher
• Executes wait() to get a chopstick
• Executes signal() on appropriate semaphore to release chopsticks

• The solution guarantees that no two neighbors can eat
simultaneously to avoid deadlock – but cannot be avoided
– Example: All 5 philosophers become hungry at same time &
each grab their left chopstick
• Possible remedies to Deadlock problem
– Permit at most 4 philosophers to sit simultaneously at table
– Philosopher picks chopsticks only if both are available (in CS)
• Slide 58 (Using Monitor)
– Use an asymmetric solution
• Odd-numbered philosopher picks left chopstick first & then right
• Even-numbered philosopher picks right chopstick first & then left
• Note: Deadlock-free solution does not necessarily eliminate
possibility of starvation

Timing errors with semaphores
• Example: If following sequence is not observed
– caused by an honest programming error or an uncooperative
programmer)
Order changed
Violates Mutual
Exclusion
signal() replaced
Dead Lock Occurs
Omit wait() or
signal() or both
Violates Mutual
Exclusion (OR) Dead
Lock Occurs
52 of 68

Structure of Monitor
• Structure of Monitor
– High-level abstraction
provides convenient &
effective mechanism for
process synchronization
– Only one process is active
within the monitor at a time
– Local variables of a monitor
can be accessed by local
functions only
– Function defined within a
monitor can access their
formal parameters

Schematic view of Monitor

Monitor usage (1/2)
• Additional constructs (like condition constructs) are required
to model some synchronization schemes
– condition x, y;
• Condition variables can only invoke wait() & signal()
– x.wait();
– x.signal();
• If no process is suspended: signal() operation has no effect
– i.e. State of x is same as if operation had never been executed
– Note: signal() operation associated with semaphores always affects
state of semaphore
• If Q is the suspended process: P executes signal() &
– Signal and continue: Q waits (until P leaves monitor or for another
condition)
– Signal and wait: P waits (until Q leaves monitor or for another
condition)

Monitor usage (2/2)

Dining-Philosophers Solution Using Monitors (1/3)
• Philosopher picks chopsticks only if both are available (in CS)
• States of a Philosopher
– enum {THINKING, HUNGRY, EATING} state[5];
• Default state of all philosophers: THINKING
• Philosopher ‘i' can eat, if its present state is HUNGRY & its two
neighbors are not EATING
– i.e. state[i] = EATING only if
» state[i] = HUNGRY
» state[(i+4) % 5] != EATING
» state[(i+1)% 5] != EATING

Implementing a Monitor Using Semaphores (1/2)

Implementing a Monitor Using Semaphores (2/2)

Resuming process within a monitor (1/5)
• Several processes are suspended on condition x and
x.signal() is executed by some process. Which suspended
processes is resumed next?
– FCFS
– Conditional-wait construct
• x.wait(c)
– Where c is an integer expression evaluated on execution
» Value of c (called priority no.) stored with name of suspended
process
• x.signal()
– Process with smallest priority no. is resumed next on execution

• Sequence followed by process needing resource access
– ResourceAllocator R; //instance of type monitor

• Does not guarantee to observe above access sequence
– Problems that could occur
• A process might access a resource without gaining access
permission
• A process might never release a resource after it has been
granted access
• A process might attempt to release a resource that it never
requested
• A process might request same resource twice (without first
releasing resource)
• Solution:
– Include resource access operations within ResourceAllocator
monitor
• Scheduling is done according to built-in monitor-scheduling
algorithm

• Ensure that processes observe appropriate sequences
– Inspect all programs that use ResourceAllocator monitor & its
managed resource
• Inspection may be possible for a small, static system
• Not reasonable for a large system or a dynamic system
• Conditions to be checked to establish correctness of this
system & guarantee that no time-dependent errors will
occur & scheduling algorithm will not be defeated
– (1) User processes must always make their calls on monitor in
a correct sequence
– (2) An uncooperative process does not simply ignore mutual-
exclusion gateway provided by monitor & try to access shared
resource directly (without using access protocols)

Process Synchronization

More Related Content

What's hot

Similar to Process Synchronization

More from Christalin Nelson

Recently uploaded

Process Synchronization