Week 29

Another week down, another set of projects finished. Not much more to say really. There is still the topic of needing to take a foreign language course to sate the requirements, but that's its own matter.

As for this week in Operating Systems:
The topics were on 

Condition Variables -  The book itself expressly calls them 'queues', despite behaving like a memory variable. Threads can place themselves onto said 'queue' when a condition isn't satisfied. While waiting for the condition to be satisfied, the thread goes to sleep. No, really. While the condition the thread is waiting on isn't met, that thread would still be 'spinning', or 'running around in circles in place'. This wastes precious CPU time. The thread enters the sleep-like waiting state with the wait() method, which frees up the CPU to work on other threads. When another thread has done what it needs to it uses the signal() method to wake up a sleeping thread once the condition has been (hopefully) satisfied. This section also placed plenty emphasis on the Producer/Consumer, or Bounded Buffer, problem. The way my head wrapped itself around the Bounded Buffer, came as a likeness of a common scene in Factorio, in the form of a conveyer linking a mining drill to a furnace. The drill pulls up a chunk of ore and puts it on the belt which delivers it to the furnace for refinement. It's probably an oversimplification of what really goes on in an actual Bound Buffer scenario, but at least the idea got across.

Semaphores - I'm not sure whether to call them evolutions, upgrades, or side-grades to Condition Variables because of the many seeming similarities between the two and locks. Who am I kidding? Locks are semaphores. Specifically, binary semaphores. Semaphores are explicitly defined as "objects with an integer value," and they are manipulated with the routines sem_wait() and sem_post(). From what I gathered, these are the semaphore counterparts to the wait() and signal() methods the condition variables use. Another use for Semaphores is limiting how many threads could run the same section of code at once. Suppose multiple threads are running the same code and there is a section that is particularly memory-intensive, to the point where if all threads were running it at once, the amount of memory needed would vastly outgrow what's available. A semaphore could limit the number of threads using that code, and keep the machine from slowing to a pace that makes a snail look like a Formula 1 racer. There was also a mention of the Dining Philosophers problem, which demonstrates a deadlock situation and is detested by the book for its lack of practical utility, and mention of similar problems like the 'Cigarette Smoker's Problem' and the 'Sleeping Barber Problem'. Maybe I'll look into them some day.

Concurrency Bugs - The names of the things that can go wrong in a complex, concurrent program. There really isn't a whole lot to say here. The chapter was a general 'who's who?' bit, broken up into the deadlocks and non-deadlocks. In the non-deadlocks category, there were the atomicity violations, bugs that occur when code sections that shouldn't be interrupted are interrupted, and order violations, bugs that occur when code that should be executed in a specific order aren't executed in that order. Deadlocks are what happens when a thread holds a lock that another thread is waiting on, while waiting on the lock the other thread has. There are four conditions that must be true for a deadlock to occur: Mutual exclusion - Threads claim exclusive control of needed resources. Hold-and-wait - threads hold their resources while waiting for more. No Preemption - resources cannot be forced out of threads holding them. Circular wait - A chain of threads exists where each thread holds resources requested by the next thread in the chain. The book does go over a number of ways to break any of the four conditions for deadlock, such as atomically acquiring locks, forcing partial ordering, or reducing the reliance on explicit locks. These tricks can be used to mitigate the risk of a deadlock scenario. Key word here: mitigate. In a sufficiently complex, concurrent program, there is always some risk of a deadlock situation. There was also mention of a rather interesting deadlock scenario: the Livelock. Livelocks are similar to deadlocks in which no meaningful progress is being made. The key difference is that the threads involved are still running, as opposed to waiting in a deadlock, each reacting to the other. The weird part, at least in my experience, was the example that came to mind as I read. I caught myself thinking of a clip I had seen from Star Trek: Lower Decks, in which two of the characters(it's been a good bit since I saw the clip) use their communicators in proximity two one another at the same time and both abort their call upon realizing the other was making a call. In perfect sync with one another. Multiple times. I mean, the example works, sure, but... Really?

Outside of trying to figure out the why and where of bizarre examples, I can't say there were any real challenges afoot this week. Much of what was shown off here came across as new applications for subjects I had already seen or even applied elsewhere. 

With the very next week being the week before the final exam, I haven't any serious questions regarding the content that may be appearing on it. Much of my focus next week will be on getting the finishing touches on the group project I'm tackling solo. I've gotten more done with it than I thought I would at this point, so maybe I'm finally starting to break a years-old bad habit.