Concurrency Programming is Like Thinking in 5 Dimensions

Concurrency is about thinking in 5 dimensions at once.

Let's consider a single code class to be a 2D space. In the end, it's flat and fits on one display.

File organization (either flat or with multiple folders) add another dimension - third one.

These are static dimensions, just like the height, width and depth in the real world.

Fourth dimension, time, has it's own analogue in the code world - execution of the code within a single thread. This is were the code comes to life and shines in its dynamics.

Concurrency brings another dimension to the mix - the fifth one, since you have to deal with multiple threads being executed. They are just like parallel dimensions in the real world. That brings us somewhat close to 5D.

So delivering reliable concurrent code is about thinking in 5 dimensions:

• it takes a bit of time and exercise to get used to to it;
• it is rather hard to visualize;
• you may want to keep the basic logical pieces as simple as possible in order to manage and evolve the entire system efficiently in your head.

Adding distributed systems could pump the dimensionality count up a little bit as well, increasing the complexity and excitement of the delivery.

NB: thinking about an entity (software system, in our case) from completely different angles helps to find simpler solutions to existing problems and challenges in the code.

Comments

[Vijay Santhanam]

Sounds cool!

I'm no mathemagician, but you're mixing design-time (code) concepts with run-time (threading). It's more like your thinking onto a projection of run-time space ..

Woh, i got a headspin

[Rinat Abdullin]

Vijay, exactly.

And since every non-reliable component or call result has undetermined state at any moment of time (failed or succeeded) we can introduce probability clouds in the picture as well.

[Steve Bjorg]

Regardless of probabilities of state, the goal of code is to always converge back on a known state. In other words, while you may not know the state of A, A + B must yield a known state C. How do you do that? Well, that's where a good library can make all the difference and hide many of the awful details of reality.

[Rinat Abdullin]

Steve, the are certain situations, where the code does not always converge to a known state (all the failures due to networking, hardware and users). And unless the code or function explicitly exposes its result or state as a strongly-typed multi-state possibility object, consumers will have to explicitly deal with completely broken states called "exceptions" (which completely blow up the execution flow).