1. Concurrency: monitors & condition synchronization1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 8b Monitors and condition synchronisation Len Freeman, Graham Riley Centre for Novel Computing School of Computer Science University of Manchester

2. Concurrency: monitors & condition synchronization2 ©Magee/Kramer 2 nd Edition Chapter 5 Monitors & Condition Synchronization

3. Concurrency: monitors & condition synchronization3 ©Magee/Kramer 2 nd Edition monitors & condition synchronization Concepts : monitors: encapsulated data + access procedures mutual exclusion + condition synchronization single access procedure active in the monitor Models :guarded actions Practice : ‘private’ data and exclusive access using locks. wait, notify and notifyAll model for condition synch. single thread active in the monitor at a time

4. Concurrency: monitors & condition synchronization4 ©Magee/Kramer 2 nd Edition 5.1 Condition synchronization A controller is required for a carpark, which only permits cars to enter when the carpark is not full and does not permit cars to leave when there are no cars in the carpark. Car arrival and departure are simulated by separate threads.

5. Concurrency: monitors & condition synchronization5 ©Magee/Kramer 2 nd Edition carpark model  Events or actions of interest? arrive and depart  Identify processes. arrivals, departures and carpark control  Define each process and interactions (structure). ARRIVALS CARPARK CONTROL DEPARTURES arrive depart CARPARK

6. Concurrency: monitors & condition synchronization6 ©Magee/Kramer 2 nd Edition carpark model CARPARKCONTROL(N=4) = SPACES[N], SPACES[i:0..N] = (when(i>0) arrive->SPACES[i-1] |when(i SPACES[i+1] ). ARRIVALS = (arrive->ARRIVALS). DEPARTURES = (depart->DEPARTURES). ||CARPARK = (ARRIVALS||CARPARKCONTROL(4)||DEPARTURES). Guarded actions are used to control arrive and depart. LTS?

7. Concurrency: monitors & condition synchronization7 ©Magee/Kramer 2 nd Edition carpark program  Model - all entities are processes interacting by actions  Program - need to identify threads and monitors  thread - active entity which initiates (output) actions  monitor - passive entity which responds to (input) actions. For the carpark? ARRIVALS CARPARK CONTROL DEPARTURES arrive depart CARPARK

8. Concurrency: monitors & condition synchronization8 ©Magee/Kramer 2 nd Edition carpark program Arrivals and Departures implemented as (active) threads. CarParkControl provides the control (condition synchronization) implemented as a (passive) monitor (data + synchronized access functions). In code : // Thread creation (in main()): pthread_create( &thread1, NULL, &arrivals, NULL); pthread_create( &thread2, NULL, &departures, NULL);

9. Concurrency: monitors & condition synchronization9 ©Magee/Kramer 2 nd Edition carpark program - Arrivals and Departures threads void *arrivals() { for(;;) { arrive(); } How do we implement the control of CarParkControl ? Similarly departures which calls depart().

10. Concurrency: monitors & condition synchronization10 ©Magee/Kramer 2 nd Edition Carpark program - CarParkControl monitor condition synchronization? block if full? (spaces==0) block if empty? (spaces==CAPACITY) mutual exclusion? // The CarparkControl monitor data and functions #define CAPACITY 4 int spaces = CAPACITY; void *arrive(); void *depart(); void *arrive() { … --spaces; … } void *depart() { … ++spaces; … }

11. Concurrency: monitors & condition synchronization11 ©Magee/Kramer 2 nd Edition condition synchronization in C and pthreads pthreads provides the following condition variable functions: (Remember, a condition variable is used with an associated mutex lock) notify: pthread_cond_signal(&cond_var) Wakes up a single thread that is waiting on a condition variable. notifyAll: pthread_cond_broadcast(&cond_var) Wakes up all threads that are waiting on a condition variable. Wait: pthread_cond_wait(&cond_var, &cond_mutex) Waits to be notified by another thread. The waiting thread releases the synchronization lock associated with the cond var (i.e. the ‘monitor lock’). When notified, the thread must wait to reacquire the monitor lock before resuming execution.

12. Concurrency: monitors & condition synchronization12 ©Magee/Kramer 2 nd Edition condition synchronization in pthreads We refer to a thread entering a monitor when it acquires the mutual exclusion lock associated with the monitor and exiting the monitor when it releases the lock. wait - causes the thread to exit the monitor, permitting other threads to enter the monitor. Thread AThread B wait notify Monitor data

13. Concurrency: monitors & condition synchronization13 ©Magee/Kramer 2 nd Edition monitor lock (here a queue) wait Monitor data waiting Thread C Thread E Thread B Thread F Thread A notify (then release lock) Thread B Thread F Thread E Thread A Thread C Thread A

14. Concurrency: monitors & condition synchronization14 ©Magee/Kramer 2 nd Edition condition synchronization in C/pthreads FSP: when cond act -> NEWSTAT C/pthreads: void *act() { pthread_mutex_lock(); while (!cond) pthread_cond_wait(); // modify monitor data pthread_cond_broadcast()//notifyall pthread_mutex_unlock(); } The while loop is necessary to retest the condition cond to ensure that cond is indeed satisfied when it re-enters the monitor. notifyall is necessary to awaken other threads that may be waiting to enter the monitor now that the monitor data has been changed.

15. Concurrency: monitors & condition synchronization15 ©Magee/Kramer 2 nd Edition CarParkControl - condition synchronization – arrive() void *arrive() { pthread_mutex_lock( &condition_mutex ); while( spaces == 0 ) { pthread_cond_wait( &condition_cond, &condition_mutex ); printf("spaces value in arrival on waking: %d\n",spaces); } --spaces; printf("spaces after an arrival: %d\n",spaces); pthread_cond_signal( &condition_cond ); pthread_mutex_unlock( &condition_mutex ); } Is it safe to use notify (i.e. signal) here rather than notifyAll (broadcast) ?

16. Concurrency: monitors & condition synchronization16 ©Magee/Kramer 2 nd Edition CarParkControl - condition synchronization – depart() void *depart() { pthread_mutex_lock( &condition_mutex ); while ( spaces == CAPACITY ) { pthread_cond_wait( &condition_cond, &condition_mutex ); printf("spaces value in depart on waking: %d\n",spaces); } ++spaces; printf("spaces after a departure: %d\n",spaces); pthread_cond_signal( &condition_cond ); pthread_mutex_unlock( &condition_mutex ); } Is it safe to use notify here rather than notifyAll ?

17. Concurrency: monitors & condition synchronization17 ©Magee/Kramer 2 nd Edition models to monitors - summary Each guarded action in the model of a monitor is implemented as a condition variable using a while loop and wait to implement the guard. The while loop condition is the negation of the model guard condition. Active entities (that initiate actions) are implemented as threads. Passive entities (that respond to actions) are implemented as monitors. Changes in the state of the monitor are signaled to waiting threads using signal() or broadcast().

18. Concurrency: monitors & condition synchronization18 ©Magee/Kramer 2 nd Edition 5.2 Semaphores Semaphores are widely used for dealing with inter-process synchronization in operating systems. Semaphore s is an integer variable that can take only non-negative values. down(s): if s >0 then decrement s else block execution of the calling process up(s): if processes blocked on s then awaken one of them else increment s The only operations permitted on s are up(s) and down(s). Blocked processes are held in a FIFO queue. (think of s as a count of ‘free’ resources)

19. Concurrency: monitors & condition synchronization19 ©Magee/Kramer 2 nd Edition modeling semaphores const Max = 3 range Int = 0..Max SEMAPHORE(N=0) = SEMA[N], SEMA[v:Int] = (up->SEMA[v+1] |when(v>0) down->SEMA[v-1] ), SEMA[Max+1] = ERROR. To ensure analyzability, we only model semaphores that take a finite range of values. If this range is exceeded then we regard this as an ERROR. N is the initial value. LTS?

20. Concurrency: monitors & condition synchronization20 ©Magee/Kramer 2 nd Edition modeling semaphores Action down is only accepted when value v of the semaphore is greater than 0. Action up is not guarded. Trace to a violation: up  up  up  up

21. Concurrency: monitors & condition synchronization21 ©Magee/Kramer 2 nd Edition semaphore demo - model LOOP = (mutex.down->critical->mutex.up->LOOP). ||SEMADEMO = (p[1..3]:LOOP ||{p[1..3]}::mutex:SEMAPHORE(1)). Three processes p[1..3] use a shared semaphore mutex to ensure mutually exclusive access (action critical ) to some resource. For mutual exclusion, the semaphore initial value is 1. Why? Is the ERROR state reachable for SEMADEMO ? Is a binary semaphore sufficient (i.e. Max=1 ) ? LTS?

22. Concurrency: monitors & condition synchronization22 ©Magee/Kramer 2 nd Edition semaphore demo - model

23. Concurrency: monitors & condition synchronization23 ©Magee/Kramer 2 nd Edition Summary  Concepts monitors: encapsulated data + access procedures mutual exclusion + condition synchronization  Model guarded actions  Practice ‘private’ data and exclusive access using locks wait, notify and notifyAll for condition synchronization single thread active in the monitor at a time