Глубокое погружение в Java Memory Model

Так. Тут происходит что-то очень интересное, но не совсем очевидное.

1) Я так понимаю, что в некоторых случаях в ссылку Foo.mock оказывается записан валидный объект ДО того, как констуктор этого Foo.mock отработает. Ноооо... в каком треде происходит выполнение инструкции static final Foo mock = new Foo();и почему?

2) У вас в строке 90 приписан комментарий return instance; // can return null Это сбивает с толку - действительно ли в этой строке может вернуться null? Это же нарушает reordering в пределах одного потока. И в ваших тестах нет ни одного подобного случая.

Не 0, а 1. И далее во всем абзаце.

Нет, я говорю именно про ситуацию, когда читаем 0. Давайте посмотрим еще раз на пример:

    private int x;
    private int y;

    public void T1() {
        x = 1; // W1
        int r1 = y; // R1
    }

    public void T2() {
        y = 1; // W2
        int r2 = x; // R2
    }

Если мы прочитали на R1 любое значение (хоть 0, хоть 1, но нас интересует именно 0), то запись W1 точно произошла, а значит на чтении R2 мы должны будем увидеть 1. Аналогично рассуждаем и о втором треде. Таким образом, мы можем увидеть 0 только на одном из чтений, но никак не на обоих, так как это просто невозможно если смотреть с точки зрения порядка в программе, ведь хотя бы одна запись должна была произойти.
Другими словами, выполнение программы начинается или с записи x, или с записи y. Если мы прочитали (0, 0), то это означало бы, что выполнение программы началось с чтений, но ведь они идут после записей? Однако это происходит по причине memory reordering, так как Java не дает sequential consistency по умолчанию.

Не LoadStore, а StoreLoad.

Нет, это называется именно LoadStore (читать так: loads can be reordered after stores).

Не StoreLoad, а LoadStore.

И здесь тоже именно StoreLoad (читать так: stores can be reordered after loads). Кстати, причина наличия такого переупорядочивания в x86 - это Store Buffer.

Проанализируем программу: если в первом треде мы видим 0 при чтении y, то запись в x точно произошла

Не 0, а 1. И далее во всем абзаце.

Код в статье правильный: вот этот же пример в JCStress.

Возможно, из описания не совсем понятно, что этот код делает.

Можно попробовать объяснить вот так:

Код:

public class MemoryReorderingExample {
    private int x;
    private int y;

    public void T1() {
        x = 1;
        int r1 = y;
    }

    public void T2() {
        y = 1;
        int r2 = x;
    }
}

Тут T1() выполняется в первом потоке, T2() - во втором.

Обычно люди, незнакомые с JMM, полагают, что в таком случае действия в каждом потоке выполняются последовательно.
И в итоге, они считают, что есть всего 4 варианта того, в каком порядке выполняются действия потоков:

x = y = 0;                                            
                                                      
 T1         |  T2            T1         |  T2         
--------------------------  --------------------------
x = 1;      |               x = 1;      |             
int r1 = y; |                           | y = 1;      
            | y = 1;        int r1 = y; |             
            | int r2 = x;               | int r2 = x; 
                                                      
                                                      
 T1         |  T2            T1         |  T2         
--------------------------  --------------------------
            | y = 1;        x = 1;      |             
x = 1;      |                           | y = 1;      
int r1 = y; |                           | int r2 = x; 
            | int r2 = x;   int r1 = y; |             

Как видите, во всех четырёх случаях первым всегда идёт либо x = 1; либо y = 1;, а значит результата (r1==0, r2==2) быть не должно.

А в JMM такой результат допустим.
Значит описанный выше "интуитивный" подход не работает в java, и программистам нужно разбираться с happens-before, volatile и остальной JMM.

В разделе "volatile", код с volatile неверный, так так если поток reader читает в r1, потом поток writer выполняет "initialized = true; /* W2 /", по проверка в reader "if (r1)" не пройдёт, хотя x уже гарантировано имеет значение 5. Уберите ненужное присваивание "boolean r1 = initialized; / R1 */" и сразу пишите "if (initialized)".

Вы не поверите, но это абсолютно одинаковый код :) Чтобы выполнить if-условие, необходимо сначала выполнить чтение. Нет разницы, вынесем мы это чтение в отдельную переменную или нет.

Чтобы подтвердить свои слова, приведу дизассемблер обоих вариантов:

    public static void reader1() {
        boolean r1 = initialized; /* R1 */
        if (r1) {
            int r2 = x; /* R2 */
        }

        /*
          x86:
              0x000002239b45b5de:   movsx  esi,BYTE PTR [rsi+0x74]      ;*getstatic initialized {reexecute=0 rethrow=0 return_oop=0}
                                                                        ; - jit_disassembly.JmmVolatileConditionRead::reader1@0 (line 14)
              0x000002239b45b5e2:   cmp    esi,0x0
              0x000002239b45b5e5:   movabs rsi,0x223b7c037e0            ;   {metadata(method data for {method} {0x00000223b7c032d8} 'reader1' '()V' in 'jit_disassembly/JmmVolatileConditionRead')}
              0x000002239b45b5ef:   movabs rdi,0x110
              0x000002239b45b5f9:   je     0x000002239b45b609
              0x000002239b45b5ff:   movabs rdi,0x120
              0x000002239b45b609:   mov    rbx,QWORD PTR [rsi+rdi*1]
              0x000002239b45b60d:   lea    rbx,[rbx+0x1]
              0x000002239b45b611:   mov    QWORD PTR [rsi+rdi*1],rbx
              0x000002239b45b615:   je     0x000002239b45b628           ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
                                                                        ; - jit_disassembly.JmmVolatileConditionRead::reader1@5 (line 15)
              0x000002239b45b61b:   movabs rsi,0x7114bd448              ;   {oop(a 'java/lang/Class'{0x00000007114bd448} = 'jit_disassembly/JmmVolatileConditionRead')}
              0x000002239b45b625:   mov    esi,DWORD PTR [rsi+0x70]     ;*getstatic x {reexecute=0 rethrow=0 return_oop=0}
                                                                        ; - jit_disassembly.JmmVolatileConditionRead::reader1@8 (line 16)
        */
    }

    public static void reader2() {
        if (initialized) { /* R1 */
            int r2 = x; /* R2 */
        }

        /*
          x86:
              0x000002239b45b25e:   movsx  esi,BYTE PTR [rsi+0x74]      ;*getstatic initialized {reexecute=0 rethrow=0 return_oop=0}
                                                                        ; - jit_disassembly.JmmVolatileConditionRead::reader2@0 (line 21)
              0x000002239b45b262:   cmp    esi,0x0
              0x000002239b45b265:   movabs rsi,0x223b7c03930            ;   {metadata(method data for {method} {0x00000223b7c03388} 'reader2' '()V' in 'jit_disassembly/JmmVolatileConditionRead')}
              0x000002239b45b26f:   movabs rdi,0x110
              0x000002239b45b279:   je     0x000002239b45b289
              0x000002239b45b27f:   movabs rdi,0x120
              0x000002239b45b289:   mov    rbx,QWORD PTR [rsi+rdi*1]
              0x000002239b45b28d:   lea    rbx,[rbx+0x1]
              0x000002239b45b291:   mov    QWORD PTR [rsi+rdi*1],rbx
              0x000002239b45b295:   je     0x000002239b45b2a8           ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
                                                                        ; - jit_disassembly.JmmVolatileConditionRead::reader2@3 (line 21)
              0x000002239b45b29b:   movabs rsi,0x7114bd448              ;   {oop(a 'java/lang/Class'{0x00000007114bd448} = 'jit_disassembly/JmmVolatileConditionRead')}
              0x000002239b45b2a5:   mov    esi,DWORD PTR [rsi+0x70]     ;*getstatic x {reexecute=0 rethrow=0 return_oop=0}
                                                                        ; - jit_disassembly.JmmVolatileConditionRead::reader2@6 (line 22)
        */
    }

Ссылка на программу, которую я тестировал (также привел там disasm и для arm64) - https://gist.github.com/blinky-z/bd0143794421878ee10dd4846da59df3

Все запутанно)
Но главное, чтобы все понимали о чем идет речь. Например, многие говорят "функционал" вместо "функциональность" (приложения), но все равно всем понятно о чем идет речь из контекста.

Поразмыслил еще раз и понял, что я действительно не прав. Спасибо за такое полезное замечание!

Для начала, укажу на свою ошибку: "immediately visible to every thread" надо понимать так, как вы и сказали. То есть, если запись становится видной хотя бы одному треду, то и все остальные треды увидят эту запись.

Далее я буду излагать свой порядок мыслей по порядку, чтобы мы единообразно понимали написанное в спеке.

На уровне SC модели действительно нет никакого времени, а есть лишь порядок и видимость предыдущих действий. Разберем еще раз определение в спеке:

A set of actions is sequentially consistent if all actions occur in a total order (the execution order) that is consistent with program order, and furthermore, each read r of a variable v sees the value written by the write w to v such that:

- w comes before r in the execution order, and

- there is no other write w' such that w comes before w' and w' comes before r in the execution order.

Здесь говорится следующее:

1. SC говорит, что программа будет выполнена в execution order (он же memory order), который консистентен с program order

2. SC говорит, что если произошла запись ранее (по порядку) в memory order, то мы увидим эту запись. Но SC не говорит, когда будет видна запись

Sequential consistency можно имплементировать или исполняя все на одном ядре, или исполняя на многоядерном процессоре, но имея блокирующий "switch", который разрешает доступ к памяти только ядру (треду) за раз, причем в program order:

Теперь снова вернемся к Dekker алгоритму и рассмотрим его в рамках sequential consistency. Благодаря тому, что в Dekker алгоритме x = 1 PO r1 = y, y = 1 PO r2 = x (PO = program order), то SC соблюдет этот порядок и выполнит чтения только после одной из записей.

Но здесь действительно есть подвох: пропагация записи может занять и год, и два, и вообще не случиться. Со стороны модели главное то, что и чтение не будет выполнено, пока не завершится запись. Но нам то этого не достаточно - мы хотим увидеть эту запись когда-нибудь.

Таким образом, если мы не гарантируем eventual visibility для записей, то это не нарушит sequential consistency модель.

В итоге хочу сказать, что вы правы. Я поискал по всей спеке слова "visibility" и "eventual" и не нашел ни единого подтверждения этому.

Я это вижу так, что в JMM только некоторый набор операций может быть быть выполнен в SC memory order. Если есть другие data race, то для них не гарантируется никакого консистентного порядка, но для связанных happens-before гарантируется. Кажется, на этом делает акцент и спека:

A set of actions is sequentially consistent if all actions occur in a total order