{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}


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

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

View Full Document Right Arrow Icon
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)); }
Background image of page 1

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

View Full Document Right Arrow Icon
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, Java’s 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 pool’s 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 ... pthread_mutex_lock(&pool->mutex); } } pthread_mutex_unlock(&pool->mutex); iii) (3 pts) This attempt uses a condition variable to wait for the first task only, rather than for every task. Subsequently, the thread will exit if upon completion of a task it finds the pool’s task queue empty, which means this pool runs out of threads if there is any period during which no tasks are pending.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.
  • Fall '11
  • Staff
  • OS, Virtual memory