How can this code cause deadlock?

Question

While passing SCJP6 exam simulator I found question like this:

class Clerk implements Runnable {

    private Record A, B;

    public Clerk(Record a, Record b) {
        A = a;
        B = b;
    }

    public void run() {
        while(true) {
            doStuff(A, B);
        }
    }

    public synchronized void doStuff(Record a, Record b) {
        synchronized(a) {
        synchronized(b) {
            a.add(1);
            b.add(-1);
        }}
    }

}

then

Record a = new Record();
Record b = new Record();

new Thread(new Clerk(a, b)).start();
new Thread(new Clerk(a, b)).start();

Answer says that this code can cause deadlock, but I don't get it - how exactly is that possible? Can someone can help me figure that out?

It's not possible. The fields are called `A` and `B`, but `run()` uses `a` and `b`, so the code won't even compile. :) — Ry-, Dec 11 '12 at 15:23
Looks to me like that code won't deadlock, but when you switch a and b in the second constructor call it could (and most likely will) (assuming you fix the issue noticed by @minitech) — Mark Rotteveel, Dec 11 '12 at 15:24
Sorry, I've not copied question correctly :) Now it is compiles — Dmitry Zaytsev, Dec 11 '12 at 15:28

assylias · Accepted Answer · 2012-12-11T15:50:31.347

9

Apart from the fact that it does not compile, there is no deadlock in that code. This code could definitely create a deadlock:

new Thread(new Clerk(a, b)).start();
new Thread(new Clerk(b, a)).start();

So if the question is: could the Clerk class be the source of the deadlock? Then the answer is yes.

EDIT

Short example that should deadlock fairly fast. If a and b are used like in the original question, the program runs fine.

public class Test1 {

    public static void main(String[] args) {
        Record a = new Record();
        Record b = new Record();

        new Thread(new Clerk(a, b)).start();
        new Thread(new Clerk(b, a)).start();
    }

    static class Record {
    }

    static class Clerk implements Runnable {

        private Record A, B;

        public Clerk(Record a, Record b) {
            A = a;
            B = b;
        }

        public void run() {
            while (true) {
                System.out.println("in thread " + Thread.currentThread());
                for (int i = 0; i < 10000; i++) {
                    doStuff(A, B);
                }
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException ex) {
                }
            }
        }

        public synchronized void doStuff(Record a, Record b) {
            synchronized (a) {
                synchronized (b) {
                }
            }
        }
    }
}

edited Dec 11 '12 at 15:50

answered Dec 11 '12 at 15:23

assylias

321,522
82
660
783

2

+1 I suspect the question has been copied incorrectly somewhere. – Peter Lawrey Dec 11 '12 at 15:24
Why does reversing the argument cause a deadlock? – Lews Therin Dec 11 '12 at 15:26
2

@LewsTherin: One could lock `a`, then before it could lock on `b`, the other already has but is waiting for `a`. – Ry- Dec 11 '12 at 15:27
@PeterLawrey indeed :) I've edited the question and it is compiles now. – Dmitry Zaytsev Dec 11 '12 at 15:29
1

...and then it is just the Dining Philosophers problem, isn't it? – Marko Topolnik Dec 11 '12 at 15:29
@LewsTherin The order you lock objects matters. If you always lock `a` then `b` you will never get a dead lock. If you have one thread lock `a` while another locks `b` first, both threads will wait for the other to release the lock, which they won't do. – Peter Lawrey Dec 11 '12 at 15:32
@PeterLawrey Thinking about it.. if thread 1 locks `a` , how does thread 2 lock `b`? Wouldn't thread 2 have to wait for thread 1 to release `a`? – Lews Therin Dec 11 '12 at 15:37
1

@LewsTherin Not if it locks the `Record b = new Record();` first because in the second thread `a` and `b` have swapped names. – Peter Lawrey Dec 11 '12 at 15:42

Brian Agnew · Answer 2 · 2012-12-11T15:33:04.750

3

I would expect this to deadlock if one thread was constructed with a/b, and the second with b/a.

In this situation a thread would put a lock on the first entity and the then on the second. If thread 1 locked a and tried to lock b, and thread simultaneously 2 locked b and waited for a, then it would all grind to a halt.

Here's the Java tutorial deadlock example, which is very similar to the above example.

edited Dec 11 '12 at 15:33

answered Dec 11 '12 at 15:26

Brian Agnew

268,207
37
334
440

How can this code cause deadlock?

2 Answers2