3. 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
4. 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
5. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 5 of 68
6. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson
If S4 happens after S5, how
many buffers are full?
6
Both processes
manipulate 'counter'
concurrently
6 of 68
7. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 7 of 68
8.
9. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 9 of 68
10. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 10 of 68
11. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 11 of 68
12. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 12 of 68
13.
14. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 14 of 68
15. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson
Entry section
Exit section
15 of 68
16. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 16 of 68
17. Algorithm (3/5)
• Provable that
– Mutual exclusion is preserved
– Progress requirement is satisfied
– Bounded-waiting requirement is met
4/1/2022 Instructor: Mr.S.Christalin Nelson 17 of 68
18. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 18 of 68
19. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 19 of 68
20.
21. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 21 of 68
22. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 22 of 68
23. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson
Non-interruptable
unit
23 of 68
25. Multiprocessor environment (3/4)
• Algorithm-2
– Mutual Exclusion with compare_and_swap()
4/1/2022 Instructor: Mr.S.Christalin Nelson 25 of 68
26. Multiprocessor environment (4/4)
• Algorithm-3
– Mutual Exclusion, Bounded wait & Progress with test_and_set()
4/1/2022 Instructor: Mr.S.Christalin Nelson 26 of 68
27.
28. 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()
4/1/2022 Instructor: Mr.S.Christalin Nelson 28 of 68
29. Mutex locks (2/2)
• Note: acquire() & release() should be performed atomically
4/1/2022 Instructor: Mr.S.Christalin Nelson 29 of 68
30.
31. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 31 of 68
33. 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:
4/1/2022 Instructor: Mr.S.Christalin Nelson
//P1
S1;
signal(S);
//P2
wait(S);
S2;
33 of 68
34. 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.
4/1/2022 Instructor: Mr.S.Christalin Nelson 34 of 68
36. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson
//P1
wait(S);
wait(Q);
.
.
.
signal(S);
signal(Q);
//P2
wait(Q);
wait(S);
.
.
.
signal(Q);
signal(S);
36 of 68
37. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson
No Priority inversion ...tasks
are running as per design!!
Priority inversion 37 of 68
38. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 38 of 68
39.
40. At a Glance
• Bounded-Buffer Problem
• Readers-Writers Problem
• Dining-Philosophers Problem
4/1/2022 Instructor: Mr.S.Christalin Nelson 40 of 68
43. 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)
4/1/2022 Instructor: Mr.S.Christalin Nelson 43 of 68
44. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 44 of 68
45. Reader-Writers Problem (3/5)
• Solution to first readers-writers problem (contd.)
4/1/2022 Instructor: Mr.S.Christalin Nelson 45 of 68
46. Reader-Writers Problem (4/5)
• Solution to first readers-writers problem (contd.)
4/1/2022 Instructor: Mr.S.Christalin Nelson 46 of 68
47. Reader-Writers Problem (5/5)
• 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 47 of 68
48. Dining-Philosophers Problem (1/4)
4/1/2022 Instructor: Mr.S.Christalin Nelson
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
49. Dining-Philosophers Problem (2/4)
• 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 49 of 68
51. Dining-Philosophers Problem (4/4)
• 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 51 of 68
52. Timing errors with semaphores
• Example: If following sequence is not observed
– caused by an honest programming error or an uncooperative
programmer)
4/1/2022 Instructor: Mr.S.Christalin Nelson
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
53.
54. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 54 of 68
55. Schematic view of Monitor
4/1/2022 Instructor: Mr.S.Christalin Nelson 55 of 68
56. 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)
4/1/2022 Instructor: Mr.S.Christalin Nelson 56 of 68
58. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 58 of 68
61. Implementing a Monitor Using Semaphores (1/2)
4/1/2022 Instructor: Mr.S.Christalin Nelson 61 of 68
62. Implementing a Monitor Using Semaphores (2/2)
4/1/2022 Instructor: Mr.S.Christalin Nelson 62 of 68
63. 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 63 of 68
64. Resuming process within a monitor (2/5)
4/1/2022 Instructor: Mr.S.Christalin Nelson 64 of 68
65. Resuming process within a monitor (3/5)
• Sequence followed by process needing resource access
– ResourceAllocator R; //instance of type monitor
4/1/2022 Instructor: Mr.S.Christalin Nelson 65 of 68
66. Resuming process within a monitor (4/5)
• 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
4/1/2022 Instructor: Mr.S.Christalin Nelson 66 of 68
67. Resuming process within a monitor (5/5)
• 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)
4/1/2022 Instructor: Mr.S.Christalin Nelson 67 of 68