Synchronization and Deadlock CS 111 On-Line MS Program Operating Systems Peter Reiher

1. Synchronization and DeadlockCS111On-Line MS ProgramOperating Systems Peter Reiher

2. Outline • Other synchronization primitives • Synchronization mechanisms in real operating systems • Deadlocks: • What are they and why are they important? • Deadlock avoidance, prevention, detection and recovery • Related synchronization problems

3. Other Important Synchronization Primitives Semaphores Mutexes Monitors

4. 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

5. 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

6. 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

7. 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?

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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 nchannels 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

16. Completion Events • Available in Linux and other Unix systems • Used in multithreaded programs • One thread creates and starts a completion event • 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

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

18. 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

19. 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