Week 31 (Week 6 of CST334)

 This week we concluded our lectures on concurrency, looking at the next phase in its evolution past locks (mutexes), and trying to solve the problems they presented. Mainly, this involved the limitation locks have in that they are go-no-go, so they either let threads use them, or they do not. There is no mechanism of "checking" to see if a resource is used or not. This led us to conditional variables as a means of performing this "check."

The first iteration of this is a polling solution, where every so often, a poll is conducted to see if a variable has changed. If it has, that will trigger a condition that will lock or unlock a mutex as a way to pass over control of the resource. The problem with this method, though, is that this causes one of the threads to sit in a waiting loop, usually doing nothing but wasting computational power, holding the lock and therefore slowing down the sensor thread, and taking up CPU schedule time to do the polling.

The better version of this is a notification solution, where the thread essentially goes to sleep, surrendering the lock until it is needed, then once the condition is satisfied, the thread is woken up, and the lock is engaged again. This also leads to a bounded buffer problem, where one thread is waiting for a buffer to be non-full before writing, while another thread is waiting for the buffer to be non-empty before reading. But this is a minor inconvenience compared to the gains in time and resource efficiency compared to a simple mutex solution.

Lastly we reached a more efficient and simpler method of programming this same functionality: semaphores, a syntax methodology that is supported by the pthreads library, and is commonly used in OS kernels. This solution provides a simple syntax method of .signal() and .wait() methods that streamline the functionality of locks and conditional variables into one mechanism. The only downside we face with them is that their nature is more implicit than locks alone, and require the programmer to keep track of them in their code.

This weeks lessons very closely mirrored last weeks in that we learned the more complicated method of protecting processes/threads as we entered the world of concurrency, gradually tackling the evolving problems one by one, making the mechanisms more powerful, but also more complicated, before finally landing on a solution that handles all of the issues we've faced so far, but with a much more simple programming solution.