This document discusses interprocess communication and synchronization. It describes race conditions that can occur when multiple processes access shared data concurrently. It introduces the concept of critical sections and mutual exclusion to prevent race conditions. Solutions to achieve mutual exclusion include semaphores and monitors. Semaphores use wait and signal operations while monitors provide mutual exclusion through language-level constructs. Condition variables allow processes to wait for and signal specific events within monitors.

1. Interprocess
Communication
Mutual exclusion
And
synchronizations

2. Interprocess Communication
• Communication of processes running
concurrently on a computer system.
• Major issues
– Passing information to another process
– Not disturbing other processes when
doing critical activities.
– Process synchronization

3. Race conditions
• Occurs when multiple processes access
and manipulate the same shared data
concurrently and the outcome of the
execution depends on the particular order in
which the access takes place.
• Example
– Assume two processes incrementing the value
of the same shared variable.
– The value of the var will depend on the
sequence the processes access the var.

4. Critical Region/section
• A piece of code that access a shared
resource.
• A process is said to be in its critical
section when it is executing critical code.

5. Mutual exclusion
• When one process is executing in its critical
section, no other process can execute in its
critical section
• Each process takes the form
– Repeat
• Entry section
• Critical section
– Exit critical section
• Remainder section
– Forever

6. Mutual exclusion using critical
region
Process A
Process B
t1 t2 t3
t4
Time
Enter Critical section
A leaves critical section
B attempts to critical section and is blocked
B leaves critical section

7. Conditions for mutual exclusion
solution
• No two processes may be
simultaneously inside their critical
region
• No assumption may be made about
the speeds or the number of CPUs
• No process running outside its critical
section may block other processes
• No process should have to wait
forever to enter its critical region.

8. Solutions to Mutual exclusion
• Disabling interrupts
• Using lock variables
• Strict alternation
• Using TLS instruction
• Strict alternation
• Petersons solution
• Semaphores
• Monitors

9. Semaphores
• Suggested by E W Dijkstra(1965)
• Nonnegative integer variable(S) that can be
operated upon by wait(s) and Signal(s) and
the initialization operation.
• Used in mutual exclusion and process
synchronization
• Types
– Binary /mutex semaphore
– Counting semaphores

10. Semaphore operations
• Signal(S)
– Increases the value of S
– Atomic operation (cannot be interrupted)
• Signal()
– S++
• Wait(S)
– Decreases the value of S
– Atomic operation (cannot be interrupted)
• Signal()
– S--

11. Semaphore Types
• Types
– Binary /mutex semaphore
• Used for mutual exclusion
• S only takes on values 0,1
– Counting semaphores
• Used for process synchronization
• Represents the number of resources available

12. Binary /mutex semaphore
• Blocking in semaphores
– Associated with each semaphore is a queue of
waiting processes
– If s > 0 /*Test entry point
• Wait(S);
• Enter critical section; /* Semaphore is open, Process proceeds
– Else Block; /* Semaphore is closed, process blocks
– Signal(s); /*waiting process on a queue is unblocked
/*If no process is on the queue the signal is
/*remembered

13. Producer consumer problem using
semaphore
• Program for producers
• Repeat indefinitely
• Begin
– Produce item;
– Wait(space available);
– Wait(buffer
manipulation);
– Deposit item in buffer;
– Signal(buffer
manipulation);
– Signal(item available);
• End;
• Program for
consumers
• Repeat indefinitely
• Begin
– Wait(item available);
– Wait(buffer
manipulation)
– Excract item from buffer;
– Signal(buffer
manipulation);
– Signal(space available);
– Consume item;
• End;

14. Producer consumer problem using
semaphore
• #Define N 100
• typedef int semaphore;
• semaphore mutex = 1;
• semaphore empty = N;
• semaphore full = 0;
• Void producer(void)
– {
• Int item;
– While (TRUE){
• Item = producer_item();
• wait(&empty);
• wait(&mutex);
• Insert_item(item);
• signal(&mutex);
• signal(&full));
• }
– {
– Void consumer(void)
– {
• Int item;
• While(True){
– wait(&full);
– wait(&mutex);
– Item = remove_item();
– signal(&mutex);
– signal(&empty);
– consume-_item;
– }
• }

15. Semaphore summary
• Semaphores can be used to solve any of the
synchronization problem
• However ,thy have some drawbacks
– They are shared variables.
– No connection between the semaphore and the data
being controlled
– No guarantee of proper usage
• Hard to use
– Use programming language support

16. Monitors
• Programming language construct that controls access to shared
data
• Mutual exclusion code added by the compiler, enforced at runtime
• Consists of
– Shared data structures and variables
– Procedures that operate on (1)
– Piece of program that initialize the variables
• Protects its data from unstructured access

17. Example of Monitor
• Monitor example
– Integer i;
– Condition c;
– Procedure consumer;
• .
• .
– End;
– Procedure producer;
• .
• .
– End;
• End monitor;

18. Monitors and mutual exclusion
• Monitors guarantees mutual exclusion
• Only one process can be active in a monitor at any time
– Compiler must handle monitor procedures differently from other
procedures
– Compiler must implement mutual exclusion on monitor entries
• If a second process invokes a monitor procedure when
the first one is within the monitor, it blocks.
– Monitor has to have a wait queue
• If no process is using the monitor, the calling process
may enter.

19. Condition Variables
• Provides a mechanism to wait for
events
• Support two operations
• Wait
– Causes the calling process to block
• Signal
– Wake up sleeping process

20. Signal Semantics
• Hoare monitors
– Allow newly awakened process to run, suspending the
other
• Brinch Hansen proposal
– Process doing a signal must exit the monitor immediately
– Putting signal statement as the final statement in a monitor
procedure
• Mesa Monitor
– Signal() places a waiter on the ready queue,but signaler
continues inside the monitor
– Condition is not necessarily true when waiter runs again

21. Condition variables vs
semaphores
• Semaphores
– Can be used anywhere in a program, but should not be used in a monitor Wait()
– Wait() does not always block the caller (i.e., when the semaphore counter is greater than
zero).
– Signal() either releases a blocked thread, if there is one, or increases the semaphore
counter.
– If Signal() releases a blocked thread, the caller and the released thread both continue.
• Condition Variables
– Can only be used in monitors
– Wait always block the caller
– Signal() either releases a blocked thread, if there is one, or the signal is lost as if it never
happens.
– If Signal() releases a blocked thread, the caller yields the monitor (Hoare type) or continues
(Mesa Type). Only one of the caller or the released thread can continue, but not both.