CST334 Week 6

The week was primarily about concurrency, and among the most important things that we studied were condition variables, semaphores, implementation of a bounded buffer, synchronization barriers, the Anderson/Dahlin method, and some typical bugs in concurrency. It is true that all these topics are related, but they all deal with thread coordination in different manners.

Condition variables made sense to me once I realized they basically act like a “waiting room” for threads. A thread can go to sleep until some condition becomes true, and another thread signals it when it’s time to move forward. Semaphores felt similar at first, but I learned they’re more like counters that let a certain number of threads access something. The difference between binary and counting semaphores stood out to me. Binary feels like a simple lock, while counting semaphores allow more flexibility depending on the resource.

The hardest part this week was keeping the differences between locks and condition variables and semaphores straight. Sometimes the code patterns look almost identical, so I had to slow down and really think about which tool fits which situation. The bounded buffer example also took me a minute because both producer and consumer threads depend on each other, and timing really matters.

My biggest “aha” moment was finally understanding why busy-waiting is so bad. Seeing the example where the parent thread keeps checking a shared variable helped me see how wasteful that actually is. It also made synchronization barriers make more sense, since they force threads to meet at a certain point before continuing.

A question I still have is how real operating systems pick which synchronization tool to use behind the scenes. I also noticed connections to my earlier programming classes, where I wrote multi-threaded Java code without really understanding the deeper problems behind concurrency. This week helped me see how all these pieces fit into reliable OS design.