Week 28

Normally, I'd have something more to say in this little prelude, I guess, before getting into the post itself. I'm convinced I've said it several times at this point, but I always fall short of things to say. And, now that I'm writing, I don't think that's really changed. Far and away, the main source of these recent posts content has been Sam's prompt. Might end up keeping it for my future classes.

As for this week, once the midterm and its difficulties were done and out of the way, we covered:
Concurrency and Threads - The general idea of, and motivation to use threads. Threads are, for lack of a better phrase, processes within processes. Strings of executions of instructions within the same process. Up until now we've had single-threaded examples, with one memory block for code, one for the heap, and one for the stack. And much of what happens between threads is about the same as what happens between processes, switching from one thread to another within a process is a context switch even within the same process. There are a few key differences, of course. For one, a multi-threaded process has multiple stacks, one for each thread, while sharing the same the code and heap blocks. There was also discussion on how and why multi-threaded programs are prone to becoming indeterminate and why its a bad thing. In short, an indeterminate program produces different results every time it's run, even with identical input. This is due to a sort of 'data race' taking place among the program's threads. Because threads run independently, there is no guaranteed order of execution, which contributes to the inconsistency. There are dedicated synchronization tools to counter this randomness, however. On of which is the atomic operation. In an age passed, atoms were thought to be indivisible. Modern physics has this disproven, but the old idea lives on in computing concept. Atomic operations are all-or-nothing; They cannot be interrupted. Full-stop. A simple integer update, like 'x = x + 1', may seem atomic, but is broken up into three operations: Read, Modify, and Write. That makes two places where it can be interrupted; where another thread can do something else to 'x'. By making it into an atomic operation we don't take that risk as all three operations complete before anyone else gets the opportunity to do anything else.

Thread API - How to manipulate threads directly in the program. In C, threads are created and defined through the family of 'pthread_' methods, and have four arguments, thread, attr, start_routine, and arg. The first, thread, is a pointer to the struct pthread_t. The second, attr, is used to specify the attributes of the thread, like size and possibly scheduling priority. The start_routine is the most complex of the four, but is really just asking the question "which function should this thread start in?". The last one, arg, is the arguments passed into the function start_routine is pointing to. The book goes over a number of other functions and pointers involved, including another tool for synchronization: Locks. Speak of...

Locks - The Ironically named key to atomic operations. As a concept, the lock is a means to ensure that critical sections of code are completed in a single swoop. It does this by, perhaps literally, locking the thread in until the code is completely finished. Think of it like a parent refusing to let their child leave the table until they've finished their vegetables. The lock, called the 'mutex', also sees to it that the critical code is only used by one thread at a time. The example for this is the checkout at a store, only one customer gets serviced at a time, all others must wait their turn. Locks are evaluated, not just by if they actually work, but also by fairness and performance. Performance with locks is evaluated the same way as anything else; how much time overheads are added by the lock's involvement. Fairness can be summed up as "does every one have a fair shot at acquiring the lock once its free?". Better yet, it can be looked at as "Are any threads being starved while waiting for their turn?" While reading through, I pictured the second question being able to be addressed by creating a FIFO 'ticket lock' system. Picture the reception area for an office or something, the sort of place where they have their clientele take numbers on walking in and calling the numbers in order. (Three different real-life scenarios to explain code in a single topic, it'd be scary if I didn't find that amusing)

As one could probably guess, there were a lot of aha moments this week. Too many for me to keep track of all of them. Though I do expect to see much fewer of them next week. The book itself stating that computers "are hard enough to understand without concurrency," and with concurrency "it simply gets worse." I mentally asked "how worse?" "Much worse." the book responded. I am not looking forward to next week's programming assignment...