The leap of faith

I am going to ask you to make a leap of faith, the one I made several years ago while trying to solve the problems with locks.
I will ask you to abandon notions you were accustomed to, to give up trying to reach certain objectives and to renounce to familiar entities. If this looks far-fetched, do not worry: it is still easier than taking the FP road.

  • Renounce to locks. If you have read me so far, you must be ready for this. I do not expect you to stop using them overnight, but consider them for what they are: hacks.
  • Renounce to mutable state sharing. If something is worth to be shared, male it immutable before sharing it. If you need to do data parallelism, use map reduce or some equivalent.
  • Embrace asynchronous programing. Accept that methods may not return or execute synchronously with the caller. This one is costly, but this is also the one that will free you the most.
  • Reevaluate your assumptions regarding simultaneity. It does not exist! Consider event ordering instead.

Once you make that leap, you can benefit from:

  • Code that is provably deadlock free. Hey, you have no lock nor wait.
  • A drastic reduction of potential race conditions thanks to using immutable shared state
  • A scalable application! Using those rules, and a dedicated library (IA+ threading), we have implemented services that scales from one to 32 cores. And I am confident this will go on up to 128 cores (beyond that figure we would need to migrate our thread pool implementation).
  • Stronger implementations, because you just freed yourself from major Heisenbug sources.

For me, that list was like my three wishes granted. Wait, make it four actually. This is the tool I was lacking during those endless hours trying to understand where was the race conditions, straighten up design to remove deadlocks, weeding useless locks to free up performance.

If you do not share those concerns, I am happy for you, and it probably means you are in a different environment. But if you do, I will raise my offer by adding to the mix:
the ability to tune your architecture between scalability,latency and throughput
– the ability to get metrics to assist you in that process

So, what do you think?

Solutions: Retlang

So far, I have listing the flaws of locks as an attempt to push you, my dear readers, out of this dead-end.

But so far, I have been avoiding the solution space, purposely. This post will end that!

I like immutability and message passing, therefore I suggest you look into retlang/jetlang (C#/java). Based on the actor model, it offers a nice API helping the implementation of scalable services. It has been around for a few years now, and it clearly provides value.

It turns out the framework I designed working here has similarities with it, but it uses a different approach, offering extra services without the obligation of the actor model.

I will share its design in future posts!