Programming with Threads Dec 6, 2001Shared variables in threaded C programsThreads memory modelExample of threads accessing another thread’s stackMapping variables to memory instancesShared variable analysisbadcnt.c: An improperly synchronized threaded programAssembly code for counter loopConcurrent executionConcurrent execution (cont)Slide 11Progress graphsTrajectories in progress graphsCritical sections and unsafe regionsSafe and unsafe trajectoriesSynchronizing with semaphoresSafe sharing with semaphoresPOSIX semaphoresSharing with POSIX semaphoresSignaling with semaphoresProducer-consumer (1-buffer)Producer-consumer (cont)Limitations of semaphoresSynchronizing with mutex and condition variablesBasic operations on mutex variablesThread-safe functionsThread-unsafe functionsThread-safe functions (cont)Slide 29Slide 30Reentrant functionsThread-safe library functionsRacesDeadlockThreads summaryProgramming with Threads Dec 6, 2001Topics•Shared variables•The need for synchronization•Synchronizing with semaphores•Synchronizing with mutex and condition variables•Thread safety and reentrancy•Races and deadlocksclass29.ppt15-213“The course that gives CMU its Zip!”CS 213 F’01– 2 –class29.pptShared variables in threaded C programsQuestion: Which variables in a threaded C program are shared variables?•The answer is not as simple as “global variables are shared” and “stack variables are private”.Requires answers to the following questions:•What is the memory model for threads?•How are variables mapped to memory instances?•How many threads reference each of these instances?CS 213 F’01– 3 –class29.pptThreads memory modelConceptual model:•Each thread runs in the context of a process.•Each thread has its own separate thread context.–Thread ID, stack, stack pointer, program counter, condition codes, and general purpose registers.•All threads share the remaining process context.–Code, data, heap, and shared library segments of the process virtual address space.–Open files and installed handlersOperationally, this model is not strictly enforced:•While register values are truly separate and protected....•Any thread can read and write the stack of any other thread. Mismatch between the conceptual and operation model is a source of confusion and errors.CS 213 F’01– 4 –class29.pptExample of threads accessing another thread’s stackchar **ptr; /* global */int main(){ int i; pthread_t tid; char *msgs[N] = { "Hello from foo", "Hello from bar" }; ptr = msgs; for (i = 0; i < 2; i++) Pthread_create(&tid, NULL, thread, (void *)i); Pthread_exit(NULL);}/* thread routine */void *thread(void *vargp){ int myid = (int)vargp; static int cnt = 0; printf("[%d]: %s (cnt=%d)\n", myid, ptr[myid], ++cnt);}Peer threads access main thread’s stackindirectly through global ptr variableCS 213 F’01– 5 –class29.pptMapping variables to memory instanceschar **ptr; /* global */int main(){ int i; pthread_t tid; char *msgs[N] = { "Hello from foo", "Hello from bar" }; ptr = msgs; for (i = 0; i < 2; i++) Pthread_create(&tid, NULL, thread, (void *)i); Pthread_exit(NULL);}/* thread routine */void *thread(void *vargp){ int myid = (int)vargp; static int cnt = 0; printf("[%d]: %s (cnt=%d)\n", myid, ptr[myid], ++cnt);}Global var: 1 instance (ptr [data])Local static var: 1 instance (cnt [data])Local automatic vars: 1 instance (i.m, msgs.m )Local automatic var: 2 instances ( myid.p0[peer thread 0’s stack], myid.p1[peer thread 1’s stack])CS 213 F’01– 6 –class29.pptShared variable analysisWhich variables are shared?Variable Referenced by Referenced by Referenced byinstance main thread? peer thread 0? peer thread 1?ptr yes yes yescnt no yes yesi.m yes no nomsgs.m yes yes yesmyid.p0 no yes nomyid.p1 no no yesAnswer: A variable x is shared iff multiple threads reference at least one instance of x. Thus:•ptr, cnt, and msgs are shared.•i and myid are NOT shared.CS 213 F’01– 7 –class29.pptbadcnt.c: An improperly synchronizedthreaded programunsigned int cnt = 0; /* shared */int main() { pthread_t tid1, tid2; Pthread_create(&tid1, NULL, count, NULL); Pthread_create(&tid2, NULL, count, NULL); Pthread_join(tid1, NULL); Pthread_join(tid2, NULL); if (cnt != (unsigned)NITERS*2) printf("BOOM! cnt=%d\n", cnt); else printf("OK cnt=%d\n", cnt);}/* thread routine */void *count(void *arg) { int i; for (i=0; i<NITERS; i++) cnt++; return NULL;}linux> badcntBOOM! ctr=198841183linux> badcntBOOM! ctr=198261801linux> badcntBOOM! ctr=198269672ctr should beequal to 200,000,000. What went wrong?!CS 213 F’01– 8 –class29.pptAssembly code for counter loop.L9:movl -4(%ebp),%eaxcmpl $99999999,%eaxjle .L12jmp .L10.L12:movl ctr,%eax # Loadleal 1(%eax),%edx # Updatemovl %edx,ctr # Store.L11:movl -4(%ebp),%eaxleal 1(%eax),%edxmovl %edx,-4(%ebp)jmp .L9.L10:Corresponding asm code(gcc -O0 -fforce-mem) for (i=0; i<NITERS; i++) ctr++;C code for counter loopHead (Hi)Tail (Ti)Load ctr (Li)Update ctr (Ui)Store ctr (Si)CS 213 F’01– 9 –class29.pptConcurrent executionKey idea: In general, any sequentially consistent interleaving is possible, but some are incorrect!•Ii denotes that thread i executes instruction I•%eaxi is the contents of %eax in thread i’s contextH1L1U1S1H2L2U2S2T2T11111222221-011-----10001111222i (thread) instrictr%eax1OK-----1222-%eax2CS 213 F’01– 10 –class29.pptConcurrent execution (cont)Incorrect ordering: two threads increment the counter, but the result is 1 instead of 2.H1L1U1H2L2S1T1U2S2T21112211222-01--11---0000011111i (thread) instrictr%eax1----0--111%eax2Oops!CS 213 F’01– 11 –class29.pptConcurrent execution (cont)How about this ordering?H1L1H2L2U2S2U1S1T1T21122221112i (thread)instrictr%eax1%eax2We can clarify our understanding of concurrentexecution with the help of the progress graphCS 213 F’01– 12 –class29.pptProgress graphsA progress graph depictsthe discrete execution state space of concurrent threads.Each axis corresponds tothe sequential order ofinstructions in a thread.Each point corresponds toa possible execution state(Inst1, Inst2).E.g., (L1, S2) denotes statewhere thread 1 hascompleted
View Full Document