2/16/23

CLASSICAL PROBLEMS OF SYNCHRONIZATION

Operating Systems
PRODUCER – CONSUMER PROBLEM
( BOUNDED-BUFFER )
Sateesh K. Peddoju
WITHOUT SEMAPHORES

1 2

1 2

Bounded-Buffer without semaphores Bounded-Buffer without semaphores

• Shared data • Producer process • Consumer process
item nextProduced; item nextConsumed;
#define BUFFER_SIZE 10 while (1) { while (1) {
typedef struct { while (counter == BUFFER_SIZE) while (counter == 0)
; /* do nothing */
... /* int data; */ ; /* do nothing */
nextConsumed = buffer[out];
buffer[in] = nextProduced;
} item; out = (out + 1) % BUFFER_SIZE;
in = (in + 1) % BUFFER_SIZE;
item buffer[BUFFER_SIZE]; counter--;
counter++; }
int in = 0; }
int out = 0;
int counter = 0;

3 4

3 4

1
 2/16/23

Bounded-Buffer without semaphores Bounded-Buffer without semaphores

• The statements • The statement “count++” may be implemented in
machine language as:
counter++; register1 = counter
counter--; register1 = register1 + 1
counter = register1
must be performed atomically.
• The statement “count--” may be implemented as:
• Atomic operation means an operation that register2 = counter
completes in its entirety without interruption. register2 = register2 – 1
counter = register2

5 6

5 6

Bounded-Buffer without semaphores Bounded-Buffer without semaphores

• If both the producer and consumer attempt to • Assume counter is initially 5. One interleaving of
statements is:
update the buffer concurrently, the assembly
language statements may get interleaved. producer: register1 = counter (register1 = 5)
producer: register1 = register1 + 1 (register1 = 6)
consumer: register2 = counter (register2 = 5)
• Interleaving depends upon how the producer and consumer: register2 = register2 – 1 (register2 = 4)
consumer processes are scheduled. producer: counter = register1 (counter = 6)
consumer: counter = register2 (counter = 4)

• The value of count may be either 4 or 6, where the

correct result should be 5.

7 8

7 8

2
 2/16/23

Process Synchronization Process Synchronization

• Dining Philosopher’s Problem • Barber Shop Problem
• 5 Philosophers – sleeping Barber Problem
• 5 chopsticks (forks) – Single Barber
– A barber’s chair
• Random times eat
– n – chairs for waiting
• Must pick – Barber spends his life in shop
– One right & One left
– Sleeps until a customer wakes up.
• Issues – Customer waits, if busy
– Deadlock or Starvation – No chairs, leaves & comes back
• Solutions? • Solution
– Only 4 to be hungry – Mutual Exclusion
– Allow – if both sticks are available
–
9 10

9 10

Process Synchronization Process synchronization

X
• Cigarette Smokers Problem • Producer-Consumer Problem
– ( or Bounded-Buffer Problem)
• Readers-Writers Problem

Tobacco à Paper à Matchbox

11 12

11 12

3
 2/16/23

Concurrency Concurrency – Race Condition

• Benefits • A race condition occurs when multiple processes
• Communication among the processes
• Sharing Resources or threads read and write data items so that the
• Synchronization of multiple processes
• Allocation of processors time
final result depends on the order of execution of
• Difficulties instructions in the multiple processes
• Sharing global resources (ex: global variable) b=1 c=2
– Race Condition
• Management of allocation of resources (optimality?) P1 P2
• Programming errors difficult to locate
b=b+c c=b+c
• Inconsistent data
13 14

13 14

Concurrency – OS Design Concerns OS Design Concerns

• Multiprogramming • Keep track of active processes
– Management of multiple processes in Uni-processor • Allocate and deallocate resources
• Multiprocessing – Processor time
– Management of multiple processes in Multi-processors – Memory
– Files
• Distributed Processing – I/O devices
– Management of multiple processes executing on multiple,
• Protect data and resources
distributed machines
• Result of process must be independent of the speed of
execution of other concurrent processes

15 16

15 16

4
 2/16/23

Concurrency – Contexts… Critical Section

• Multiple Applications
• A section of code within a process that requires
– Sharing processing time – dynamically
• Structured Applications access to shared resources and that must not be
– Concurrency is part of programming
– User Threads
executed while another process is in a
• Operating System Structure corresponding section of code.
– Concurrency is part of OS
– Kernel Threads

17 18

17 18

Critical Section Problem Solution to Critical Section Problem

Mutual Exclusion
1. Only one process at a time is allowed in the critical section for a resource
• Design a protocol that the processes can use to
Progress
cooperate. 2. A process that is in its reminder section must do so without interfering with other
processes
3. A process must not be delayed access to a critical section when there is no other
• Each process must request to enter critical section process using it
4. It must not be possible for a process to be delayed indefinitely
5. A process remains inside its critical section for a finite time only
• Entry Section 6. We assume that each process is executing at non-zero speed. However, we can
make no assumption concerning the relative speed of the processes.
• Exit Section Bounded Waiting
• Remainder Section 7. If another process is waiting to enter the critical section, there exists a bound or
limit on the number of times current process to enter its critical section

19 20

19 20

5
 2/16/23

Mutual Exclusion Mutual Exclusion

• The requirement that when one process is in a
critical section that accesses shared resources, no
other process may be in a critical section that
accesses any of those shared resources.

21 22

21 22

Meeting the Requirements… Software Approaches

• Software Approach: • Peterson’s Solution
– Leave the responsibility with the processes to handle the – Restricted to two processes (P0, P1) (Pi, Pj)
situation (neither OS nor PL will support)
– Prone to high processing overhead and bugs – int turn;
/* whose turn it is to enter critical section */

– boolean flag[2];
• Hardware Approach: /* which process is ready to enter critical section */

– Using special purpose machine instructions

– Reduces overhead but not the general purpose solution – Mutual exclusion?
– Progress ?
– Bounded Wait ?
• OS and PL Approach:
– Provide support within OS and PL itself.
23 24

23 24

6
 2/16/23

Software Approaches Software Approaches

• A general Solution - Lock • Disadvantage
• Prone to high processing overhead and bugs

25 26

25 26

Hardware Approaches Hardware Approaches

• Interrupt Disabling • Special Machine Instructions
– uniprocessor – Performed in a single instruction cycle
– Disabling interrupts guarantees mutual exclusion
– Not subject to interference from other instructions
– TestAndSet() and Swap() (Reading)
– Disadvantages:
– Processor is limited in its ability to interleave programs
– Multiprocessing
• disabling interrupts on one processor will not guarantee mutual
exclusion

27 28

27 28

7
 2/16/23

Hardware Approaches Hardware Approaches

• Disadvantages
• Advantages
– Busy-waiting
• consumes processor time
– Applicable to any number of processes on either a single
processor or multiple processors sharing main memory – Starvation
• more than one process is waiting à some process may not be
selected à waiting indefinitely.
– It is simple and therefore easy to verify
– Deadlock
• If a low priority process (say P1) executing in the critical region and
– It can be used to support multiple critical sections a higher priority process (P2) needs, the higher priority process will
obtain the processor.
• If P2 tries to access a resource which P1 holds, it will be denied
due to mutual exclusion.
• P1 to wait for the critical region, P2 to wait for resource
29 30

29 30

OS and PL Approaches OS and PL Approaches

• Semaphore
• Semaphores
– Binary Semaphores
• Mutex
– Condition Variable
• Monitor
– Event Flags
• Mailboxes/Messages
• Spinlocks

31 32

31 32

8
 2/16/23

Semaphore Implementation OS and PL Approaches

• When a process must wait on a semaphore, it is added to • Semaphore – Disadvantages Solution
the list of processes – Busy waiting
OS should have system calls:
• A Signal() operation removes one process from the list of block()
wakeup()
waiting processes and awakens that process.

May be negative also

If negative à s = no. of processes

waiting for s

33 34

33 34

OS and PL Approaches OS and PL Approaches

• Semaphore – Example • Semaphore – Example
– At some instance, A is executing, B,D,C are in RQ and S=1

35 36

35 36

9
 2/16/23

OS and PL Approaches
• Semaphore – Disadvantages
– Deadlock
• Say, there are two semaphores, S and Q
USAGE OF SEMAPHORES
IN
CLASSICAL PROBLEMS OF SYNCHRONIZATION

– Starvation
• Processes are stored in LIFO order
37 38

37 38

Bounded-Buffer with semaphores Bounded-Buffer with semaphores

Producer Process Consumer Process
• Shared data
do { do {
– No. of Buffers = n (each – one item only) wait(full)
• semaphores input an item in nextp wait(mutex);
– full : to count the number of full buffers
wait(empty); consume an item from buffer to nextc
– empty : to count the number of empty buffers wait(mutex);
– mutex : to access the critical section (buffers) signal(mutex);
produce nextp to buffer signal(empty);
• Initially:
– full = 0, empty = n, mutex = 1 signal(mutex); remove the item in nextc
signal(full);
} while (1); } while (1);
39 40

39 40

10
 2/16/23

Readers – Writers Problem Readers-Writers with Semaphores

• First Readers – Writers Problem • Shared data
– File, database etc
– Writers starve
• Semaphore
• Second Readers – Writers Problem – mutex – mutual exclusion semaphore for updating readcount variable
– Readers starve – wrt - mutual exclusion semaphore for writers
– User by first or last reader enters or exists
• Initially
– mutex = 1, wrt = 1,
• Starve free Readers – Writers Problem – readcount = 0 // how many are reading
– Assignment: Submit the Code + Documentation
– Copying: Penalty of 20 marks. I may ask the questions as well.
– Github link (roughly two weeks)

41 42

41 42

Readers-Writers with Semaphores Readers-Writers with Semaphores

Writer Process : Reader Process :
wait(mutex);
readcount++;
wait(wrt); if (readcount == 1) wait(wrt);
… signal(mutex);
…
writing is performed reading is performed
… …
signal(wrt); wait(mutex);
readcount--;
if (readcount == 0) signal(wrt);
signal(mutex):
43 44

43 44

11
 2/16/23

Dining-Philosophers Problem Dining-Philosophers Problem

• Philosopher i:
• Shared data do {
– chopsticks wait(chopstick[i])
wait(chopstick[(i+1) % 5])
• Semaphore
…
– chopstick[5]; eat
• Initially …
signal(chopstick[i]);
– all values are 1 signal(chopstick[(i+1) % 5]);
…
think
…
} while (1);
45 46

45 46

It’s Your turn… Monitors and Condition Variables

• Producer – Consumer Problems • Semaphores can result in deadlock due to programming
– Bounded buffer errors
– Cyclic buffer – forgot to add a P() or V(), or misordered them, or duplicated
– Infinite buffer them
• to reduce these errors, introduce high-level
• Dining Philosophers Problem synchronization primitives, e.g. monitors with condition
variables, that essentially automates insertion of P and V
for you
• Sleeping Barbers Problem – As high-level synchronization constructs, monitors are found in
high-level programming languages like Java and C#
• Cigarette Smokers Problem – underneath, the OS may implement monitors using semaphores
and mutex locks
– Any other problems of like….

47 48

47 48

12
 2/16/23

Monitors Monitors
• Monitor is a software module • Chief characteristics
– Same as semaphore – simple to implement. – Local data variables are accessible only by the monitor
• Abstract Data Type – Process enters monitor by invoking one of its
– Class procedures
– Hide (Restrict the access to) the shared data – Only one process may be executing in the monitor at a
time
– Access through procedures / functions

49 50

49 50

Monitors Monitors
• monitor class Account {
• Syntax private int balance := 0
monitor monitor-name public method boolean withdraw(int amount) precondition amount >= 0
{ { BUSY WAITING ?
shared variable declarations if balance < amount then
procedure body P1 (…) { return false
...
else {
}
balance := balance - amount ;
procedure body P2 (…) {
... return true
} }
procedure body Pn (…) { }
... public method deposit(int amount) precondition amount >= 0
} {
{ balance := balance + amount
initialization code
}
}
} 51
} 52

51 52

13
 2/16/23

Monitors Monitors and Condition Variables

• For many applications, mutual exclusion is not • There are two main operations on condition
enough. variables:
• Threads/Processes may also wait (busy wait) on
some other conditions x.wait() : means that the process invoking this
while not( P ) do skip operation is suspended until another process
invokes
• Solution:
– Condition Variables x.signal() : resumes exactly one suspended
• Conceptually a condition variable is a queue of processes / process. If no process is suspended, then the
threads, associated with a monitor, on which a
process/thread may wait for some condition to become signal operation has no effect.
true.

53 54

53 54

Monitors and Condition Variables P – C Problem – Monitor Solution

monitor bounded_buffer
• Note that x.signal() is unlike the semaphore’s signalling monitor monitor-name
{
operation V(), which preserves state in terms of the value { item buffer[N];
of the semaphore. shared variable declarations int in, out;
procedure body P1 (…) { int counter;
... condition notfull, notempty;
• Declare a condition variable with pseudo-code: }
procedure body P2 (…) { void producer();
... void consumer();
condition x,y; } void append(item x);
procedure body Pn (…) {
void take(item x);
...
} {
{ /* initialization code*/
initialization code
in = 0, out = 0, counter = 0;
}
} }
}
55 56

55 56

14
 2/16/23

P – C Problem – Monitor Solution P – C Problem – Monitor Solution

57 Block itself until notfull 58

57 58

P – C Problem – Monitor Solution Dining Philosophers using Monitors

• Key insight: pick up 2 chopsticks only if both are free
– this avoids deadlock

– reword insight: a philosopher moves to his/her eating state only

if both neighbors are not in their eating states
• thus, need to define a state for each philosopher

– 2nd insight: if one of my neighbors is eating, and I’m hungry, ask

them to signal() me when they’re done
• thus, states of each philosopher are: thinking, hungry, eating
• thus, need condition variables to signal() waiting hungry philosopher(s)

– Also, need to Pickup() and Putdown() chopsticks

59 60

59 60

15
 2/16/23

D – P Problem – Monitors Solution D – P Problem – Monitors Solution

monitor dp void pickup(int i) {
{ state[i] = hungry;
enum {thinking, hungry, eating} state[5];
test(i);
condition self[5]; if (state[i] != eating)
self[i].wait();
void pickup(int i); }
void putdown(int i);
void test(int i); void putdown(int i) {
void init() { state[i] = thinking;
for (int i = 0; i < 5; i++) // test left and right neighbors
state[i] = thinking; test((i+4) % 5);
} test((i+1) % 5);
}
61
} 62

61 62

D – P Problem – Monitors Solution D – P Problem – Monitors Solution

void test(int i) { • Deadlock ?
if ( (state[(i + 4) % 5] != eating) && – Deadlock free!
(state[i] == hungry) && • Starve ?
(state[(i + 1) % 5] != eating)
){
state[i] = eating;
self[i].signal();
}
}
63 64

63 64

16
 2/16/23

Issues with Monitors & Semaphores Process Interaction

• Monitors
– High level constructs – not highly supported by various
PLs – Difficult to implement in practice
• Semaphores
– Low level constructs– not easily implemented. – Still,
disadvantages exist.

65 66

65 66

17