ПК
volatile от ms обещает rel/ac.
Я так понимаю rel/ac не даст happens before
Size: a a a
2020 June 22
m
Я так понимаю rel/ac не даст happens before
Да, здесь вы правы.
ПК
читающий thread устраивают оба случая: что он прочитал переменную и до записи и после
Грубо говоря работает до первого компилятора, который сможет это как то оптимизировать и создать неработающую программу
m
ну надо учитывать аппаратные гарантии всегда
если считать что их вообще нет никаких, то невозможно писать производительные многопоточные программы
если считать что их вообще нет никаких, то невозможно писать производительные многопоточные программы
Но вы же видели, что инкремент volatile от ms был разбит на 3 операции. load inc store. Где гарантия что между load и store другой поток не изменит значение?
ПК
в стандарте решили это не описывать
только компилятор работает по стандарту и не увидев в нужном месте mutex.lock или atomic может посчитать, что тут однопоточный код и из этого сделать какие то выводы, которые приведут к неработающей программе. И на платформу ему будет пофиг
S
только компилятор работает по стандарту и не увидев в нужном месте mutex.lock или atomic может посчитать, что тут однопоточный код и из этого сделать какие то выводы, которые приведут к неработающей программе. И на платформу ему будет пофиг
volatile должен этому мешать
ПК
volatile должен этому мешать
только как случайность в некоторых случаях, в общем случае никаких гарантий нет
S
Но вы же видели, что инкремент volatile от ms был разбит на 3 операции. load inc store. Где гарантия что между load и store другой поток не изменит значение?
даже если он не разбит а сделан одной инструкцией:
inc x - это не атомарная - другой поток может вклиниться в середину ее выполнения