Wednesday, March 11, 2009

Nature Keeps Coming With Better Idiots To Fight Concurrency

Incompetence

A friend of mine sent me a link to an article about Erlang style concurrency. Immediately MapReduce and Sawzall come to mind as smart paradigms intended to reduce (if only as a side effect) the complexity of concurrent programming to complexity of single threaded. And I almost start hoping that there'll be the next best thing since sliced bread which will make all the problems go away. But then, I look back at the code, more and more lines of which gets written every day, and chuckle. No way smart things can fix the situation, given into wrong hands (recent example: A340-600 ADAT accident).

So, what's the good that is supposed to come out of this rant? Very simple advice to make your life easier, if your IQ allows you to follow:
  • Fughet the deadlocks and race conditions, they may be the least of your worries in the sanitized world of J2EE containers (sure, take this with a grain of salt, but not too much salt, OK?).
  • Scope variables right. Not too wide, not too narrow. Using instance variables to hold request scope data is a recipe for thread safety violation and subsequent data loss and corruption. Reading configuration that doesn't change unless you redeploy the application within a loop is a recipe for a major performance impact.
  • Maintain thought over and consistent instantiation and object life cycle patterns.
Now, if you think this is way too simple and can't comprehend why something this trivial should even be explained (and feel like questioning my IQ) - well, feel free to donate something to, say, DZ to alleviate my mental pain and suffering from working with code like this on a day to day basis. Why, you ask? Well, I guess someone does need to do the dirty work...

No comments:

Post a Comment