Лагман
Это не работает. Во-первых, это не защищает от реордеринга, так как те же спекулятивные чтения никто не отменял. Во-вторых, потому что если бы вы даже смогли таким образом предовтратить реордеринг, у вас все равно не будет гарантий того, что другой поток увидит изменения именно в таком порядке. Погуглите про store buffer и invalidate queue.

Лагманzig zu,
реордеринг возможен, если инструкции независимы друг от друга. Если мы пишем reslit != null то это уже зависит от reslit, и реордеринга не будет.К сожалению, это не так. Out-of-order execution это значительно более сложная вещь, чем "раз зависимы, значит не зареордерятся".

zig zuесть такой код




в первом потоке может случится реордеринг и второй поток словит NPE. Как сделать, чтобы первый поток всегда выполнял строку после строки ? В противном случае от NPE во втором потоке никто не гарантирует.Вам нужен synchronized-with между запись в reslitReady, и чтением из него. Есть множество вариантов, как сделать это.
1) Самый простой - объявить reslitReady volatile.
2) Можно обернуть эти два участка кода в synchronized на одном и том же мониторе.
3) Ну и всевозможные способы, производные от первых двух.

Вообще, мужики, потерпите, ждать осталось не долго - скоро будет готова моя первая часть тренинга по multithreading. В эту часть войдет вся теория по JMM, synchronized, volatile, final, а так же вопросы остановки потоков. Вчера как раз весь день рисовал схемки, как кэши работают :-)
Можете уже бронировать места

zig zuНаверное Out-of-order execution действительно крутая и очень сложная штука, но не могли бы вы на пальцах объяснить, как вот такой код может подвергнутся реордеренгу?Например, speculative branch prediction. Как это может произойти:
1) Процессор начинает выполнять calc(), и натыкается там на чтение значения, которого нет в кэшах.
2) Из-за этого процессор вынужден отправить запрос в память на получение этого значения; длительность этого чтения может составлять сотни тактов.
3) Что бы не стоять эти такты без дела, процессор начинает фигачить следующие инструкции (пошел out-of-order execution);
4) Процессор натыкается "reslitReady = reslit != null"
5) Вроде бы дело дрянь, так и так придется ждать окончание долго чтения в calc(). Но процессор находит выход: он делает спекулятивное предположение, что, например, reslit != null в будущем будет true, и присваивает reslitReady = true.
6) Далее, если у вас есть что-то вроде "if (reslitReady) { ... }", процессор попытается спекулятивно выполнить какие-то инструкции из этого бранча.
7) Наконец, нам приходит ответ на чтение. Если процессор угадал результат - все круто, идем дальше. Если не угадал - откатываемся.