Notes to self

Writing correct concurrent code is hard. Writing correct and performant concurrent is significantly harder still, but before getting to that, the code must first be correct. Actually, even correct in the non-concurrent sense. Simply put, the set of potential bugs - failure modes - in a multi-threaded program is the set of failure modes for the single-threaded program, plus all of the concurrency specific failure modes.

So, a correct multi-threaded program implies a correct program in general. But in this post, I will only focus on the part that is specific to correct concurrency.

Getting concurrency right takes knowledge and analytical skills. I am an avid TDD practitioner, and I try to test-drive as much as I possibly can. However, in the world of concurrency we are faced with the problem that some bugs are simply impossible to write a test case for. Sometimes the timings required to surface a bug are just too tight and the chances too small, other times a bug is just does not exist on our specific combination of hardware and runtime.

Therefore, analyzing the code in terms of the concurrency guarantees provided by the underlying platform, is a key element of the path towards concurrency correctness. And it cannot be done without knowledge of the guarantees provided by the platform, whether it be the JVM, CLR or x86.

There are lots of failure modes specific to mutli-threaded programs. Many are quite esoteric, but three things stand out as the most basic problems: shared mutable state, publication and locking.

The first problem of concurrency is shared mutable state. There are cases where you can have deliberate under-synchronized shared mutable state, but those are as few as they are special. There are basically three ways to deal with shared mutable state:

1. Make state immutbale
2. Don't share state
3. Guard the shared mutable state by the same lock (two different locks cannot guard the same piece of state, unless you always use exactly these two locks)

The second problem of concurrency is safe publication. How do you make data available to other threads? How do you perform a hand-over? You will find the solution to this problem in the memory model of your platform and (hopefully) in the API. Java, for instance, has many ways to publish state and the java.util.concurrent package contains tools specifically designed to handle inter-thread communication. Make sure to give this problem ample focus; the bugs produced by unsafe publication can be extremely subtle, and it is easy to gloss over this problem and focus on locking instead.

The third (and harder) problem of concurrency is locking. Mismanaged lock-ordering is the source of dead-locks. Some dead-locks are practically guaranteed to always occur, while others require highly improbable timing. This problem can actually be generalized to everything that prevents a thread from making progress. Blocking operations, waits on conditions, spin-locks - these all have the same potential to stall a thread. And in this highly networked world, two threads don't even have to be on the same machine to dead-lock each other.

You can get pretty far with carefully constructed automatic test cases - and you should, but analysis is by far the most important step towards correctness in a multi-threaded program. However, you need to design and write your code with that in mind, otherwise the complexity of the code can quickly render such an analysis impossible to perform in practice.

GEdit, the "Text Editor" program in Ubuntu and other Gnome based Linux distributions, has an annoying habit of highlighting far too many non-VHDL files as VHDL. One of the file types it is particularly keen on highlighting incorrectly is SQL files. This is a pain because I use those a lot, wheres I have never had, and most likely never will have, any use at all for editing VHDL files.

So I decided to figure out how I could disable that highlighting mode once and for all. This is what I came up with on my Ubuntu Hardy box:

sudo rm /usr/share/gtksourceview-2.0/language-specs/vhdl.lang

Then restart gedit and everything VHDL'ish about it will be gone.

I watch, and sometimes post, links to many talks and videos. In this post I've collected a bunch of the better ones. So without further ado, here they are in no particular order:

• Eric Evans: What I've learned about DDD since the book
• J. B. Rainsberger: Integration Tests Are a Scam
• Tony Hoare: Null References: The Billion Dollar Mistake
• Dave West: Transcendence and Passing Through the Gate
• Dan North: Behaviour-Driven Development - a road to effective design and clean code
• Kent Beck: Responsive Design
• Robert C. Martin: Craftsmanship and Ethics
• Luke Francl: Testing is Overrated
• Steve Freeman On TDD: How Do We Know When We’re Done?
• David Hussman: Automating Business Value with FIT and Fitnesse
• Alistair Cockburn: I Come to Bury Agile, Not to Praise It

I just read Kent Becks article in the third issue of PragPup Magazine called Responsive Design.

His points ring very true with me and I am looking forward to seeing his results become a book at some point.

The fundamental thesis is that software design is not created through a rational process. Rather, the design emerges, guided by the programmer, as a response to the problem at hand.

Our illusion of control over software design is a dangerous conceit best abandoned.

To think that we are controlling the design of our software is a lie. It is this lie that leads us to believe that we can create big detailed class diagrams before the first line of code is written, and believe that they resemble anything but a fantasy.

There is a very simple way to illustrate why these upfront designs don't work. See, design exists to solve problems. The solution exists because the design does. The design causes the solution to be - brings it into being, but not only it. With a design comes also flaws and imperfections. A design contains decisions, some of which are good, some may be bad and some are compromises. A design causes not only solutions, but also new problems.

These problems may be bug or they may be limitations of sorts, but if we want them solved we will need a design. As this cycle continues, it becomes increasingly difficult to predict and describe problems and design with any level of accuracy. And as fate would have it, we really only have two levels of accuracy: accurate, or not. Even the tiniest assumption can have vast consequences for a design - only with runnable code can we really know what the truth is.

Design is not a rational process.

Design grows in response to problems. Responsive Design. But the design is not chaotic. Consider a plant: it is not design - no one can say before the seed is planted, how, exactly, it is going to look. It will grow in what way it finds most meaningful in an effort to solve the problem of survival. But its growth is not chaotic. It has definite lines, purpose and structure. It has parts that are connected in purposeful and meaningful ways.

In short: there is meaning and intent behind the growth of a plant. Likewise, there is meaning and intent behind the growth of a software design. Kents Responsive Design Project is about uncovering and coming to grips with that meaning.

I have noticed a pattern in my unit-testing recently. Ah, the word "pattern" is possibly a tad loaded for this purpose, so you might also call it a trend, a style or a convention. It's a recurring thing anyways, and it has to do with how I build my mock objects in my unit tests. I write primarily in Java, by the way, so this is where I noticed this pattern but it may just as well apply, with or without modification, to other languages.

Onwards.

The gist of it that if I have some class called a "Peg" that is used in all sorts of situations throughout my code and I need to build mocks of it for testing, then I will create a companion class called "PegThat" in the test sources tree.

This "PegThat" class will consist of nothing but static methods that all return various forms and instances of Pegs. These static methods will have names telling of certain properties of the Pegs they return. For instance, it might have an "isSquare" method that returns a square Peg.

The beauty of this naming convention is the readability that ensures in my test code. Behold:

@Test public void
squarePegsMustFitIntoSquareHoles() {
  Peg peg = PegThat.isSquare();
  Hole hole = HoleThat.hasEdges(4);
  
  assertThat(peg, fitsInto(hole));
}

That is arguable a very contrived example, but when you are building more complex mocks or instances, and these static methods need parameters or various types, then the benefit increases. Your tests can become a lot less messy and a good deal more readable.