CONDITION VARIABLE

Announcements

Quiz Getting the big picture

Programming assignments Cooperation

Lecture is cut 20 mins short for Quiz and in-class activ-ity.

Today

Races Deadlocks Dining Philosopher's Problem Condition Variable

One Worry: Races A race occurs when correctness of the program

depends on one thread reaching point x before another thread reaches point y/* a threaded program with a race */

int main() { pthread_t tid[N]; int i; for (i = 0; i < N; i++) Pthread_create(&tid[i], NULL, thread, &i); for (i = 0; i < N; i++) Pthread_join(tid[i], NULL); exit(0);}

/* thread routine */void *thread(void *vargp) { int myid = *((int *)vargp); printf("Hello from thread %d\n", myid); return NULL;} race.c

Race Elimination Make sure don’t have unintended sharing of state

/* a threaded program without the race */int main() { pthread_t tid[N]; int i; for (i = 0; i < N; i++) { int *valp = malloc(sizeof(int)); *valp = i; Pthread_create(&tid[i], NULL, thread, valp); } for (i = 0; i < N; i++) Pthread_join(tid[i], NULL); exit(0);}

/* thread routine */void *thread(void *vargp) { int myid = *((int *)vargp); free(vargp); printf("Hello from thread %d\n", myid); return NULL;}

norace.c

Today

Races Deadlocks Dining Philosopher's Problem Condition Variable

Another Worry: Deadlock

Def: A process is deadlocked iff it is waiting for a condition that will never be true.

Typical Scenario Processes 1 and 2 needs two resources (A and B) to

proceed Process 1 acquires A, waits for B Process 2 acquires B, waits for A Both will wait forever!

Analogous to a traffic gridlock

Deadlocking With Semaphoresint main() { pthread_t tid[2]; Sem_init(&mutex[0], 0, 1); /* mutex[0] = 1 */ Sem_init(&mutex[1], 0, 1); /* mutex[1] = 1 */ Pthread_create(&tid[0], NULL, count, (void*) 0); Pthread_create(&tid[1], NULL, count, (void*) 1); Pthread_join(tid[0], NULL); Pthread_join(tid[1], NULL); printf("cnt=%d\n", cnt); exit(0);}

void *count(void *vargp) { int i; int id = (int) vargp; for (i = 0; i < NITERS; i++) { P(&mutex[id]); P(&mutex[1-id]);

cnt++;V(&mutex[id]); V(&mutex[1-id]);

} return NULL;}

Tid[0]:P(s0);P(s1);cnt++;V(s0);V(s1);

Tid[1]:P(s1);P(s0);cnt++;V(s1);V(s0);

Deadlock Visualized in Progress Graph

Locking introduces thepotential for deadlock: waiting for a condition that will never be true

Any trajectory that en-tersthe deadlock region willeventually reach thedeadlock state, waiting for either s0 or s1 to be-come nonzero

Other trajectories luck out and skirt the dead-lock region

Unfortunate fact: dead-lock is often nondeter-ministic

Thread 1

Thread 2

P(s0) V(s0)P(s1) V(s1)

V(s1)

P(s1)

P(s0)

V(s0)Forbidden regionfor s0

Forbidden regionfor s1

Deadlockstate

Deadlockregion

s0=s1=1

Avoiding Deadlockint main() { pthread_t tid[2]; Sem_init(&mutex[0], 0, 1); /* mutex[0] = 1 */ Sem_init(&mutex[1], 0, 1); /* mutex[1] = 1 */ Pthread_create(&tid[0], NULL, count, (void*) 0); Pthread_create(&tid[1], NULL, count, (void*) 1); Pthread_join(tid[0], NULL); Pthread_join(tid[1], NULL); printf("cnt=%d\n", cnt); exit(0);}

void *count(void *vargp) { int i; int id = (int) vargp; for (i = 0; i < NITERS; i++) { P(&mutex[0]); P(&mutex[1]);

cnt++;V(&mutex[id]); V(&mutex[1-id]);

} return NULL;}

Tid[0]:P(s0);P(s1);cnt++;V(s0);V(s1);

Tid[1]:P(s0);P(s1);cnt++;V(s1);V(s0);

Acquire shared resources in same order

Avoided Deadlock in Progress Graph

No way for trajectory to get stuck

Processes acquire locks in same order

Order in which locks released im-material

Thread 1

Thread 2

P(s0) V(s0)P(s1) V(s1)

V(s1)

P(s1)

P(s0)

V(s0)Forbidden regionfor s0

Forbidden regionfor s1

s0=s1=1

Threads Summary

Threads provide another mechanism for writing concur-rent programs

Threads are growing in popularity Somewhat cheaper than processes Easy to share data between threads

However, the ease of sharing has a cost: Easy to introduce subtle synchronization errors Tread carefully with threads!

For more info: D. Butenhof, “Programming with Posix Threads”, Addison-

Wesley, 1997

Dining Philosopher’s Problem(Dijkstra ’71)

Philosophers eat/thinkEating needs two forksPick one fork at a time

Captures the concept of multiple threadscompeting for shared resources

Dining Philosopher’s Problem

Thinking about philosophers makes it easier to think abstractly.

The philosophers are very logical They want to settle on a shared policy that all can apply

concurrently They are hungry: we should let everyone eat (eventually) The policy should be totally fair.

Design an algorithm that the philosophers can follow that insures that none starves as long as each philoso-pher eventually stops eating, and such that the maxi-mum number of philosophers can eat at once.

Wrong design

void philosopher() { while(1) { sleep(); get_left_fork(); get_right_fork(); eat(); put_left_fork(); put_right_fork(); }}

Other (inefficient) ideas: use a binary semaphore before getting the forksRecommended reading:http://www.isi.edu/~faber/cs402/notes/lecture8.pdf

What can go wrong?

Starvation: Leaving some philosopher hungry (for a long time) in some situation

Deadlock: All the philosophers waits or gets “stuck”; nobody can make progress

Livelock: Everyone does something endlessly (e.g., in-finite loop) without ever eating!

Deadlock Starvation but not vice versa

Solution 1: test (get_fork blocks until you can eat)

#define N 5 /* Number of philosphers */#define RIGHT(i) (((i)+1) %N)#define LEFT(i) (((i)==N) ? 0 : (i)+1)typedef enum { THINKING, HUNGRY, EATING } phil_state;

phil_state state[N];semaphore mutex =1;semaphore s[N]; /* one per philosopher, all 0 */

void test(int i) { if ( state[i] == HUNGRY && state[LEFT(i)] != EATING && state[RIGHT(i)] != EATING ) { state[i] = EATING;

V(s[i]); }}

void get_forks(int i) { P(mutex); state[i] = HUNGRY; test(i); // try to acquire two forks V(mutex); P(s[i]); // wait if you can’t eat}

void put_forks(int i) { P(mutex); state[i]= THINKING; test(LEFT(i)); // see if LEFT can eat test(RIGHT(i)); // see if RIGHT can eat V(mutex);}void philosopher(int process) { while(1) { think(); get_forks(process); eat(); put_forks(process); }}

Solution 2

void get_forks(int i) { state[i] = HUNGRY; while ( state[i] == HUNGRY ) { P(mutex); if ( state[i] == HUNGRY &&

state[LEFT] != EATING && state[RIGHT(i)] != EATING ) { state[i] = EATING; V(s[i]);

} V(mutex); P(s[i]); }}

void philosopher(int process) { while(1) { think(); get_forks(process); eat(); put_forks(); }}void put_forks(int i) { P(mutex); state[i]= THINKING; if ( state[LEFT(i)] == HUNGRY ) V(s[LEFT(i)]); if ( state[RIGHT(i)] == HUNGRY) V(s[RIGHT(i)]); V(mutex);}

Today

Races Deadlocks Dining Philosopher's Problem Condition Variable

Difficulties in using Semaphores

Semaphores provide a very general mechanism for synchronization. The power of semaphores derives from calls to P() and V()

that are unmatched. E.g., reader/writer and dining phil. Unlike mutex (locks) where we lock() and unlock()

This means that it’s very tricky to get it right (e.g., no single fixed pattern of use and/or more than one sema-phores).

Condition Variables

Condition variables is a synchronization primitive that helps us model events (rather than resources in the case of semaphores).

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

Broadcast

The pthread_cond_broadcast() function is used when-ever 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 wait-

ing; more throughput on a multi-processor. Read-write lock.

Wakes up all waiting readers when a writer releases its lock. Recommended readinghttp://pages.cs.wisc.edu/~remzi/OSFEP/threads-cv.pdf

Producer and consumer

Important to use while statement to check the condition after waking up. It handles spurious wakeup.

cond_t empty, fill;

void produce(int item) { mutex_lock(&mutex); while (count == MAX) cond_wait(&empty, &mutex); put(item); // put an item in the cir-cular buffer cond_signal(&fill); // signal an item is filled mutex_unlock(&mutex);}

int consumer() { mutex_lock(&mutex); while (count == 0) cond_wait(&fill, &mutex); int item = get(); cond_signal(&empty); mutex_unlock(&mutex); return item;}

Next Lecture

So far we have learned basic concepts in Operating System.

This is not an OS class But, most of you didn’t take OS. We will begin to talk more about distributed systems.