Easter's Laws of Concurrency

I've been reading Brian Goetz' Java Concurrency in Practice. It has some mind-expanding thoughts on how subtle it can be to have threading problems in Java (or any language).

The book, and Amdahl's Law, has inspired me to codify a warning to junior developers (apprentices, in the parlance of Code to Joy), and as a reminder to the senior devs (composers).

Preface

A program is said to be thread-effective if it is:

• (a) thread-safe
• (b) efficient with respect to concurrency (e.g. throughput, UI responsiveness, etc)

Define a program's probability of thread-effectiveness (PTE) to be a metric ranging from 0 to 1, where 1 is complete certainty of thread-effectiveness.

Easter's 1st Law of Concurrency

If you don't know if your program is thread-effective, then its PTE is approximately 0.

Easter's 2nd Law of Concurrency

If you think that your program is thread-effective, then its PTE follows the specified equation:


where:

• C is a random constant between 0.01 and 0.025
• E is experience

Experience is difficult to define in practice, but an approximation is:






where:

• P is the number of programs successfully debugged with respect to thread-effectiveness
• B is the number of books read (in their entirety) on thread-effectiveness

Easter's 3rd Law of Concurrency

If a progam's thread-effectiveness is not optimal, problems will eventually manifest themselves. This manifestation will follow neither Murphy's Law nor the related Law of Demos.

Instead, the problems will manifest themselves, in production, long after you have moved onto other issues and have forgotten the intricacies of the design. This will leave you to rely on the quality of design and documentation as the primary means of fixing the problem.

One Word for Your Career: Lemmings

To be a virtuoso code composer in Java (or any language), one needs to understand concurrency and the memory model of the platform.

Many of us, myself included, should study and learn as much as we can about these subjects: they truly separate the masters from the apprentices.

The best resource going these days for Java is the book Java Concurrency in Practice. Get it. Just get it. After all, at your next interview, some of your competitors will have read it.

Here's a blog on a study group for the book.

re: title. What's with the lemmings you ask? Many, many moons ago in grad school, I played a wonderful computer game called Lemmings. The gist was that there were many lemmings who would flow from one place to another. They weren't very bright. The game-play was for you to control gates, ramps, and other control structures to guide the little buggers to safety, and to prevent them from causing chaos.

As the levels ratcheted up, the game became frenetic, both in terms of speed and the number of lemmings. I would play with a girlfriend -- one would observe and shout out shorthand commands; the other would operate the devices.

I now realize that we were pair-programming in a multi-threaded environment. If you played the game, you know that the analogy is profound.

ps. From the "brushing teeth after posting dept": this is crazy but I wonder if something like Lemmings could be used to visualize tests against multi-theaded programs. Sort of like a generalized, 2D version of JUnit's green/red bar. As you run the program, the display shows threads (lemmings) exploring the program/data space. It wouldn't be used to prove correctness but rather to show, visually, what is going on for a given execution. It might be illuminating.

pps. An idea that is much smaller in scope. If UML is used to represent the relationships and contracts between objects graphically, is there any such representation for concurrency?