SampleFinalCS3214F10

SampleFinalCS3214F10 - CS 3214 Sample Final Exam (Fall...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CS 3214 Sample Final Exam (Fall 2010) 1/13 Sample Final Exam (Fall 2010) Solutions are shown in this style. This exam was given Fall 2010. 1. Multithreading (18 pts) a) (15 pts) Mutexes and Condition Variables . Exercise 10 asked that you implement futures, a commonly used abstraction for task parallelism, backed by a pool of threads. Each of these threads will execute a work function that processes tasks submitted to the pool. The following 5 examples were submitted by students. Point out what is wrong with them! To keep the focus of this question on the use of mutexes and condition variables to implement the monitor abstraction (which was the point of this exercise), irrelevant details have been omitted and you should assume they are correctly implemented. // here, 'pop' returns the first element // of the pool's queue, or NULL if queue // is empty while ( !getShuttingDown(pool) ) { struct future *ftr = NULL; pthread_mutex_lock(&pool->mutex); ftr = pop(pool); pthread_mutex_unlock(&pool->mutex); while ( ftr == NULL ) { pthread_mutex_lock(&pool->mutex); ftr = pop(pool); pthread_mutex_unlock(&pool->mutex); if ( getShuttingDown(pool) ) { return NULL; } } ... process task and signal semaphore ... } i) (3pts) This attempt employs busy-waiting and does not use condition variables at all. while(1) { pthread_mutex_lock(&(pool->startWorkMutex)); if (is_empty(pool->jobs)) { pthread_cond_wait(&(pool->startWorkCondition), &(pool->startWorkMutex)); } CS 3214 Sample Final Exam (Fall 2010) 2/13 if (!pool->shuttingDown) { struct future * next_Job = poll_job(pool->jobs); pthread_mutex_unlock(&(pool->startWorkMutex)); ... process task and signal semaphore ... } else { pthread_mutex_unlock(&(pool->startWorkMutex)); break; } } ii) (3 pts) This attempt uses if instead of while. For condition variables in monitors that employ Mesa semantics (including pthreads, Javas and C#s monitors) the call to pthread_cond_wait() must always be preceded by a while. There is no guarantee that the predicate a thread is waiting for is true upon return from pthread_cond_wait(). Notably, another thread (not the one being signaled) could have picked the task from the pools queue. Note that this can happen even though pthread_cond_signal wakes up only one thread, for instance if a thread who has just completed a task acquires the lock earlier than the signaled thread. (Moreover, the POSIX standard allows pthread_cond_wait() to return spuriously without any pthread_cond_signal call having happened at all!) /* Wait for new futures to be enqueued in the thread pool's work queue. */ pthread_mutex_lock(&pool->mutex); pthread_cond_wait(&pool->cond, &pool->mutex); while (pool->futures != NULL) { if (!pool->shutting_down) { fut = pool->futures; pool->futures = pool->futures->next; // Dequeue future pthread_mutex_unlock(&pool->mutex); ... process task and signal semaphore ......
View Full Document

This note was uploaded on 12/31/2011 for the course CS 3214 taught by Professor Staff during the Fall '11 term at Virginia Tech.

Page1 / 13

SampleFinalCS3214F10 - CS 3214 Sample Final Exam (Fall...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online