Java memory model synchronization: how to induce data visibility bug?

Question

"Java Concurrency in Practice" gives the following example of an unsafe class which due the nature of the java memory model may end up running forever or print 0.

The issue this class is trying to demonstrate is that the variables here are not "shared" between threads. So the value on thread sees can be different from another thread as they are not volatile or synchronized. Also due to the reordering of statements allowed by the JVM ready=true maybe set before number=42.

For me this class always works fine using JVM 1.6. Any idea on how to get this class to perform the incorrect behavior (i.e. print 0 or run forever)?

public class NoVisibility {
    private static boolean ready;
    private static int number;

    private static class ReaderThread extends Thread {
        public void run() {
            while (!ready)
                Thread.yield();
            System.out.println(number);
        }
    }

    public static void main(String[] args) {
        new ReaderThread().start();
        number = 42;
        ready = true;
    }
}

Lyndseylyndsie

Short answer no. But do you really need to check whether jumping from the roof is dangerous after someone told you and gave good reasons? – Inelegance

@Voo...what on earth are you talking about? – Lyndseylyndsie

@JBNizet....does anyone use a computer without multiple cores these days?? – Lyndseylyndsie

I like this question, and finding out why your program behaves like it does would be interesting. – Hymeneal

@JBNizet - No, at least not for the runs-forever case. That one is only possible on a single-core machine (if the ReaderThread becomes active before the assignments are made, and then the scheduler ignores the yield() calls). On a multi-core machine there is no way for ReaderThread to permanently block execution of the main thread, and thus the runs-forever error will never occur. – Lendlease

@aroth: the problem is not thread starvation. It's visibility of the ready value. If you have two cores, both may cache their value of ready, and the main thread will set it to true but the reader thread won't see it due to the absence of volatile. A scheduler will always let the chance to a thread to execute its instructions. – Marcie

@DD you can set affinity to 1 core (this can speed up some applications that are memory bound) – Wirework

Answer 1

The problem you have is that you are not waiting long enough for the code to be optimised and the value to be cached.

When a thread on an x86_64 system reads a value for the first time, it gets a thread safe copy. Its only later changes it can fail to see. This may not be the case on other CPUs.

If you try this you can see that each thread is stuck with its local value.

public class RequiresVolatileMain {
    static volatile boolean value;

    public static void main(String... args) {
        new Thread(new MyRunnable(true), "Sets true").start();
        new Thread(new MyRunnable(false), "Sets false").start();
    }

    private static class MyRunnable implements Runnable {
        private final boolean target;

        private MyRunnable(boolean target) {
            this.target = target;
        }

        @Override
        public void run() {
            int count = 0;
            boolean logged = false;
            while (true) {
                if (value != target) {
                    value = target;
                    count = 0;
                    if (!logged)
                        System.out.println(Thread.currentThread().getName() + ": reset value=" + value);
                } else if (++count % 1000000000 == 0) {
                    System.out.println(Thread.currentThread().getName() + ": value=" + value + " target=" + target);
                    logged = true;
                }
            }
        }
    }
}

prints the following showing its fliping the value, but gets stuck.

Sets true: reset value=true
Sets false: reset value=false
...
Sets true: reset value=true
Sets false: reset value=false
Sets true: value=false target=true
Sets false: value=true target=false
....
Sets true: value=false target=true
Sets false: value=true target=false

If I add -XX:+PrintCompilation this switch happens about the time you see

1705    1 % RequiresVolatileMain$MyRunnable::run @ -2 (129 bytes)   made not entrant
1705    2 % RequiresVolatileMain$MyRunnable::run @ 4 (129 bytes)

Which suggests the code has been compiled to native is a way which is not thread safe.

if you make the value volatile you see it flipping the value endlessly (or until I got bored)

EDIT: What this test does is; when it detect the value is not that threads target value, it set the value. ie. thread 0 sets to true and thread 1 sets to false When the two threads are sharing the field properly they see each others changes and the value constantly flips between true and false.

Without volatile this fails and each thread only sees its own value, so they both both changing the value and thread 0 see true and thread 1 sees false for the same field.

Revue

Could you provide an example with a loop which will demonstrate the problem? – Lyndseylyndsie

I have added an explanation. Let me know if you have more doubts/questions. – Revue

I dont see how the prints demonstrate this. How do you know that the threads are seeing different values when you are printing a snapshot every 100000000 iterations? Also why would the value constantly flip.....If thread 1 runs the loop several times without thread 2 running the value will not flip. That seems quite dependent on the scheduling. – Lyndseylyndsie

It has to run a billion times without flipping the value. You can't have both threads consistently looping and checking a billion times when neither thinks it need to flip the value (even if your box is seriously loaded) unless each thread is acting as if the value is different. – Revue

Answer 2

The java memory model defines what is required to work and what isn't. the "beauty" of unsafe multi-threaded code is that in most situations (especially in contolled dev environments) it usually works. it's only when you get to production with a better computer and load increases and the JIT really kicks in that the bugs start to bite.

Prepotency

Answer 3

Not 100% sure on this, but this might be related:

What is meant by reordering?

There are a number of cases in which accesses to program variables (object instance fields, class static fields, and array elements) may appear to execute in a different order than was specified by the program. The compiler is free to take liberties with the ordering of instructions in the name of optimization. Processors may execute instructions out of order under certain circumstances. Data may be moved between registers, processor caches, and main memory in different order than specified by the program.

For example, if a thread writes to field a and then to field b, and the value of b does not depend on the value of a, then the compiler is free to reorder these operations, and the cache is free to flush b to main memory before a. There are a number of potential sources of reordering, such as the compiler, the JIT, and the cache.

The compiler, runtime, and hardware are supposed to conspire to create the illusion of as-if-serial semantics, which means that in a single-threaded program, the program should not be able to observe the effects of reorderings. However, reorderings can come into play in incorrectly synchronized multithreaded programs, where one thread is able to observe the effects of other threads, and may be able to detect that variable accesses become visible to other threads in a different order than executed or specified in the program.

Peculiarize

+1 The printout of 0 is due to reordering. From the book itself: "NoVisibility could print zero because the write to ready might be made visible to the reader thread before the write to number,a phenomenon known as reordering" – Nika

Answer 4

I think the main point about this is that it is not guaranteed that all jvms will reorder the instructions in the same way. It is used as an example that different possible reorderings exist, and therefore for some implementations of the jvm you might get different results. It just so happens that you jvm is reordering in the same way every time, but that might not be the case for another. The only way to guarantee ordering is to use proper synchronisation.

Stain

Answer 5

Depending on your OS, Thread.yield() might or might not work. Thread.yield() cannot really be considered platform independent, and shouldn't be used if you need that assumption.

Making the example do what you expect it to do, I think that's more a matter of processor architecture than anything else... try running it on different machines, with different OS's, see what you can get out of it.

Ddt

This has little to do with thread.yield...its about the shared memory model in java. – Lyndseylyndsie

Answer 6

Please see the below code, It introduces the data visibility bug on x86. Tried with jdk8 and jdk7

package com.snippets;


public class SharedVariable {

    private static int  sharedVariable = 0;// declare as volatile to make it work
    public static void main(String[] args) throws InterruptedException {

        new Thread(new Runnable() {

            @Override
            public void run() {
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                sharedVariable = 1;
            }
        }).start();

        for(int i=0;i<1000;i++) {
            for(;;) {
                if(sharedVariable == 1) {
                    break;
                }
            }
        }
        System.out.println("Value of SharedVariable : " + sharedVariable);
    }

}

Trick is not to expect the processor to do the reordering rather make compiler to make some optimization which introduces the visibility bug.

If you run the above code you will see it hangs indefinitely because it never sees the updated value sharedVariable.

To correct the code declare the sharedVariable as volatile.

Why normal variable didn't work and the above program hangs ?

1. sharedVariable was not declared as volatile.
2. Now because sharedVariable was not declared as volatile compiler optimizes the code. It sees that sharedVariable is not going be changed so why i should read from memory every time in the loop. It will take the sharedVariable out of the loop. Something similar to below.

f

for(int i=0;i<1000;i++)/**compiler reorders sharedVariable
as it is not declared as volatile
and takes out the if condition out of the loop
which is valid as compiler figures out that it not gonna  
change sharedVariable is not going change **/
    if(sharedVariable != 1) {  
     for(;;) {}  
    }      
}

Shared at github : https://github.com/lazysun/concurrency/blob/master/Concurrency/src/com/snippets/SharedVariable.java

Therese