why this simple java application goes into dead lock?

[jokop]

why this simple java application do infinete while loop?
thanks very much
niv jokop

class DualSync {


public boolean busy=true;

  public synchronized void store() {
	  System.out.println("before");  
	  while (busy) ;		  
	  System.out.println("after");
  }

  public synchronized void read() {
	  
  }
}

  public class SyncObj{

  public static void main(String[] args) throws InterruptedException {
    final DualSync ds = new DualSync();
    new Thread() {
    	public void run() {
            	ds.store();
      }
    }.start();
    Thread.sleep(5000);
    ds.busy=false;
    ds.read();
    System.out.println("end main");
  }
 
  
} ///:~

[KevinWorkman]

What do you mean? This program reaches the end of main for me just fine. Are you sure you're waiting 5 whole seconds before deciding that it has locked up?

[jokop]

thanks for the reply
yes I'm pretty sure it shows only the word "before" and then halts. (it dont terminate)
maybe its related to the fact that Im using Ubuntu OS and java-6-openjdk (what ever that means,
as I have regular updates that I agree to install whenever Im requested to do so.)

[KevinWorkman]

I find it hard to accept that your OS or JDK would behave so differently. Are you certain you're waiting the full 5 seconds? Are you sure this is the code you're running?

[jokop]

here is a screenshot of my eclipse
notice the red square that signals the application is still running.
notice also that the console output is only "before"
thanks for your interest
niv jokop

[doWhile]

It deadlocks for me as well. IMO this is a very poor way to write code, a better design would be to utilize the wait()/notify() methods. As to why, the fact that it works for KevinWorkman has me a bit stumped but I can guess is its an OS issue - see volatile below (possible local caching involved?), but logically the synchronized store() method continually acquires a lock on the object, thus the main thread can never access the busy variable. I mentioned this is poor code, but an interesting example as to thread deadlocking. Remove the synchronized on store, and it still locks (in a different place). Use a synchronized statement to lock ds prior to setting the flag to true and it still locks. Do the above and mark the boolean as volatile and it works. I will let the original poster look up what volatile means...

[KevinWorkman]

Weird. It definitely exits for me. I'm using Windows XP and Java 1.6.0_22. It exits successfully both in eclipse and from the command line.

[KevinWorkman]

Also- this doesn't really explain why it works for me and not you, but what happens when you make your busy variable volatile?

[JosAH]

Make your variable 'busy' volatile.

kind regards,

Jos

edit: *sigh* not again, too slow again ... ;-)

[jokop]

doWhile
why it cant access the locked objects variables. as I understand only synchonized methods of the locked object cannot be invoked by the main thread (while the object is locked with the "inner" thread).
regards
niv jokop

[doWhile]

doWhile
why it cant access the locked objects variables.

See Typical use of the volatile keyword
and
Intrinsic Locks and Synchronization (The Java™ Tutorials > Essential Classes > Concurrency)

In this case its not about locking per se, its about local caching of a variable.

[toadaly]

KevinWorkman's and JosAH's advice will probably "fix" your problem, but this is a horrible design. You are probably eating an entire CPU doing nothing but checking the status of 'busy'. The right approach would be to get rid of the 'busy' variable altogether, and use a 'wait' instead. In place of setting 'busy' to false, use a notify.

class DualSync {

  private boolean busy = true;
  private boolean hasStore = false;

  public synchronized void store() {
    System.out.println("before");  

    hasStore = true;
    notify();

    while(busy) {
      try {
        wait();
      } catch (InterruptedException iex) {}
    }

    System.out.println("after");
  }

  public synchronized void read() {
    while(!hasStore) {
      try {
        wait();
      } catch (InterruptedException iex) {}
    }

    busy = false;
    notify();
  }
}

public class SyncObj{

  public static void main(String[] args) throws InterruptedException {
    final DualSync ds = new DualSync();

    new Thread() {
    	public void run() {
           ds.store();
      }
    }.start();

    ds.read();

    System.out.println("end main");
  }
 
  
} ///:~

(haven't tested it, but should work ;p )

[JosAH]

KevinWorkman's and JosAH's advice will probably "fix" your problem, but this is a horrible design. You are probably eating an entire CPU doing nothing but checking the status of 'busy'. The right approach would be to get rid of the 'busy' variable altogether, and use a 'wait' instead. In place of setting 'busy' to false, use a notify.

True, a busy loop burns your cpu but there are even nicer solutions than wait() and notify(); there's a bunch of great classes in the java.util.concurrent package that can handle most (if not all) of those multi threaded problems and they take away the wait, synchronize, notify scheduling from the use of those classes. Those classes have been written by Doug Lea and were already with us as a separate package years ago. It's a mature technology and should be used imho.

kind regards,

Jos