Other Important Synchronization Primitives Semaphores Mutexes Monitors

Semaphores Counters for sequence coord. and mutual exclusion Can be binary counters or more general E.g., if you have multiple copies of the resource Call wait() on the semaphore to obtain exclusive access to a critical section For binary semaphores, you wait till whoever had it signals they are done Call signal() when you’re done For sequence coordination, signal on a shared semaphore when you finish first step Wait before you do second step

Mutexes A synchronization construct to serialize access to a critical section Typically implemented using semaphores Mutexes are one per critical section Unlike semaphores, which protect multiple copies of a resource

Monitors An object oriented synchronization primitive Sort of very OO mutexes Exclusion requirements depend on object/methods Implementation should be encapsulated in object Clients shouldn't need to know the exclusion rules A monitor is not merely a lock It is an object class, with instances, state, and methods All object methods protected by a semaphore Monitors have some very nice properties Easy to use for clients, hides unnecessary details High confidence of adequate protection

Synchronization in Real World Operating Systems How is this kind of synchronization handled in typical modern operating systems? In the kernel itself? In user-level OS features?

Kernel Mode Synchronization Performance is a major concern Many different types of exclusion are available Shared/exclusive, interrupt-safe, SMP-safe Choose type best suited to the resource and situation Implementations are in machine language Carefully coded for optimum performance Extensive use of atomic instructions Imposes a greater burden on the callers Most locking is explicit and advisory Caller expected to know and follow locking rules

User Mode Synchronization Simplicity and ease of use of great importance Conservative, enforced, one-size-fits-all locking E.g., exclusive use, block until available Implicitly associated with protected system objects E.g., files, processes, message queues, events, etc. System calls automatically serialize all operations Explicit serialization is only rarely used To protect shared resources in multi-threaded apps Simpler behavior than kernel-mode Typically implemented via system calls into the OS

Why Require System Calls for User Level Sync Operations? Mutual exclusion operations likely involve the blocking and unblocking of threads These are controlled by the operating system Critical sections in the implementations of those operations must be protected From interrupts or SMP parallelism The OS already has powerful serialization mechanisms It is easier to build on top of these

Why Is Performance More Important for Kernel Sync? Multi-threaded execution in user mode is rare High resource contention even rarer So performance problems with user-mode serialization are extremely rare The OS, on the other hand, is always running multiple concurrent threads The OS also includes many high use resources Avoiding resource contention is key to achieving good multi-processor scalability

So Why Provide Multiple Sync Primitives? If performance (and correctness) is so vital in OS sync, why not do it once? Quick and right Multiple types of locking operation lead to better performance Least restrictive locking discipline (e.g. reader/writer locks) can greatly reduce resource contention Choosing exactly when and which locks are obtained and released can minimize the time spent in the critical section Lessening the danger of deadlocks

Case Study: Unix Synchronization Internal use is very specific to particular Unix implementation Linux makes extensive use of semaphores internally But all Unix systems provide some user-level synchronization primitives Including Linux

Unix User Synchronization Mechanisms Semaphores Mostly supporting a Posix standard interface sem_open, sem_close, sem_post, sem_wait Mutual exclusion file creation (O_EXCL) Advisory file locking (flock) Shared/exclusive, blocking/non-blocking Enforced record locking (lockf) Locks a contiguous region of a file Lock/unlock/test, blocking/non-blocking All blocks can be aborted by a timer

Unix Asynchronous Completions Most events are associated with open files Normal files and devices Network or inter-process communication ports Users can specify blocking or non-blocking use Non-blocking returns if no data is yet available Poll if a logical channel is ready or would block Select the first of n channels to become ready Users can also yield and wait E.g., for the termination of a child process Signal will awaken a process from any blockage E.g., alarm clock signal after specified time interval

Completion Events Available in Linux and other Unix systems Used in multithreaded programs One thread creates and starts a completion Another thread calls a routine to wait on that completion event The thread that completes it makes another call Which results in the waiting thread being woken

Case Study: Windows Synchronization Windows includes many synchronization methods File locking Other synchronization primitives

Windows File Locking By default, Windows applications have exclusive access to files they open Can allow sharing For shared files, byte range locking provided Applications can specify ranges of bytes in the file to lock Shared or exclusive locking Windows file systems treat locks as mandatory Other applications using file mapping treat them as advisory

Other Windows Synchronization Primitives A wide range Mutexes (of several kinds) Critical regions (and guarded regions, which are less protected) Event-based synchronization E.g., waiting for an event to complete Semaphores Spin locks (several kinds) Timers