Using synchronization primitives CS-3013 A-term Using Synchronization Primitives in C, C++, and Linux Kernel CS-3013 Operating Systems A-term 2008 (Slides include materials from Modern Operating Systems, 3 rd ed., by Andrew Tanenbaum and from Operating System Concepts, 7 th ed., by Silbershatz, Galvin, & Gagne)

Using synchronization primitives CS-3013 A-term How do we actually use synchronization mechanisms in program design? Producer-Consumer (pipelined parallelism) Semaphores Mutexes for protecting shared data of pipeline Monitors (task parallelism) Mutexes for monitor locks Condition variables for waiting and signaling in user space Simulation of condition variable in kernel space Barrier Synchronization (data parallelism) Simulate with monitors in user space Simulate with Completion variables in kernel space

Using synchronization primitives CS-3013 A-term Producer-Consumer User-space operations semaphore.h — POSIX semaphores sem_init, sem_wait, sem_trywait, sem_post, sem_getvalue, etc. Usable in any C or C++ user program Thread may sleep for long period of time –Some other thread needs to awaken it Kernel-space operations asm/semaphore.h down, down_interruptible, down_trylock, up For putting a task to sleep for long time (if necessary) –Some other task needs to awaken it May not be used while holding a spinlock or in interrupt handler

Using synchronization primitives CS-3013 A-term Producer-Consumer (continued) Locking shared data structures (temporarily) User space operations pthread.h — POSIX thread tools pthread_mutex_init, pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock, etc. Only unlockable by owner (i.e., the locking thread) Normally used for short critical sections, no sleeping Kernel space operations linux/spinlock.h spin_lock, spin_trylock, spin_unlock, etc. Must never be used when task might sleep! Consume CPU cycles until locking attempt is satisfied

Using synchronization primitives CS-3013 A-term Questions?

Using synchronization primitives CS-3013 A-term Monitors Must be simulated by lower-level constructs User-space –Monitor lock  pthread_mutex_t Every monitor function must be surrounded by pair ( pthread_mutex_lock, pthread_mutex_unlock ) Not automatic in C, C++ –Condition variable  pthread_cond_t pthread_cond_wait, pthread_cond_signal, pthread_cond_broadcast pthread_cond_wait atomically releases mutex Waiting thread must re-acquire mutex upon waking –Also check situation that required the wait –Easily adaptable to object-oriented programming

Using synchronization primitives CS-3013 A-term Monitors (continued) Harder to simulate in kernel space –Monitor lock  spinlock Every monitor function must be surrounded by pair ( spin_lock, spin_unlock ) pair Not automatic –Condition variables not supported Must be simulated using counter and semaphore –Amenable to object-oriented programming style

Using synchronization primitives CS-3013 A-term Simulating Condition Variables in Kernel Space Condition variable = ( wait_count, semaphore ) Wait: while holding spinlock mon_lock wait_count++ spin_unlock(mon_lock) down(semaphore) spin_lock(mon_lock) Signal: while holding spinlock mon_lock if (wait_count > 0) { –up(semaphore) –wait_count -- } Question: is there a danger of a race condition between waiting and signalling?

Using synchronization primitives CS-3013 A-term Questions?

Using synchronization primitives CS-3013 A-term Barrier Synchronization User space May be simulated with pthread_mutex and pthread_cond_broadcast Kernel space May be simulated with completion variables See linux/completion.h and Robert Love, pp

Using synchronization primitives CS-3013 A-term Questions?