4061 Session 20 (3/29)

1. 4061 Session 20 (3/29)

2. Today • Posix Threads Howto Leftovers • Intro to Synchronization Issues

3. Today’s Objectives • Explain how multiple threads can get into trouble using shared data. • Give an example. • Define mutual exclusion, critical sections, and race conditions. • Explain why it’s not easy to ensure mutual exclusion between threads, and give an example of how a mutex might be implemented in an OS. • Write multi-threaded programs that use POSIX mutexes for synchronization.

4. Admin • Quiz 4 next Thursday

5. The Trouble With Threads • Concurrent access to shared data? • Is everyone just reading? We’re ok. • Is someone writing? Unsafe.

6. An Example

7. Concepts • Situations where two or more processes are reading or writing some shared data and the final result depends on who runs when are called race conditions. • The section of code where a thread accesses a shared resource non-atomically is known as a critical section. • Today is about learning some tools that we can use to synchronize access between threads to stay safe.

8. Mutual Exclusion • We wish to prohibit multiple threads from accessing shared data at the same time • We call this mutual exclusion • Shorthand: mutex • The design of primitives to enforce mutual exclusion is a central part of OS design • Take 5103 and you get to implement these primitives yourself

9. Avoiding Race Conditions • Four conditions to avoid race conditions: • No two threads simultaneously in critical region • No assumptions made about speeds or numbers of CPUs • No thread running outside its critical region may block another thread • No thread must wait forever to enter its critical region

10. The Behavior We Want

11. Bad Solution 1 • Disable Interrupts • How does this help? • Do we really want to allow user processes to disable interrupts? (what are the consequences in a multi-user system?) • Will this work on a multi-CPU system? • Conclusion: The OS may wish to disable interrupts as part of a mutex implementation

12. Bad Solution 2 • Lock Variable int lock = 0while (lock)lock=1do critical section lock=0 • What’s wrong with this solution? Remember that context switches can happen at any time.

13. Peterson’s Solution

14. Hardware Support Helps • Test and Set Lock instruction • Example: TSL RX, LOCK • All at once: • read the contents of LOCK into register RX • Store nonzero value in LOCK • How can we use this crazy instuction?

15. Building Calls for Mutex

16. Priority Inversion • Hmm...one more problem • enter_region guarantees mutex, but it uses busy waiting. • Inefficient, and... • The priority inversion problem • Two processes, H and L (high and low priority). H runs whenever it is in “ready” state, L never runs when H is ready. • L holds a lock • H wakes up from an I/O operation and decides that it wants that lock. • (Thus, L is really the highest-priority process here)

17. Mutex with Voluntary Yielding

18. Achieving Mutual Exclusion • Finding critical sections in code can be hard (debugging typically won’t work) • Luckily, the mechanisms built into UNIX make *implementing* mutex pretty easy. • Some possibilities • File locks • Pipes • Semaphores • POSIX mutex

19. POSIX Mutex • What is a POSIX Mutex? • It’s a variable that can be either locked or unlocked. • If the mutex is locked, then there is a thread that is said to “hold” the mutex. • Meant to be used for short periods of time.

20. Many Threads • So what if there are many threads that all want access to the same data? • POSIX mutex maintains a queue of processes that wish to hold the mutex. • POSIX does not guarantee the order in which processes in the queue obtain the mutex.

21. Mutex Interface • pthread_mutex_init • pthread_mutex_destroy • pthread_mutex_lock • pthread_mutex_trylock • pthread_mutex_unlock