CST 334: Week 6

This week we learned about condition variables, semaphores, and common concurrency problems. In terms of conditional variables, they are useful when we want to make a thread sleep rather than spin as it waits to complete its execution. When a thread begins to spin as it waits for its turn with a lock, the thread still utilizes a substantial amount of processing power. To salvage or preserve this power, we can instead teach the thread to sleep rather than spin by applying conditional variables. A thread that chooses or needs to wait for a certain condition to be met will go to sleep using the wait() function, but its not until it is signaled by another thread that the condition has been met and it wakes again. The other thread can signal the initial thread in question by calling the signal() function or signal all threads waiting for the same condition at once by calling the broadcast() function. In terms of semaphores, they are similar to ticket locks as they both track values that determine whether the critical section is open to waiting threads. How semaphores differ from ticket locks is that they allow threads to sleep rather than spin, like conditional variables, and the value they track is how many more threads can run concurrently as opposed to ticket locks, which track the queue of threads waiting to complete their execution. Both a very efficient tools for maintaining CPU cycles, but we’ve learned it essential to watch out for concurrency issues that may come up with these techniques, such as race conditions and deadlock.