Is it possible for a thread to Deadlock itself?
Is it technically possible for a thread in Java to deadlock itself?
I was asked this at an interview a while back and responded that it wasn't possible but the interviewer told me that it is. Unfortunately I wasn't able to get his method on how to achieve this deadlock.
This got me thinking and the only situation that I can think of is where you can have this happen is where you have an RMI server process which contained a method that calls itself. The line of code that calls the method is placed in a synchronized block.
Is that even possible or was the interviewer incorrect?
The source code I was thinking about was along these lines (where testDeadlock is running in an RMI server process)
public boolean testDeadlock () throws RemoteException {
synchronized (this) {
//Call testDeadlock via RMI loopback
}
}
Solution 1:
Well, based on the definition of:
A deadlock is a situation wherein two or more competing actions are each waiting for the other to finish.
I would say that the answer is no - sure a thread can sit there waiting indefinitely for something, however unless two competing actions are waiting for each other it is by definition not a deadlock.
Unless someone explains to me how a single thread can be simultaneously waiting for two actions to finish?
UPDATE: The only possible situation that I can think of is some sort of message pump, where a thread processes a message that asks it to wait indefinitely for something to happen, where in fact that something will be processed by another message on the message pump.
This (incredibly contrived) scenario could possibly be technically called a deadlock.
Solution 2:
It depends on what you mean by "deadlock" exactly. For example, you could easily wait()
on a monitor which nothing would ever pulse... but I don't think I'd call that deadlock, as such.
Thinking along your "method that calls itself" lines, if your server only ran a certain number of threads, they could all be busy waiting from responses from the same server, if that counts. (Simplest example: the server only uses one thread for processing. If you write a request handler which calls into the same server, it will be waiting for the blocked thread to finish handling the request before it can serve the same request...) This isn't really a "synchronized block" sort of deadlock, but it's certainly a danger to be aware of.
EDIT: To apply this answer to the definition in the others, the competing actions here would be "complete the current request" and "handle the new request". Each action is waiting for the other to occur.
Solution 3:
Maybe he meant LOCK itself, that's certainly too easy:
synchronized( this )
{
wait( );
}
Solution 4:
Maybe what the interviewer was thinking of was:
Thread.currentThread().join();
However I would argue that it does not count as a deadlock.