Hi! Welcome!! Thanks for visiting my blog. Feel free to comment, criticize, suggest anything about the blogs. The options and views expressed here are my own and does not reflect my employer's (or my previous employers'). Thanks for visiting and hope that you enjoy your stay here!

Thursday, March 13, 2008

Deadlock - Technico Mokkaiyo Explanation.

[Disclaimer: Weak-hearted people are advised to take medical check-up before reading this. May turn out to be the most horrible experience of your lifetime.]

One advantage of Object Oriented Programming [if you were tempted to say "I don't understand Greek and Latin" please bypass this and the next paragraph] is that, you can compare the software objects with the real world objects (which sometimes screws us in understanding well). Though most of the programming concepts could not be just-like-that-compared with real world concepts, some of them could be. Let me not beat around the bush and let me jump into the matter of interest.

Deadlock, the name itself could make those who prepare for interviews (for the first shift) shiver. The most notorious topic in which Java professionals (and may be others also, but I can not promise) would be tested is *Threads* and the most sadistic questions will come revolving this deadlock. And this is how it mostly goes: "What is a dead lock?" "<our standard answer>" "How could you avoid it?" "<our standard answer" "Suppose, <and the hell starts here>". Or they can take a different approach and ask like: "Explain deadlock as you will explain to a layman" [for this question, many may be tempted to answer like, "why in the f**k should I explain a technical term to a bloody layman", but what we do is "<our standard answer>"]

Suppose, there are two children A and B each one has something which the other one wants. A says: "Give me your helicopter and I will give you this aeroplane". B says: "Never... only if you give me your aeroplane, I will give you my helicopter". What happens here is a deadlock in technical term. Two entities waiting and not proceeding because of a dependency on each other. This could also be a chain, A can only proceed if B gives her something and B can only proceed if C gives him something and C can only proceed if A gives her something.

Also, if there is a fight between two friends and if they both have ego, a good deadlock could happen. Both can think like, "I will only talk to him if he talks to me" and that is all. A complete technical explanation for this topic may come soon. So, stay tuned. Comments are most welcome. But wait. One small karutthu is hidden here. Deadlocks are the most unwanted things ever in a software and as we know, this could also apply to our life. So, avoid deadlocks! [as though everyone is going to hold a white flag in one hand and a white dove in another hand]

[P.S.: The notation "f**k" is not what you think. It was not added to mean anything bad. It is only for fun.][A.P.S.: The P.S. and the idea is copied from "Head First Servlets and JSPs from Kathy Sierra" and it is not my own idea. Over.]