атомиков, если у моей архитектуры точно работает протокол MESI, нужно ли мне парится за реордеринг внутри комманд процессора (Конкретнее за инвалидацию кэшей)? Строя барьеры так, чтобы они точно помогали избавиться от реордеринга компилятором.
> Строя барьеры так, чтобы они точно помогали избавиться от реордеринга компилятором не очень понятен вопрос, если речь про C/C++, то речь идёт о программировании виртуальной машины, и гарантии в барьерах атомиков распространяются на итоговый сгенерированный код
Имеется в виду код, кт в теории может соблюдать порядок проверки каких-то флагов, но не соблюдать порядок их инициализации относителтно друг друга. (Потому что они например в разных потоках инциализируются и оба получаются release). Условно говоря, они могут порождать ситуацию, когда f1 у одного процессора true, f2 - false, а у другого наоборот. Фиксится ли это самой системой (каким-нибудь умным протоколом)?
Я о чём пытаюсь сказать. Если формально C/C++ код допускает такое состояние (а, как я понимаю, запись с release его допускает), то компилятор считает такой результат допустимым, иначе нет
То есть нет никакой разницы между "ограничениями для компилятора" и "ограничениями, которые соблюдаются в результирующем коде", если речь не идёт о volatile-операциях
Что именно подразумевается под "париться"?
Ну писать таким образом чтобы быть уверенным, что такой ситации не будет
Какой "такой"? Я все еще не вижу конкретики, которую можно обсудить в рамках Стандарта)
При которой разные ядра в какой-то тик видят разные значения, ща найду пример и мб вы мне объясните что я неправильно понял
https://github.com/anthonywilliams/ccia_code_samples/blob/main/listings/listing_5.7.cpp - там мало строк, это из уильямса, кт утверждает, что тут ассерт может и сработать, хотя для компилятора все ясно в плане реордеринга, для процессора может быть ситуация с противоположными значениями. Подробно он не называет причину, но как я понял - инвалидация кэшей. Вот тут то и вопрос, а нужно ли о таком переживать, если есть MESI? Иначе я не понимаю почему assert может и сработать :/
нужно переживать хотя бы потому, что с точки зрения компилятора это возможный результат исполнения
Но почему? Не может же быть ситации чтобы в последнем работающем read было одно значение true, но не было другого? Они ж атамарно работают
Хм... вы физику СТО не учили?) Говорить о том, что Х произошло раньше У, можно только когда между ними возможна причинно-следственная связь, иначе локальные координаты могут их переупорядочить...
Обсуждают сегодня