Consider this lock implementation using a simple flag: void lock(int *flag) { while (*flag == 1) ; // spin *flag = 1; } This implementation correctly provides mutual exclusion.

Assume there is no space left on the heap at the beginning (bytesLeft = 0). Three threads are run in the following order: T1: allocate(100) and then T2: allocate(20) and then T3: free(30). Which of these is a possible final outcome?

The following implementation of thread_join() and thread_exit() is a little bit different from what you saw in lecture. Specifically, lines c2 and c3 have been swapped. Do they still work correctly? void thread_join() { void thread_exit() { mutex_lock(&m); // p1 mutex_lock(&m); // c1 while (done == 0) // p2 cond_signal(&c); // c2 cond_wait(&c, &m); // p3 done = 1; // c3 mutex_unlock(&m); // p4 mutex_unlock(&m); // c4 } }

Consider the following code executed by two threads concurrently, where balance is a shared global variable initially set to 100: balance = balance + 1; Assume this single C statement compiles to three assembly instructions (load, add, store) which are each atomic. What are all the possible final values of balance after both threads complete?

A programmer runs their multithreaded program 1000 times and never observes a bug. What can they conclude?

Assume there is no space left on the heap at the beginning (bytesLeft = 0). Three threads are run in the following order: T1: allocate(50) and then T2: allocate(30) and then T3: free(50). What is the final outcome?

What is the primary advantage of a thread context switch over a process context switch?

For questions 29–30, consider the following producer/consumer implementation using a shared bounded buffer of size 1. There are two producer threads and two consumer threads. Assume the mutex and condition variable are correctly initialized. The variable count tracks the number of items in the buffer (initially 0). int count = 0; mutex_t m; cond_t cv; void *producer(void *arg) { while (1) { mutex_lock(&m); // P1 if (count == 1) // P2 cond_wait(&cv, &m); // P3 count = 1; // P4 fill_buffer(); // P5 cond_signal(&cv); // P6 mutex_unlock(&m); // P7 } } void *consumer(void *arg) { while (1) { mutex_lock(&m); // C1 if (count == 0) // C2 cond_wait(&cv, &m); // C3 count = 0; // C4 use_buffer(); // C5 cond_signal(&cv); // C6 mutex_unlock(&m); // C7 } }

The wait(cv, lock) operation atomically releases the lock and puts the calling thread to sleep. When the thread is later woken up, it re-acquires the lock before wait() returns.

What is the key advantage of implementing thread_join() using a condition variable plus a done flag, compared to simply spinning on the done flag?