Blog

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

Deadlock and Race Detection: True/False

Suppose all three threads are modified to use mutex_trylock in a loop: each thread attempts to acquire both locks, and if the second trylock fails, it releases the first lock and retries both from the beginning (with no delay). What problem can arise?

Consider a concurrent linked list with hand-over-hand (lock coupling) locking: each node has its own lock, and a thread traversing the list locks the next node before unlocking the current one. Compared to using a single coarse-grained lock for the entire list, what is the main advantage of this approach?

In a system where every thread holds at most one lock at a time, deadlock is impossible.

Consider the following program: int x = 0; void *worker(void *arg) { x = x + 1; return NULL; } int main() { pthread_t t1, t2; pthread_create(&t1, NULL, worker, NULL); pthread_create(&t2, NULL, worker, NULL); pthread_join(t1, NULL); pthread_join(t2, NULL); printf(“%d\n”, x); return 0; } Which of the following best describes the behavior of this program?

Does Lock A provide mutual exclusion?

Locks prevent the OS scheduler from performing a context switch during a critical section.

When the OS switches between two threads in the same process, it must flush the TLB.

For questions 23–24, consider the following code snippet: int bytesLeft = MAX_HEAP_SIZE; cond_t c; mutex_t m; void* allocate(int size) { mutex_lock(&m); while (bytesLeft < size) cond_wait(&c, &m); void *ptr = ...; // get mem from heap bytesLeft -= size; mutex_unlock(&m); return ptr; } void free(void *ptr, int size) { mutex_lock(&m); bytesLeft += size; cond_signal(&c); mutex_unlock(&m); }