Strange behavior in Java with unsyncronized access in a multithreading program

Question

I change a value that is used to determine when a while-loop terminates in a seperate thread.
I don't want to know how to get this working. If I access the variable test only through synchronized getters/setters it works as expected..

I would have expected, if some read/write commands are lost due to concurrency the program sometimes does not terminate, but it never does. Thats what confuses me..
I would like to know why the program never terminates, without the print-command. And I would like to understand why the print-command changes anything..

     

    public class CustomComboBoxDemo  {
        public static boolean test = true;
        public static void main(String[] args) {
            Thread user =new Thread(){
                @Override
                public void run(){
                    try {
                        sleep(2000);
                    } catch (InterruptedException e) {}
                    test=false;
                }
            };
            user.start();
            while(test) {
                System.out.println("foo"); //Without this line the program does not terminate..
            }
        }
    }

See: [Loop doesn't see changed value without a print statement](https://stackoverflow.com/questions/25425130/loop-doesnt-see-changed-value-without-a-print-statement) — Boann, Jan 16 '15 at 22:35

NPE · Accepted Answer · 2012-01-05T14:30:47.413

8

The most likely explanation is that the variable is only read once, turning the while into an infinite loop (or a no-op). Since you haven't declared test as volatile, the compiler is allowed to perform such an optimization.

Once you call an external function from within the loop, the compiler can no longer prove that test remains invariant across loop iterations, and doesn't perform the optimization.

edited Jan 05 '12 at 14:30

answered Jan 05 '12 at 14:25

NPE

486,780
108
951
1,012

1

I wonder, is it bytecode compiler or JIT compiler that does that kind of optimization? – bezmax Jan 05 '12 at 14:34
@Max: On my system the bytecode compiler doesn't do it, so it has to be the JIT compiler. – NPE Jan 05 '12 at 14:35
1

Btw, it could also be that it's constantly reading it, but doing so from a cache (like a CPU register) that isn't being affected to the write to main memory. Marking the field as `volatile` will fix this, too. – yshavit Jan 05 '12 at 14:41
Nice job stealing the answer btw ;-) – Jean Logeart Jan 05 '12 at 15:51
@Vakimshaar: Don't be ridiculous. – NPE Jan 05 '12 at 16:02

score 1 · Answer 2 · answered Jan 05 '12 at 14:25

If the test variable is not defined as volatile, the compiler probably optimizes the loop containing no operation into a while(true) loop for your main thread and the program never ends.

Otherwise, the value of the test variable is actually checked and when your second thread changes its value, then the main thread leaves the while loop and your program terminates.

score 0 · Answer 3 · answered Jan 05 '12 at 14:22

I presume it's something to do with the way IO is handled. Without the print, you'll probably see the java application using all available CPU time; with the print it's likely that IO delays give up enough CPU time for other processing to take place.

A quick way to test this theory would be to put printlns in the run() method of your thread to see whether the thread is actually ever executing. In my experience, infinite empty loops cause a lot of strange behaviour.

That said, it appears to terminate fine on my workstation under JDK 1.6.0_10_b23

Agree with mcfinnigan. Add some debugging prints to your thread. When something doesn't work as expected, always do some work to prove that your assumptions are correct, in this case that the separate thread is working as designed. — Mitch, Jan 05 '12 at 14:27

score 0 · Answer 4 · answered Jan 05 '12 at 14:30

0

Seems like your loop is being incorrectly compiled away into a busy-wait. Adding a volatile keyword to your boolean corrects the 'problem'.

answered Jan 05 '12 at 14:30

Perception

79,279
19
185
195

score 0 · Answer 5 · edited May 23 '17 at 12:03

public static boolean test = true;
public static void main(String[] args) {
    Thread user =new Thread(){
        @Override
        public void run(){
            try {
                sleep(2000);
            } catch (InterruptedException e) {}
            test=false;
            System.out.println("Thread.end <"+test+">");
        }
    };
    user.start();
    while(test);
}

That's interesting. The compiler most probably optimzes this while into an endless loop, not reading the value at each loop.

Defining test as volatile fixes this and let your program terminate

Btw: you probably already know that you shoud use user.join() to wait for the Thread to end

score 0 · Answer 6 · answered Jan 05 '12 at 14:44

I don't understand what you are trying to do by using code you know is not correctly synchronized.

As some have reported, on their machine the code behaves differently than on your machine. The behavior of badly synchronized code is undefined. It makes no sense to try to understand what it does since that behavior will change with the JVM version or architecture.

Strange behavior in Java with unsyncronized access in a multithreading program

6 Answers6