Monitors and Blocking Synchronization

1. Monitors and Blocking Synchronization By Tal Walter

2. Outline • Monitors • Conditions • Readers-Writers Locks • Reentrant locks / semaphores implementations

3. Motivation for Monitors • Programming with locks often gets complicated and cumbersome • In order to program something that uses multiple cores, you have to use and understand locks. • Monitors encapsulate a class with it’s synchronization needs • Provides another layer of abstraction • User doesn’t have to be aware of locks at all.

4. What’s a Monitor? • Monitors are a structured way of combining synchronization and data. • A class encapsulates both data and methods in the same way that a monitor combines data, methods, and synchronization in a single modular package.

5. An Example mutex.lock(); try { queue.enq(x) } finally { mutex.unlock(); } • Suppose an application has two threads, a producer and a consumer, that communicate through a shared FIFO queue. • We could have the threads share two objects: an unsynchronized queue, and a lock to protect the queue. • The producer would be:

6. An Example • Suppose the queue is bounded. • What to do on queue.enq(x)? • Would it pass? What if the queue is full? Would it block? Depends on internal state mutex.lock(); try { queue.enq(x) } finally { mutex.unlock(); }

7. An Example • The user of the queue will have to figure out a cumbersome synchronization protocol. • The queue should manage its own synchronization. • A queue that also has the synchronization logic encapsulated is a synchronized queue, a Monitor.

8. Spinning/Blocking-a reminder • If a thread cannot immediately acquire a lock, it can either spin, repeatedly testing whether the desired event has happened, or it can block, giving up the processor for a while to allow another thread to run.

9. Conditions – Why? • Back to the queue, a thread that waits to deq(x) on an empty queue needs to be blocked • After the waiting thread went to sleep, it needs a way to be awakened, to reacquire the lock and try again. • That’s where conditions come in:

10. Conditions – What? • A condition is an object that’s associated with a lock, and is created by calling that lock’s newCondition() method. • If the thread holding that lock calls the associated condition’s await() method, it releases that lock and suspends itself, giving another thread the opportunity to acquire the lock.

11. Conditions – What? • When that condition is signal()ed by some other thread, the noble thread awakens (or not) and reacquires the lock, perhaps competing with other threads in the process.

12. A Monitor Lock Lock() waiting room unLock() Critical Section 12

13. Unsuccessful Deq Lock() waiting room Deq() await() Critical Section Oh no, Empty! 13

14. Another One Lock() waiting room Deq() await() Critical Section Oh no, Empty! 14

15. Enqueur to the Rescue Yawn! Yawn! Lock() waiting room Enq( ) signalAll() Critical Section unLock() 15

16. Monitor Signalling Yawn! Yawn! waiting room Critical Section Awakend thread might still lose lock to outside contender… 16

17. Dequeurs Signalled Yawn! waiting room Found it Critical Section 17

18. Dequeurs Signalled Yawn! waiting room Critical Section Still empty! 18

19. Dollar Short + Day Late waiting room Critical Section 19

20. Lost Wake-Up Yawn! Lock() waiting room Enq( ) signal () Critical Section unLock() 20

21. Lost Wake-Up Yawn! Lock() waiting room Enq( ) Critical Section unLock() 21

22. Lost Wake-Up Yawn! waiting room Critical Section 22

23. Lost Wake-Up waiting room Found it Critical Section 23

24. What’s Wrong Here? zzzz….! waiting room Critical Section 24

25. A Queue Example • An example of a queue with conditions who are Signal()ed everytime instead of using SignalAll() when transitioning:

26. A Queue Example

27. Readers-Writers Locks • A lot of times we can split a data structure’s methods into “readers” that return information about the object’s state without modifying the object, and “writers” who actually modify the object. • There can be many readers at once, or a writer, but only one. • A readers–writers lock allows multiple readers or a single writer to enter the critical section concurrently. • In practice, we’ll call readLock().lock() and writeLock().lock() accordingly, instead of calling lock.lock().

28. Readers-Writers Locks • We’ll have a look at 2 Readers–Writers Lock implementations. • First one is pretty straight-forward, The SimpleReadWriteLock

29. SimpleReadWriteLock

30. ReadLock

31. WriteLock OR

32. Introducing fairness into the scheme • If readers are much more frequent than writers, as is usually the case, then writers could be locked out for a long time by a continual stream of readers. • The FifoReadWriteLock class, that will be shown next, shows a way to give writers priority.

33. FifoReadWriteLock – The Idea • FifoReadWriteLock ensures that once a writer calls the write lock’s lock() method, no more readers will be able to acquire the read lock until the writer has acquired and released the write lock. • Eventually, the readers holding the read lock will drain out without letting any more readers in, and the writer will acquire the write lock.

34. FifoReadWriteLock

35. ReadLock

36. WriteLock

37. The Reentrant Lock • It’s simply a lock that can be obtained multiple times by the same thread that originally acquired it. • Let’s see how do we implement a reentrant lock using a non reentrant one and a condition:

38. The Reentrant Lock – implementation

39. Another use for conditions - Semaphores • We all know what a semaphore is, let’s see the implementation (don’t worry it’s pretty short)

40. Semaphore implementation

41. Summary • Monitors • Conditions • Readers-Writers Locks • Reentrant locks / semaphores implementations

42. That’s it!