views:

335

answers:

6

I'm learning about deadlocks in Java, and there's this sample code from Sun's official tutorial:

Alphonse and Gaston are friends, and great believers in courtesy. A strict rule of courtesy is that when you bow to a friend, you must remain bowed until your friend has a chance to return the bow. Unfortunately, this rule does not account for the possibility that two friends might bow to each other at the same time.

public class Deadlock {
    static class Friend {
        private final String name;
        public Friend(String name) {
            this.name = name;
        }
        public String getName() {
            return this.name;
        }
        public synchronized void bow(Friend bower) {
            System.out.format("%s: %s has bowed to me!%n", 
                    this.name, bower.getName());
            bower.bowBack(this);
        }
        public synchronized void bowBack(Friend bower) {
            System.out.format("%s: %s has bowed back to me!%n",
                    this.name, bower.getName());
        }
    }

    public static void main(String[] args) {
        final Friend alphonse = new Friend("Alphonse");
        final Friend gaston = new Friend("Gaston");
        new Thread(new Runnable() {
            public void run() { alphonse.bow(gaston); }
        }).start();
        new Thread(new Runnable() {
            public void run() { gaston.bow(alphonse); }
        }).start();
    }
}

Here's Sun's explanation:

When Deadlock runs, it's extremely likely that both threads will block when they attempt to invoke bowBack. Neither block will ever end, because each thread is waiting for the other to exit bow.

I don't quite seem to follow. When alphonse.bow(gaston) runs, the bow method is locked. So now it'll first print "Gaston has bowed to me!". Then it'll go on and call bowBack, and locks bowBack as well. How can this cause a deadlock? Am I misunderstanding what happens when a synchronized method is called?

If someone can give me a easy explanation, thanks.

A: 

I'd have to double check, but I think a synchronized method locks on the class object, so it locks out other synchronized methods in the same class.

I think it locks on the class object itself, so it even blocks different instances.

Edit to add:

Take a look at this part of the java language spec

Each bow method grabs it's own objects monitor. Both then try to call the other object's bow back, and block waiting for the other monitor.

developmentalinsanity
Nope, synchronized in a non-static method signature will only lock the current instance, not the class object.
Outlaw Programmer
Found the appropriate part of the spec. You're right.
developmentalinsanity
Incidentally, locking the class object would actually prevent the deadlock in this case!
Outlaw Programmer
+6  A: 

alphonse and gaston are two different objects. Each object has an intrinsic monitor (lock) that is associated with it.

It could happen like this:

alphonse is created. His object monitor is 1.

gaston is created. His object monitor is 2.

alphonse.bow(gaston); alphonse now owns lock #1

gaston.bow(alphonse); gaston now owns lock #2

alphonse calls bowBack on gaston and is waiting for lock #2 gaston calls bowBack on alphonse and is waiting for lock #1

Make sense? Using the synchronized keyword locks that instances monitor for the duration of the method. The example could be rewritten as follows:

public class Deadlock {
    static class Friend {
        private final String name;
        public Friend(String name) {
            this.name = name;
        }
        public String getName() {
            return this.name;
        }
        public void bow(Friend bower) {
            synchronized(this) {            
                        System.out.format("%s: %s has bowed to me!%n", 
                    this.name, bower.getName());
                        bower.bowBack(this);
            }
        }
        public void bowBack(Friend bower) {
            synchronized(this) {
                        System.out.format("%s: %s has bowed back to me!%n",
                    this.name, bower.getName());
            }
        }
    }
}
Kevin
When alphonse calls bowBack, it passes its own instance (bowBack(this)). Why would bowBack require gaston's lock?
Saobi
It doesn't, its just for logging purposes. It could have easily passed friend.getName() instead of the entire Friend object.
Kevin
+1  A: 

Locks are held on Java objects, not java methods. So when synchronized is used on a method, it locks the "this" object. In the case of a static method, it locks the class object.

You can explicitly specify the monitor object by using synchronized ( object ) { }

Jim Ferrans
+12  A: 

One important point to note is that it is not methods which are locked but object instances.

When you call alphonse.bow(gaston), it tries to acquire the lock on alphonse. Once it has the lock, it prints a message, then calls gaston.bowBack(alphonse). At this point, it tries to acquire the lock on gaston. Once it has the lock, it prints a message, then releases the lock, and finally the lock on alphonse is released.

In deadlock, the locks are acquired in such an order that there's no way for either thread to proceed.

  • Thread 1: acquires lock on alphonse
  • Thread 2: acquires lock on gaston
  • Thread 1: prints message
  • Thread 1: tries to acquire lock on gaston - can't, because Thread 2 already has it.
  • Thread 2: prints message
  • Thread 2: tries to acquire lock on alphonse - can't, because Thread 1 already has it.
Simon Nickerson
Ah. Ok, I think I get it. So when you add synchronized keyword in front of a method, it means that when a thread calls this method, the entire object "locks", which means no other thread can call any other method on this object, even if those OTHER methods simply print "hello" ?
Saobi
Not quite. No thread can call any other synchronized method on this object, and no thread can enter a synchronized { } block which synchronized on this object instance.
Simon Nickerson
e.g. other threads can call alphonse.toString() or alphonse.getName() even if a different thread owns the lock on alphonse.
Simon Nickerson
And printing the messages serves to delay the threads so that deadlock becomes more likely.
starblue
A: 

synchronized in a method definition is a shorthand for synchronizing on the object (this) itself. In essence this means that bow() and bowBack() cannot be invoked on the same Friend object mutually.

Now if both Friends get into bow(), neither of them will be able to invoke each other's bowBack() method.

Zed
A: 

To add to simonn, et al.,

If you would like to visualize this, compile and run the program and generate a thread dump of the running program. You can do this by typing a Ctrl-Break to a Windows console or issueing a kill -QUIT [pid] command to a *nix system. What this will provide you is a list of all of the Threads running in your system and where they are either running or waiting, as well as the monitors the threads are either locking on or waiting to lock on.

If you change your Thread names in their constructors, you will have an easier time finding them in the full thread dump:

   new Thread(new Runnable() {
        public void run() { alphonse.bow(gaston); }
    }, "Alphonse").start();
    new Thread(new Runnable() {
        public void run() { gaston.bow(alphonse); }
    }, "Gaston").start();
akf