Synchronization and Scheduling Section 6 Synchronization and Scheduling February 24th, 2017 Taught by Joshua Don

Locks Synchronization primitive Provides mutual exclusion to a critical section/shared resource Only one thread may own the lock at a time. Trying to acquire a held lock causes a thread to block. Has a holder -> implies ownership Locking mechanism struct lock lock; lock_init(&lock); lock_acquire(&lock); // critical section lock_release(&lock);

Semaphores Synchronization primitive Prevents resource contention Generalized mutex Signaling mechanism Initialized with a value. Can be ‘downed’ as many times as ‘value’ before a thread must block. Can be ‘upped’ by any thread struct semaphore sema; sema_init(&sema, 1); sema_down(&sema); // restricted mutual access sema_up(&sema);

Semaphores Continued Should you ever try to read the current value of a semaphore directly? No; it creates a race condition, the value could change right after you read it

When to use: lock vs. sema(1)?

Lock vs Sema(1) Thread A Thread B A lock is a locking mechanism, while a semaphore is a signaling mechanism A semaphore can be ‘upped’ by any thread, whereas a lock can only be released by its holder struct semaphore event; sema_init(&event, 0); Thread A Thread B // wait for event sema_down(&event); handleEvent(); createEvent(); // signal that event has occurred sema_up(&event);

Lock vs sema(1) continued In Pintos:thread.c, this exact signaling behavior is used for the idle thread! Check out the use of struct semaphore idle_started;

Monitors NOT a synchronization primitive Composed of a lock and one more condition variables Condition variables: A list of threads waiting for an event to occur There is no such thing as a ‘struct monitor’ (unless you make one!) Must acquire the lock before checking the condition! A thread acquires the monitor lock Check if some condition is not met, if so call wait(&cond, &mutex) – atomically releases the lock and adds the thread to the condition variable Another thread acquires the monitor lock The thread changes the original condition that the threads on cond are waiting for. Can now either signal cond (wake up one waiter) or broadcast (wake up all)

Monitor example struct lock mutex; struct cond_t space_available; struct cond_t data_available; AddToQueue(item) { lock_acquire(&mutex); while (queue.isFull()) { cond_wait(&space_available, &mutex); } queue.push_back(item); cond_signal(&data_available); lock_release(&mutex); RemoveFromQueue() { lock_acquire(&mutex); while (queue.isEmpty()) { cond_wait(&data_available, &mutex); } queue.pop(); cond_signal(&space_available); lock_release(&mutex);