Multi-threading the wrong way.
Some time back I had an experience down at a local supermarket, a strange experience that reminded me of a neglected topic in software development. The topic of efficient multi-threading.
Everybody knows multi-threading as a difficult thing. Multi-threaded applications are inherently difficult to develop, debug and maintain and has potentially evil pitfalls in form of race-conditions and deadlocks and what not. You need your thoughts clear and your tongue straight and remember to put locks, monitors and synchronization objects all over your code… but in the end it will make your application run at leaping speeds while utilizing the smallest of transistors in your top-notch multi-core CPU.
Well, that is what most of us programmer think. Actually the most difficult thing with threads is to make them efficient. Synchronizing threads to avoid race-conditions is rather straight forward - just surround your critical code with a lock and you’re safe. You’re safe, but that’s pretty much it.
Synchronizing threads is much more than just adding locks. A well designed application should behave in such a way that the locks are there for protection - as a last resort. To make your application truly efficient it shouldn’t depend on the locks at all. The threads should work and accees shared resources in such a way that they avoid each other… ah, anyway, back to what I experienced at my local supermarket.
The shop has 4 registers, but this day only 2 was operated. I’d been standing in line waiting for my turn for quite some time, when suddenly a critical situation occured infront of me. An old lady was trying to purchase a bag of rolls from which the price tag was missing. A pretty normal situation I would guess, I would even guess that the shop had implemented pretty good routines to handle such a situation. Routine or not, the cashier didn’t handle the situation well at all. The queue was standing in went to a complete halt.
First he tried to ask the lady, who of course didn’t know the price. Then he asked the cashier working the other register. Neither did he know the price. Now, beginning to get desperate he tried to reach someone using the in-house call system - to no avail. Then, as a last resort, he gave us waiting customers a spectacular introduction of both pecking order and a total lack of logistics ability. Once again he turned to the second cashier, but this time he instructed him to go and figure out the price. And the second queue went to a complete halt…
Now every person in the shop where waiting on one single guy.
I leave it as an exercise to reproduce this episode with code. A 4 core CPU, setup affinity to mask out 2 of them and then let every thread in the pool wait on the same lock…
- petter
