[Ownaginatios]

Similar to software engineering 3A04, 3BB4 is also one of the few courses you should really pay close attention to and understand. While 3A04 focuses more on the structural design of software (classes, modules, OO-architecture etc), 3BB4 focuses on how software components interact with each other. In my opinion this is something very important to understand - and funny enough: a lot of people working as software engineers seem to not even understand it well themselves!

Software engineering 3BB4 focuses on the concurrent design of software. This means, designing software with multiple simultaneous paths of execution. For most traditional programs, execution is completely linear and predictable following a single thread of instruction execution. In a multi-threaded programs, however, different 'processes' or 'threads' run simultaneously. In this course, you learn about how to coordinate interaction between these threads because in multithreaded programs, resources typically need to be shared and no two threads can have those resources at the same time. In traditional household computers, threads don't really execute simultaneously due to the processor itself having only one path of execution. Each thread gets a slice of time to do something before being unloaded randomly during execution for another thread to have its slice of time to use the processor. This happens so fast, however, that from the user's view it looks like everything is happening at the same time. Since multicore processors (processors that have 2, 4, 6, 8 or even 12 paths of execution) are becoming more prevalent, some multithreaded programs can actually have more than one of their threads executing at a time - so the material in this course is one of the hot things in the industry right now.

This course is interesting because it does not take the traditional approach to teaching concurrent design. In sister courses to this, such as SFWR ENG 3S03 taken by mechatronics engineers, this material is taught by literally making low level context switching components using C++. In 3BB4 however, everything is taught from a completely theoretical point of view without regards to hardware. I think that's what makes this course unique among others like it at other universities.

The course begins with teaching basic finite state machines, which are here called 'labelled transition systems'. This is to abstract the idea of a computer out of the whole thing and simplify it down to simply FSMs. They start very simple, such as this for a light switch : on -> off -> on; a circular FSM.

Gradually the course builds up to the first concurrency principle - the mutex lock or the semiphore. A mutex lock (mutual exclusion lock) only allows a limited number of users to use some resource... that limited number usually being 1. Take for example a washroom at a school. Only one student can use the washroom at a time. Multiple students may fight to get in the door - but in the end, there will always be one student who gets in first. The student has control over the washroom now, and no other student can try and take it until he leaves. In programs, these sections (like the washroom) are called critical sections. Only one thread may be executing the code in it at a time. Examples of why you would want this is to prevent two threads from modifying an array at once. If one wants to add an element to the array, and then increment the number of elements in the array while another wants to delete an element and then decrement the number of elements in the array - this can go wrong if it happens simultaneously. Say there are 3 elements in the array. If the incrementing thread records '3' increments it, adds the element, and then writes 4 back to memory, at the same time the decrementing thread may record '3' decrement it and write back 2 right after - leaving the counter inaccurately at 2 when it should be 3.

Following that, things move into the one big concurrency issue - deadlock. Deadlock is a situation where all threads end up waiting on each other to do something. Take an example where a thread has to acquire resource A and resource B before it can do something and then release both resources. Suppose there are two threads that need to do this called thread 1 and thread 2. Thread 1 acquires A and simultaneously thread 2 acquires B. Thread one goes into sleep waiting for resource B to be free, and thread 2 goes into sleep waiting for resource A to be free. Both threads are now waiting on each-other to release what they have. You learn techniques to get around this, such as having a timeout where thread 2 will give up its resource if it can't acquire A in X amount of time. You also learn to consider situations such as thread 2 crashing and never releasing B - you have to account for these things in programs. There are I believe 5 principles of deadlock, but they're all a manifestation of either of those situations.

Those are literally the two things you pick up in this course. The rest of the course is trying to solve problems using mutex locks/semiphores with consideration of the potential deadlock that can occur in each. Don't think for a second that this is really easy, haha. All the work you do is in a special simulation language called LTSA (labelled transition system analyzer). A lot of the content of this course has to deal with learning how to use that language properly. The language is interesting in that all the 'threads' of your program are written as finite state machines and the interaction between them is through their transitions (i.e. if in one FSM, you get from state A to state B when transitioning on f, and in another FSM a transition from C to D occurs on f, then transitioning on f MUST cause the state transition in both of these FSMs). The compiler of the language automatically meshes all your FSMs together (which can sometimes have thousands of states) so that you can watch the transitions occur in real time. You'll likely think it's the stupidest thing ever at first, but it's actually very smart as all it leaves you to worry about is the concurrency of the whole thing. In can automatically detect potentially deadlock as well. Some of these programs you are then required to write in Java using Java's built in concurrency tools (synchronized blocks, some semiphores .etc).

The rest is analysis (i.e. what happens if this FSM takes this transition a lot less/more than this one). LTSA has some built in tools to make your FSMs 'starve' from not frequently getting to take transitions. It's not complicated stuff.

Overall, I found the course really made you think. Even though there's just a small fundamental set of things to know, it still takes a lot of time to consider all the possibilities for screw up in the program. The assignments are long and get pretty tough, but you get a good sense of accomplishment once they are complete. It's one of those courses that you don't really appreciate until a while after it is over.

In my year when I took it, Dr. Janicki was teaching the course. Normally Dr. Maibaum teaches the course, but I believe he was on sabbatical at the time. I only went to maybe 2 or 3 courses (as one typically does with Janicki's classes), but his notes and the book had pretty much everything that mattered.

The breakdown was as follows:

27% - Three assignments worth (3 x 9%)
18% - One midterm worth
55% - Final exam

The midterm was kind of stupid; Janicki just gave out Dr. Maibaum's midterm from the year before, so of course everyone did well. Even if you hadn't seen that ahead of time though, but did the assignments - it was very straight forward. Just an easier version of the assignments completely doable in the time given.

The exam was challenging. Dr. Janicki took Maibaum's exam from the previous year, but added some theoretical stuff that isn't normally part of the course - Petri Nets and Multidimensional semiphores. If you want to know what a Petri net is, just look it up - it's just a different way of looking at a concurrent system as a system with states and tokens rather than an FSM. We had had to do one for each assignment, but a lot of people skipped them out of confusion. Multidimensional semiphores I figured out during the exam, haha. I don't remember exactly what it was, but if you get a question on it and think about it long enough, it eventually clicks. Those were the only hard things and I don't think they will show up again in the future if Maibaum is teaching the course. Everyone was allowed a single double sided cheat sheet, which was mostly just for remembering LTSA syntax, the causes of deadlock and some examples here and there.

I ended up getting a 12 in the course. It was probably one of my favourite courses so far in university for how much it challenged you to just think rather than follow rules.

Thank you for a great course review. Also, the longest course review either? haha