SYNCHRONIZATION-2 Slides from: Computer Systems: A Programmer's Perspective, 2nd Edition by Randal E. Bryant and David R. O'Hallaron, Prentice Hall, 2011.

Last Lecture  Sharing  Synchronization

Critical Sections and Unsafe Regions Def: A trajectory is safe iff it does n ot enter any unsafe region Claim: A trajectory is correct (wrt c nt ) iff it is safe H1H1 L1L1 U1U1 S1S1 T1T1 H2H2 L2L2 U2U2 S2S2 T2T2 Thread 1 Thread 2 critical section wrt cnt Unsafe region unsafe safe

Enforcing Mutual Exclusion  Question: How can we guarantee a safe trajectory?  Answer: We must synchronize the execution of the threads so th at they never have an unsafe trajectory.  i.e., need to guarantee mutually exclusive access to critical regions  Classic solution:  Semaphores (Edsger Dijkstra)  Other approaches (out of our scope)  Mutex and condition variables (Pthreads)  Monitors (Java)

Semaphores  Semaphore: non-negative global integer synchronization variable  Manipulated by P and V operations:  P(s): [ while (s == 0) wait(); s--; ] Dutch for "Proberen" (test)  V(s): [ s++; ] Dutch for "Verhogen" (increment)  OS kernel guarantees that operations between brackets [ ] are ex ecuted indivisibly Only one P or V operation at a time can modify s. When while loop in P terminates, only that P can decrement s  Semaphore invariant: (s >= 0)

goodcnt.c: Proper Synchronization  Define and initialize a mutex for the shared variable cnt: volatile int cnt = 0; /* Counter */ sem_t mutex; /* Semaphore that protects cnt */ Sem_init(&mutex, 0, 1); /* mutex = 1 */ Surround critical section with P and V: for (i = 0; i < niters; i++) { P(&mutex); cnt++; V(&mutex); } linux>./goodcnt OK cnt=20000 linux>./goodcnt OK cnt=20000 linux> Warning: It’s much slower than badcnt.c.

Today  Producer-consumer problem  Readers-writers problem  Thread safety  Races  Deadlocks

Example: a producer-consumer problem  N buffers, counter (# of full buffers, 0 as initial value)  Producer: produces a new buffer, increments counter  Consumer: consumes a buffer, decrements counter  producer thread shared buffer consumer thread

Producer-Consumer Problem  Examples  Multimedia processing: Producer creates MPEG video frames, consumer renders them  Event-driven graphical user interfaces Producer detects mouse clicks, mouse movements, and keyboard hits and ins erts corresponding events in buffer Consumer retrieves events from buffer and paints the display producer thread shared buffer consumer thread

Producer while (true) { item * next_produced = produce(); // do nothing if buffers full while (counter == BUFFER_SIZE) ; buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; } 10 while (true) { item* next_consumed; // do nothing if no avail buff while (counter == 0); next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; consume(next_consumed); } Producer / Consumer Consumer

Producer while (true) { item * next_produced = produce(); // do nothing if buffers full mutex_lock(&mutex); while (counter == BUFFER_SIZE) { mutex_unlock(&mutex); process_yield(); // unlock and yield mutex_lock (&mutex); } buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; mutex_unlock(&mutex); } 11 while (true) { item* next_consumed; // do nothing if no avail buff mutex_lock(&mutex); while (counter == 0) { mutex_unlock(&mutex); process_yield(); mutex_lock (&mutex); } next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; mutex_unlock(&mutex); consume(next_consumed); } Improved Producer / Consumer Consumer

Condition Variables  Problem: sometimes you want to wait until a condition happens.  E.g., wait for a child to finish (often called a join())

Condition variable  A condition variable is an explicit queue that threads can put themselves on when some state of execution (i.e., some condition) is not as desired.  That is you wait on the condition.  Some other threads, when it changes the state can then wake on (or more) of the waiting threads

Condition Variables  Condition variables is a synchronization primitive that helps us model events.  A condition variable represents some condition that a thread can:  Wait on, until the condition occurs; or  Notify other waiting threads that the condition has occur  It provides a place to wait (queue).

Condition Variables  Operations on condition variables:  wait() -- Block until another thread calls signal() or broadcast() on the CV  signal() -- Wake up one thread waiting on the CV  broadcast() -- Wake up all threads waiting on the CV  Pthread  pthread_cond_wait(pthread_cond_t *c, pthread_mutex_t *m);  pthread_cond_signal(pthread_cond_t *c);  pthread_cond_broadcast (pthread_cond_t *c);  Used with mutex

 int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);  int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);  The pthread_cond_wait() and pthread_cond_timedwait() functions are used to block on a condition variable. They are called with mutex locked by the calling thread or undefined behaviour will result.  These functions atomically release mutex and cause the calling thread to block on the condition variable cond;

Broadcast  The pthread_cond_broadcast() function is used whenever the shared- variable state has been changed in a way that more than one thread can proceed with its task.  Single producer/multiple consumer problem  The producer would notify all consumers that might be waiting; more throughput on a multi-processor.  Read-write lock.  Wakes up all waiting readers when a writer releases its lock. Recommended reading

 The pthread_cond_signal() call unblocks at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond).  The pthread_cond_broadcast() call unblocks all threads currently blocked on the specified condition variable cond.  If more than one thread is blocked on a condition variable, the scheduling policy determines the order in which threads are unblocked.

Consume data No data – wait() C should have woken P!

Final version: Producer and consumer  Generalized to MAX items  Important to use while statement to check the condition after waking up. It handles spurious wakeup. cond_t empty, fill; mutex_t mutex; void produce(int item) { pthread_mutex_lock(&mutex); while (count == MAX) pthread_cond_wait(&empty, &mutex); put(item); // put an item in the circular buffer pthread_cond_signal(&fill); // signal an item is filled ptherad_mutex_unlock(&mutex); } int consumer() { pthread_mutex_lock(&mutex); while (count == 0) pthread_cond_wait(&fill, &mutex); int item = get(); pthread_cond_signal(&empty); pthread_mutex_unlock(&mutex); return item; } Use two condition variables!

Barrier Synchronization  A wait at a barrier causes a thread to wait until all threads have performed a wait at the barrier.  At that point, they all proceed.

Implementing Barriers in Pthreads  Count the number of arrivals at the barrier.  Wait if this is not the last arrival.  Make everyone unblock if this is the last arrival.  Since the arrival count is a shared variable, enclose the whole operation in a mutex lock-unlock.

Implementing Barriers in Pthreads void barrier() { pthread_mutex_lock(&mutex_arr); arrived++; if (arrived<N) { pthread_cond_wait(&cond, &mutex_arr); } else { pthread_cond_broadcast(&cond); arrived=0; /* be prepared for next barrier */ } pthread_mutex_unlock(&mutex_arr); }

Case Study: Prethreaded Concurrent Server Master thread Buffer... Accept connections Insert descriptors Remove descriptors Worker thread Worker thread Client... Service client Pool of worker threads

Today  Producer-consumer problem  Readers-writers problem  Thread safety  Races  Deadlocks

Readers-Writers Problem  Generalization of the mutual exclusion problem  Problem statement:  Reader threads only read the object  Writer threads modify the object  Writers must have exclusive access to the object  Unlimited number of readers can access the object  Occurs frequently in real systems, e.g.,  Online airline reservation system  Multithreaded caching Web proxy

Solution to First Readers-Writers Problem using mutex int readcnt; /* Initially 0 */ sem_t mutex, w; /* Both initially 1 */ void reader(void) { while (1) { P(&mutex); readcnt++; if (readcnt == 1) /* First in */ P(&w); V(&mutex); /* Reading happens here */ P(&mutex); readcnt--; if (readcnt == 0) /* Last out */ V(&w); V(&mutex); } void writer(void) { while (1) { P(&w); /* Writing here */ V(&w); } Readers: Writers rw1.c

Pthread provides read/write lock  pthread_rwlock_init()  pthread_rwlock_rdlock()  pthread_rwlock_wrlock() ReaderWriter ReaderOKNo WriterNo Access permission table

Today  Producer-consumer problem  Readers-writers problem  Thread safety  Races  Deadlocks

Crucial concept: Thread Safety  Functions called from a thread must be thread-safe  Def: A function is thread-safe iff it will always produce correct results when called repeatedly from multiple concurrent threads.  Classes of thread-unsafe functions:  Class 1: Functions that do not protect shared variables.  Class 2: Functions that keep state across multiple invocations.  Class 3: Functions that return a pointer to a static variable.  Class 4: Functions that call thread-unsafe functions.

Thread-Unsafe Functions (Class 1)  Failing to protect shared variables  Fix: Use P and V semaphore operations  Example: goodcnt.c  Issue: Synchronization operations will slow down code

Thread-Unsafe Functions (Class 2)  Relying on persistent state across multiple function invocations  Example: Random number generator that relies on static state static unsigned int next = 1; /* rand: return pseudo-random integer on */ int rand(void) { next = next* ; return (unsigned int)(next/65536) % 32768; } /* srand: set seed for rand() */ void srand(unsigned int seed) { next = seed; }

Thread-Safe Random Number Generator  Pass state as part of argument  and, thereby, eliminate static state  Consequence: programmer using rand_r must maintain seed /* rand_r - return pseudo-random integer on */ int rand_r(int *nextp) { *nextp = *nextp* ; return (unsigned int)(*nextp/65536) % 32768; }

Thread-Unsafe Functions (Class 3)  Returning a pointer to a static variable  Fix 1. Rewrite function so caller passes address of variable to store result  Requires changes in caller and callee  Fix 2. Lock-and-copy  Requires simple changes in caller (and no ne in callee)  However, caller must free memory. /* lock-and-copy version */ char *ctime_ts(const time_t *timep, char *privatep) { char *sharedp; P(&mutex); sharedp = ctime(timep); strcpy(privatep, sharedp); V(&mutex); return privatep; } Warning: Some functions like gethostbyname r equire a deep copy. Use reentrant gethostbyna me_r version instead.

Thread-Unsafe Functions (Class 4)  Calling thread-unsafe functions  Calling one thread-unsafe function makes the entire function th at calls it thread-unsafe  Fix: Modify the function so it calls only thread-safe functions

Reentrant Functions  Def: A function is reentrant iff it accesses no shared variables whe n called by multiple threads.  Important subset of thread-safe functions. Require no synchronization operations. Only way to make a Class 2 function thread-safe is to make it reentrant (e.g., r and_r ) Reentrant function has a property that it can be interrupted in the middle of its execution and then safely called again. Reentrant functions All functions Thread-unsafe functions Thread-safe functions

Thread-Safe Library Functions  All functions in the Standard C Library (at the back of your K&R text) are thread-safe  Examples: malloc, free, printf, scanf  Most Unix system calls are thread-safe, with a few exceptions: Thread-unsafe functionClassReentrant version asctime 3asctime_r ctime 3ctime_r gethostbyaddr 3gethostbyaddr_r gethostbyname 3gethostbyname_r inet_ntoa 3(none) localtime 3localtime_r rand 2rand_r