Я знаю, что процессор может изменить порядок команд, таких как
load A
load B
но процессор переупорядочит следующий код? (другими словами, будет ли второй поток, работающий на другом ядре, видеть результат в обратном порядке?)
some_array[array_index] = new_value;
++array_index;
Я предполагаю, что это будет НИКОГДА потому что вторая строка зависит от первой строки. Я прав?
Нет, ты не прав.
Компилятор и ЦП полностью свободны для оптимизации и переупорядочения кода, если результат одинаков для любого гарантированного поведения. То, что другие потоки увидят изменения в каком-либо конкретном порядке, не гарантируется. Так, например, процессор и компилятор могут свободно реализовывать код так же, как этот код:
++array_index;
some_array[array_index - 1] = new_value;
Или даже:
tmp = array_index;
++array_index;
some_array[tmp] = new_value;
Поскольку никакие гарантии не нарушаются, компилятор и процессор могут выполнять эти оптимизации. Это хорошо, потому что они могут сделать код значительно быстрее.
Если вам нужно больше гарантий, вы можете использовать соответствующие инструменты (замки, барьеры, атомы, что угодно), чтобы получить их. Но нет кода причины, который не заботится об этом, следует запретить оптимизацию, подобную этой.
Вот где вы ошиблись:
Я предполагаю, что это никогда не будет, потому что вторая строка зависит от первой строки. Я прав?
Только если ни процессор, ни компилятор не смогут выяснить зависимость и распутать ее. Но это тривиально очевидно здесь. С выясненной зависимостью они могут выполняться в любом порядке, и компиляторы и ЦП фактически выявляют такие виды зависимостей (и даже более сложные), потому что наше программное обеспечение будет много медленнее, если они этого не сделали.
Но даже если бы зависимость была безотзывной, это не требовало бы, чтобы фактические записи были видны другим потокам в любом конкретном порядке. Они могут находиться в буферах записи записи ЦП и выполняться в любом порядке. И другой поток может также переупорядочить операции чтения, при этом процессор будет выполнять чтение впереди.
Других решений пока нет …