This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
There are many solutions to prevent deadlocks, among them: ....
Ignore the problem. Seriously- is it a requirement of your assignment? Is there a possibility that attempting to handle this problem could result in you making a mistake....
If there is a deadlock when the program is execute, I don't think I can use exception handling to handle this problem.
When deadlock happens, the program hangs forever. If that is the case, I can only improve the code, but I cannot use try catch block to throw exceptions and let the rest of the program execute.
When deadlock happens in a program, the program hangs and it won't continue. The users need to terminate the program themselves.
Is there any way to use try catch block to handle deadlock, so that the program can continue?
(The Monkhouse book says it is still possible to handle deadlock. In the book, it always says that we can ignore this problem in the exam.)
I don't see what's the added value of adding extra code which will never be used. It only has drawbacks: increased complexity, more code to maintain, more code = more chance for bugs,... So, a deadlock detection mechanism is not needed at all!
IMHO, once deadlock happens in your code, it doesn't matter what you do or how you handle it - a MUST requirement is already broken (and you know what happens in that case )
A highly recommended option is to avoid deadlock at all costs. There is a really nice explanation given in Monkhouse book about how to achieve no-deadlock situation. Surprisingly, preventing deadlock is quite easy and desirable than detecting deadlock and then handling it (not to mention that you'll have to make sure that your deadlock-handling code itself is deadlock free )
I would suggest to go through approaches suggested by Monkhouse.
Yes. I agree that deadlock avoidance is easier to handle than handling the code that hangs forever.
I remember Monkhouse suggests a very straightforward suggestion: make a thin client and let the server handle the business logic like retrieve and reserve DVD. If the client loses connection, it won't hold any locks. In the exam, I am thinking of building GUI on the client side application, make a facade to let the client to talk to the server remotely. Once multiple client requests are sent to the server, the server will hanle the request.
If I am using RMI, I don't think I need to create threads on the server to handle multiple client requests. To my knowledge so far, RMI itself will handle multiple client requests (multiple clients can talk to a single server and the RMI framework will handle the multiple threadings underneath the hood.)