Thread Deadlock

[ajeeb]

Hi,
The following is a code which generally results in a thread deadlock.

public class Test2 {

public static void main(String[] args) {
OwnThread ot = new OwnThread();
Thread t1 = new Thread(ot);
Thread t2 = new Thread(ot);
t1.start();
t2.start();
}
}

class OwnThread extends Thread {
A a = new A();

B b = new B();

public void run() {
synchronized (a) {
System.out.println(Thread.currentThread().getName( ) + " A");
synchronized (b) {
System.out.println(Thread.currentThread().getName( ) + " B");
}
}



synchronized (b) {
System.out.println(Thread.currentThread().getName( ) + " B");
synchronized (a) {
System.out.println(Thread.currentThread().getName( ) + " A");
}
}
}
}

When there is no deadlock (which is very rare), i will get 8 lines printed - something like:
Thread-1 A
Thread-1 B
Thread-2 A
Thread-2 B
Thread-2 B
Thread-2 A
Thread-1 B
Thread-1 A

On thread deadlocks, i get 4 lines printed - something like:
Thread-1 A
Thread-1 B
Thread-2 A
Thread-1 B
The output is definitely uncertain.

Now, I need to break this deadlock by using wait() and notify(), where do i put these methods so that deadlock never happens ?

[hardwired]

class OwnThread extends Thread {
    A a = new A();
    B b = new B();

    public void run() {
        synchronized (a) {
            System.out.println(getId(" A"));

            synchronized (b) {
                b.notify();
                System.out.println(getId(" B in A"));
            }
        }

        synchronized (b) {
            System.out.println(getId(" B"));
            try {
                b.wait();
            } catch(InterruptedException e) {
                System.out.println(getId(" interrupt in B"));
            }

            synchronized (a) {
                System.out.println(getId(" A in B"));
            }
            b.notify();
        }
    }

    private String getId(String s) {
        return Thread.currentThread().getName( ) + s;
    }
}

[neilcoffey]

I think using wait/notify would be an odd solution to this problem, and one liable to have subtle bugs unless you're really careful. (For example, in the example above, one bug is that both threads could run notify() before either starts to wait(), and then the two threads will just sit waiting forever for a notify() that never comes.)

Some typical solutions are:
(a) in cases where you really need to hold two synchronized locks, make sure there is a determined order every time (e.g. use the numerical order of System.identityHashCode() of the objects in question);
(b) use Java 5 Lock classes, or one of the other classes from the Java concurrency framework, which allow you to wait with a timeout, or which allow you to "tentatively" acquire a lock/perform an action on a concurrent structure, and take appropriate action in case of failure. (E.g. don't synchronize forever waiting for things like logging queues: if you don't manage to post an item to the queue in 500ms, then "Something Has Gone Wrong" and there's not point blocking forever.)

If you must use wait/notify, I would recommend encapsulating the construct in your own lock class. (See my example of a pre-Java 5 lock implementation with wait/notify based on this idea.) But I really only recommend this if, say, you're running in a version pre Java 5.