Operating Systems CMPSC 473

1. Operating SystemsCMPSC 473 Mutual Exclusion Lecture 12: October 7, 2010 Instructor: Bhuvan Urgaonkar

2. Agenda • Last class • Liveness conditions accompanying mutual exclusion • Mutex locks • Peterson’s solution: based only on atomic loads/stores • Solutions based on test&set and swap atomic instructions • Next: Solutions that eliminate busy wait • Condition variables • Semaphores

3. Condition Variables • Mutex locks waste CPU cycles via busy wait • Mutex locks not suitable for making a thread wait till a certain condition becomes true • One Solution: Condition variables • A condition variable indicates an event and has no value • Manipulated using wait() and signal() operations

4. Condition Variables • Wait operation • When a thread executes a wait call on a condition variable, it is immediately suspended • It is now is waiting for the event that is represented by the condition variable to occur • Signal operation • Eventually, a thread will cause the event to occur after which it will call the signal method on the corresponding condition variable • If there are threads waiting on the signaled condition variable, the “monitor” will allow one of the waiting threads to resume its execution • If there is no waiting thread on the signaled condition variable, this signal is lost as if it never occured

5. cond_t not_full, not_empty; int count == 0; Produce() { if (count == N) wait (not_full); … ADD TO BUFFER, count++ … signal (not_empty); } Consume() { if (count == 0) wait (not_empty); … REMOVE FROM BUFFER, count-- … signal (not_full); } What is wrong?

6. cond_t not_full, not_empty; mutex_lock m; int count == 0; Produce() { mutex_lock (m); if (count == N) wait (not_full,m); … ADD TO BUFFER, count++ … signal (not_empty); mutex_unlock (m); } Consume() { mutex_lock (m); if (count == 0) wait (not_empty,m); … REMOVE FROM BUFFER, count-- … signal (not_full); mutex_unlock (m); } NOTE: You can improve this code for more concurrency!

7. Condition Variables • Wait operation • When a thread executes a wait call on a condition variable, it is immediately suspended • It is now is waiting for the event that is represented by the condition variable to occur • Signal operation • Eventually, a thread will cause the event to occur after which it will call the signal method on the corresponding condition variable • If there are threads waiting on the signaled condition variable, the monitor will allow one of the waiting threads to resume its execution • If there is no waiting thread on the signaled condition variable, this signal is lost as if it never occured • Always used in conjunction with a mutex lock

8. Condition Variables • pthreads functions/data struct • pthread_cond_t condition = PTHREAD_COND_INITIALIZER; or pthread_cont_init (condition, attr) • pthread_cond_wait (condition, mutex) • pthread_cond_signal (condition)

9. Semaphores Definition (Dijkstra) • ACK: Lot of material borrowed from “The Little Book of Semaphores” byAllen B. Downey • Available online (free) at: http://www.greenteapress.com/semaphores/

10. Semaphores Definition (contd.) • Can only be accessed via two indivisible (atomic) operations • wait (S) { /* also called decrement */ while S <= 0; // no-op S--; } • signal (S) { /* also called increment */ S++; } • Note: Busy waiting in these definitions, we will see how they can be improved to avoid busy waiting Entry section Exit section

11. Semaphore Usage (Prelim.) • Can only be accessed via two indivisible (atomic) operations • wait (S) { /* also called decrement */ while S <= 0; // no-op S--; } • signal (S) { /* also called increment */ S++; } • Provides mutual exclusion • Semaphore S; // initialized to 1 • wait (S); Critical Section signal (S);

12. Consequences of the definition • In general, there is no way to know before a thread decrements a semaphore whether it will block • After a thread increments a semaphore and another thread gets woken up, both threads continue running concurrently. There is no way to know which thread, if either, will continue immediately • When you signal a semaphore, you don’t necessarily know whether another thread is waiting, so the number of unblocked threads may be zero or one.

13. Meaning of Semaphore Values • If the value is +, it represents the number of threads that can decrement without blocking • If the value is -, it represents the number of threads that are blocked and are waiting • If the value is 0, it means there are no threads waiting, but if a thread tries to decrement, it will block

14. Why Semaphores? • Semaphores impose deliberate constraints that help programmers avoid errors • Solutions using semaphores are often clean and organized, making it easy to demonstrate their correctness • Semaphores can be implemented efficiently on many systems, so solutions that us semaphores are portable and efficient

15. Counting and Binary Semaphores • Counting semaphore – integer value can range over an unrestricted domain • Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement • Also known as mutex locks • Can implement a counting semaphore S as a binary semaphore - will return to this later

16. Semaphore Usage: Basic Synchronization Patterns • Not just for Mutex but many other purposes! • Signaling • Rendezvous • Mutex • Multiplex • Barrier • Re-usable barrier • Queues • FIFO Queue We will study these

17. Signaling • Initial value of sem = 0 • This ensures a1 executes before b1 • Why?

18. Rendezvous • We want a1 before b2 and b1 before a2 • Hint: Create two semaphores aArrived (indicating A has arrived at the rendevous) and bArrived both initialized to 0;

19. Rendezvous: Solution 1 • Initialization: • aArrived = 0; • bArrived = 0;

20. Rendezvous: Solution 2 • Initialization: • aArrived = 0; • bArrived = 0;

21. Rendezvous: Solutions 1 and 2 Compared • Which is likely more efficient? • Hint: Solution 2 might require one • extra context switch • Initialization: • aArrived = 0; • bArrived = 0;