Upload
brit
View
37
Download
0
Embed Size (px)
DESCRIPTION
Condition variable. Announcements. Quiz Getting the big picture Programming assignments Cooperation Lecture is cut 20 mins short for Quiz and in-class activity. . Today. Races Deadlocks Dining Philosopher's Problem Condition Variable. One Worry : Races. - PowerPoint PPT Presentation
Citation preview
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 GraphNo 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 concurrent
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.