Почему этот код выкидывает RuntimeException, не смотря на volatile?

Question

[Анатолий]

Изучаю многопоточность в Java. Насколько я понял, в JMM есть гарантия, что после записи в volitile, все операции до обязаны выполниться. Т.е. если при чтении в другом потоке y равен 2, то x обязан быть 1. Но так не происходит. ЧЯДНТ?

public class Reordering {
    int x = 0;
    volatile int y = 0;

    public void writer() {
        x = 1;
        y = 2;
    }

    public void reader() {

        if (y == 2) {
            if(x == 0) {
                throw new RuntimeException();
            }

            this.x = 0;
            this.y = 0;
        }
    }

    public static void main(String[] args) {
        final Reordering reordering = new Reordering();

        final Thread thread = new Thread(() -> {
            while (true) {
                reordering.writer();
            }
        });

        thread.setDaemon(true);
        thread.start();

        while (true) {
            reordering.reader();
        }
    }
}

Answer 1

[Сергей Горностаев]

Гарантия happens-before не исключает гонок

reader     writer  состояние
---------- ------ ------------
перед x=0          x=1, y=2
             x=1   x=1, y=2
x=0                x=0, y=2
y=0                x=0, y=0
             y=2   x=0, y=2

При следующем вызове reader он получит состояние в котором x равно 0, когда y равно 2.

Answer 2

[Денис Загаевский]

volatile ничего не говорит ни про что кроме переменной, на которой он поставлен. Говорит, что это переменная не будет закеширована в тренде. Ты всегда будешь видеть её актуальное значение. У тебя реализована банальная гонка потоков. х может браться из локального кеша (thread local) - спорно и в данном случае неважно.

Распишу подробнее гонку. Код может выполняться в такой последовательности

x = 1; //thread 1
x = 0; //thread 2
y = 0; //thread 2
y = 2; //thread 1
if (y == 2) {  //thread 1, TRUE
    if (x == 0) { //thread 1, TRUE
        throw //thread 1, привет
    }
}

То есть это всё о чём - одно нахождение переменной и её присвоений рядом с volatile переменной ничего не гарантирует. Никакой синхронизации нет. Отличие от кода, который есть в статье, которую ты привел в том, что там меняет данные лишь один поток, поэтому гонки не возникает.
Кроме того, знание таких мелочей скорее вредно, потому что может возникнуть желание использовать это в реальном коде, что ведёт к опасному коду, малейшее изменение которого(или, не дай бог, JMM) ведет к труднуловимым ошибкам.

Comments

[Анатолий]

Нет, говорит. В частности из https://habr.com/company/golovachcourses/blog/221133/

Разница в том, что теперь уже не так легко изменить порядок между обычными полями расположенными рядом volatile. Запись в volatile поле имеет тот же эффект для памяти как и освобождение монитора (monitor release), а чтение из volatile поля имеет тот же эффект для памяти как и захват монитора (monitor acquire). В сущности, так как новая модель накладывает более строгие ограничения на изменение порядка между доступом к volatile полям и другими полями (volatile или обычным), все, что было видимо для потока A когда он писал в volatile поле f становится видимым для потока B, когда он прочтет f.

[Денис Загаевский]

Анатолий, если следовать такой логике, появление одно volatile переменной убивает весь локальный кеш. Это не так.

[Евгений]

ЕМНИП, volatile лишь гарантирует, что операции чтения/записи отмеченной переменной будут атомарны, и значения таких переменных будут видны всем потокам в одинаковом состоянии. Про состояние "гонки" все верно написано.

[Анатолий]

Денис Загаевский, теперь понятно, спасибо.

[Сергей Горностаев]

Денис Загаевский, и тем не менее это поведение зафиксированное в JMM, поэтому абсолютно все JVM будут именно так себя вести. Вот что по этому поводу пишет Брюс Эккель в "On Java 8":

public class ReOrdering implements Runnable {
    int one, two, three, four, five, six;
    volatile int volaTile;

    @Override
    public void run() {
        one = 1;
        two = 2;
        three = 3;
        volaTile = 92;
        int x = four;
        int y = five;
        int z = six;
    }
}

The assignments of one, two and three may be reordered, as long as they all happen before the volatile write. Similarly, the x, y, and z statements may be reordered as the volatile write happens before all of them. The volatile operation is often called a memory barrier. The happens before guarantee ensures that read and write instructions of volatile variables cannot be reordered across a memory barrier.

The happens before guarantee has another effect: When a thread writes to a volatile variable, then all other variables - including non-volatiles - changed by the thread before writing to the volatile variable are also flushed to main memory. When a thread reads a volatile variable it also reads all other variables - including non-volatile - that were flushed to main memory together with the volatile variable.

Но это не так уж и критично. Во-первых, JVM (или JIT-компилятор) при операциях с с волатильными переменными использует lock-префиксные инструкции процессора, которые обеспечивают happens-before, но существенно быстрее полноценного барьера устанавливаемого инструкцией mfence например. Во-вторых, современные контроллеры памяти способны обеспечить когерентность кэшей без сброса store/load-буферов в память.