Гарантирует ли стандарт атомарное чтение и запись данных, размер которого не более чем машинное слово?

Насколько я знаю атомарность для чтения и записи данных которые не более чем одно машинное слово, гарантируется на уровне процессора. А со стороны стандарта с++ есть подобные гарантии? Тут речь не про std::atomic, а именно про обычные переменные.

0

TRam_, в контексте вопроса ТС, тут скорее проблема не в "устаревших значениях", а в том, что можно получить значение, которое только частично "обновилось", если операции чтения/записи не атомарны.

Добавлено через 22 минуты

Сообщение от TRam_ Или значение (содержимое полей структуры), которое было обновлено только частично.

Именно "частичное обновление" и значит, что операция чтения или записи не атомарна.

ТС же интересует, есть ли определённые гарантии атомарности стандартных типов в стандарте языка.

1

gray_fox, если работать на однопроцессорной машине/в одном потоке и никакие прерывания/другие потоки не меняют переменные этой программы, то ситуации что "частично обновилось" не бывает. Просто потому, что код будет выполняться строго последовательно, а "частичное обновление" подразумевает то, что в выполнение программы как-то вклинились между какими-то из последовательных операций обновления переменной.

Добавлено через 9 минут
По тому же принципу мьютексы/семафоры в однопоточной программе бессмысленны - потому что могут привести только к зависанию из-за самоблокировки потока, или просто будут бесполезно жрать ресурсы, закрываясь и открываясь.

0

Сообщение от TRam_ сли работать на однопроцессорной машине и никакие прерывания не меняют переменные этой программы, то ситуации что "частично обновилось" не бывает.

Вы имеете ввиду, что все store/load (и "производные") операции атомарны в контексте одного процессора? Я правильно понял?

0

Сообщение от gray_fox Я правильно понял?

в контексте одного процессора с выключенными прерываниями. Но такого в реальности почти не бывает, можно говорить только о абсолютной атомарности для "одного процессора, прерывания которого не оказывают влияния на переменные данной программы"

0

Потому что это очевидно не так.

Добавлено через 5 минут
Ну допустим... Но в любом случае это конкретная конфигурация, которая не имеет никакого отношения к изначальному вопросу.

Добавлено через 8 минут

0

Сообщение от gray_fox которая не имеет никакого отношения к изначальному вопросу

Как не имеет? Уже ж было сказано, что на многопроцессорной машине без гарантированной синхронизации кэшей операция для переменной длиной в машинное слово не будет атомарной, потому что другой поток на другом ядре может получить устаревшее значение переменной уже после выполнения присвоения этой переменной нового значения. Несмотря на то, что этому ядру требуется только один такт для такого присвоения, а тому ядру - один такт для считывания.
Случай, если у нас однопоточная программа, разобран выше.
Остаётся случай, когда у нас многопоточная программа и процессор одноядерный или с синхронизацией кэшей, то для него могло быть что-то записано в стандарте (так как да, атомарность операций с машинным словом тут была бы логична). Но он же частный.

0

Сообщение от TRam_ на многопроцессорной машине без гарантированной синхронизации кэшей операция для переменной длиной в машинное слово не будет атомарной

Ты путаешь такие понятия, как атомарность и видимость (atomicity and visibility).

Атомарность (в контексте операции) значит, что операция либо не произошла (значение не изменилось), либо произошла (значение изменилось). Нет промежуточных состояний (часть операции прошла, а часть нет), соответственно нельзя "увидеть" промежуточное состояние (например, когда половина переменной приняла новое значение, а вторая ещё хранит старое). Но это не значит, что изменения сразу будут видимы в контексте другого потока (будь он на том же ядре, процессоре или где ещё).
Уверен ТС интересует именно это.

Видимость значит, как другие (относительно текущего) потоки могут видеть состояние переменной: тут уже зависит от memory_order
- если, например, использовть release-acquire семантику, то поток, "читающий" значение, получит актуальное значение сразу же при чтении (будет синхронизация кеша(/кешей), если "физические" ядра различны)
- если использвать relaxed семантику, то изменения значения не будут сразу же "распространены" (ничто не синхронизируется, просто изменяется значение переменной). Но, тем не менее, операции атомарны

Добавлено через 14 минут
В последнем абзаце я подразумеваю, что переменная - инстанс std::atomic<>.

1

Умные дяди пишут что стандарт ничего не гарантирует (перевод статьи)

В C/C++ каждая операция считается неатомарной до тех пор, пока другое не будет явно указано прозводителем компилятора или аппаратной платформы — даже обычное 32-битное присваивание.

C++
1 2 3 4 5 uint32_t foo = 0; void storeFoo() {     foo = 0x80286; }

Стандарты языка ничего не говорят по поводу атомарности в этом случае. Возможно, целочисленное присваивание атомарно, может быть нет. Поскольку неатомарные операции не дают никаких гарантий, обычное целочисленное присваивание в C является неатомарным по определению.

1

Сообщение от gray_fox - если, например, использовть release-acquire семантику, то поток, "читающий" значение, получит актуальное значение сразу же при чтении

Что здесь поднимается под "актуальным значением"?

0

Ygg,
Спасибо за статью!

Добавлено через 8 минут
Попробую ответить пока gray_fox нет
Может добавит что-то

Сообщение от SeqInconsistent Что здесь поднимается под "актуальным значением"?

Процессор оперирует данными как правило через свои кэши
При этом у каждого ядра свой кэш
Учитывая то что каждый поток выполняется на отдельном ядре (физическом или логическом)
То если поток А что-то записал себе в кэш, это вовсе не значит что поток Б тут же увидит это значение
Поток Б будет работать со своим кэшем и у него вполне может быть другое значение для этой же переменной
Но ядра могут обмениваться своми кэшами

Под актуальностью подразумевается то, что при чтении данных используя барьеры памяти поток Б может забрать к себе в кэш то что записал поток А... (подразумевается что поток А был последним который что либо записал в эту переменную). И чтение этих данных потоком Б будет строго после того как завершится синхронизация кэшей.

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

0

Сообщение от Undisputed Процессор оперирует данными как правило через свои кэши

Меня интересует что понималось под "актуальным значением" с формальной точки зрения (стандарта).

0

Сообщение от SeqInconsistent Меня интересует что понималось под "актуальным значением" с формальной точки зрения (стандарта).

Понятно. Насколько я знаю в стандарте такого понятия нету.
Там все это объясняется понятиями "происходит раньше", "синхронизируется-с" и т.п

0

Сообщение от Undisputed Насколько я знаю в стандарте такого понятия нету.

Смотря что понимать под "актуальным значением".
Если последнее значение из modification order (http://eel.is/c++draft/intro.r... tion_order) — то есть.
Но в таком случае утвержедние про то, что load-acquire получает "актуальное значение" — неверно, т.к. стандарт такого не гарантирует.

Поэтому непонятно, что подразумевалось под "актуальным значением" в

Сообщение от gray_fox если, например, использовть release-acquire семантику, то поток, "читающий" значение, получит актуальное значение сразу же при чтении

0

SeqInconsistent,
Не очень понятно что именно вы хотите сказать, расшифруйте плиз
Ну есть порядок изменений, ясное дело, есть... Но не понятно что дальше вы имеете ввиду...

Тут речь о том что если поток А сделал store используя memory_order_release, то при load этой же самой атомарной переменной с memory_order_acquire поток Б увидит то, что последним было записано в эту самую атомарную переменную потоком А.

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

0

Сообщение от Undisputed Тут речь о том что если поток А сделал store используя memory_order_release, то при load этой же самой атомарной переменной с memory_order_acquire поток Б увидит то, что последним было записано в эту самую атомарную переменную потоком А.

Такой гарантии нет.

Добавлено через 2 минуты

Сообщение от Undisputed Не очень понятно что именно вы хотите сказать, расшифруйте плиз

Я хочу сказать, что "последнее значение из modification order" это единственное, что приходит мне на ум, когда я читаю про "актуальное значение".

Но, как я уже говорил, никто чтению с memory_order_acquire не гарантирует получения этого последнего значения.

0

Сообщение от SeqInconsistent никто чтению с memory_order_acquire не гарантирует получения этого последнего значения.

Операция загрузки с этим упорядочением памяти выполняет операцию захвата (acquire) над задействованной областью памяти: предыдущие записи, сделанные в зависимую от данных область памяти потоком, который выполнил освобождение (release), становятся видимыми в данном потоке.

http://ru.cppreference.com/w/c... mory_order

Так же по вашей ссылке:

Certain library calls synchronize with other library calls performed by another thread. For example, an atomic store-release synchronizes with a load-acquire that takes its value from the store

Приблизительный перевод выделенного:
Атомарная операция store с освобождением (memory_order_release), синхронизируется с загрузкой acquire (memory_order_acquire), которая получает значение, сохраненное при помощи store операции.

То есть acquire-читатель видит то, что сохранил release-писатель для той же самой атомарной переменной.

Исходя из написанного, поведение, о котором идет речь, именно что гарантируется...
Отсюда возникает вопрос - что по вашему не так?

0

Сообщение от Undisputed То есть acquire-читатель видит то, что сохранил release-писатель для той же самой атомарной переменной.

Там всего лишь указано, какие store-release синхронизируются с какими load-acquire: с теми, которые прочитали значение, записанное данным store-release.
В обратную сторону это тоже работает: с теми, которые не прочитали значение — не синхронизируются.

Сообщение от Undisputed Исходя из написанного, поведение, о котором идет речь, именно что гарантируется...

Исходя из написанного именно что не гарантируется. Т.к. load-acquire самого по себе недостаточно для синхронизации, а нужен такой load-aсquire, который прочитал значение. Там же не написано что "load-acquire synchronizes with the last store-release".

Сообщение от Undisputed Отсюда возникает вопрос - что по вашему не так?

Для операций, которые читают последнее значение из modification order — это явно указано.

0

Сообщение от SeqInconsistent а нужен такой load-aсquire, который прочитал значение.

Ну да, об этом и речь... load-acquire читает значение, что же еще кроме этого делать load-acquire?

Ладно...
Может мы просто не понимаем друг друга

0

Сообщение от Undisputed Ну да, об этом и речь... load-acquire читает значение, что же еще кроме этого делать load-acquire?

Ещё раз:

Сообщение от http://eel.is/c++draft/atomics#order-2 An atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and takes its value from any side effect in the release sequence headed by A.

Release операция синхронизируется с той acquire операцией, которая читает значение, записанное данной release операцией (для простоты я игнорирую часть про release sequence).
"and takes its value" — это именно условие синхронизации, что значение должно быть прочитано, чтобы произошла синхронизация.
Ты же понимаешь это как "acquire синхронизируется с release и читает значение". То, что read читает, это, как бы, очевидно. Ты правда считаешь, что стандарт фразой "and takes its value" просто хочет сказать, что чтения читают?

На примере: в modification order для M присутствуют записи значений "a, b, c, d", записанные операциями release_a, release_b, release_c, release_d. Если acquire читает значение a, то release_a сихнронизируется с этим acquire. Если читает b — то release_b и т.д.
Правило говорит только про то, что acquire синхронизируется с тем release, чьё значение читает, не более того.

В общем случае гарантий, что acquire прочитает последнее значение из modification order — нет.

Гарантии есть, например, для memory_*order​::​seq_*cst:

Сообщение от http://eel.is/c++draft/atomics#order-3 There shall be a single total order S on all memory_*order​::​seq_*cst operations, consistent with the “happens before” order and modification orders for all affected locations, such that each memory_*order​::​seq_*cst operation B that loads a value from an atomic object M observes one of the following values: — the result of the last modification A of M that precedes B in S

Если теперь обратиться к части про release sequence:

Сообщение от http://eel.is/c++draft/intro.multithread#def:release_sequence A release sequence headed by a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A, and every subsequent operation — is performed by the same thread that performed A, or — is an atomic read-modify-write operation.

Т.е. release sequence это максимальная непрерывная последовательность операций над atomic object M, сформированная определённым образом.
Вернёмся к синхронизации через чтение значения

and takes its value from any side effect in the release sequence headed by A.

Это говорит, что для синхронизации с release operation A надо прочитать либо само значение, записанное операцией, либо любое из последующих в release sequence.

Зачем написано про любое значение из release sequence, если у нас якобы есть гарантия, что load-acquire (с memory_order ≠ seq_cst) гарантированно читает последнее значение из modification order?

1

Сообщение от gray_fox Ты путаешь такие понятия, как атомарность и видимость (atomicity and visibility)

Мне вот тоже кажется, что разные участники обсуждения понимают разные вещи под словом "атомарность". Скорее всего причина в том, что стандартные интерфейсы atomic внутри себя содержат сразу две вещи:
1. Непосредственная атомарность операции - т.е. гарантия того, что, например, при чтении из памяти, мы получим либо старое, либо новое значение (и никаких комбинаций, когда один байт старый, а другой новый)
2. Семантика операции (release, acquire, relaxed и т.п.) - не знаю, как этот параметр по умному называется. Т.е. учёт аппаратных особенностей исполнения операций чтения-записи

Кто-то под атомарностью подразумевает только п.1. (т.е. истинную смысловую нагрузку слова "атомарный"), а кто-то - одновременно п.1 и п.2. (т.е. смысл, который вкладывается в стандарты интерфейсов "atomic")

Добавлено через 5 минут

Сообщение от Undisputed Насколько я знаю атомарность для чтения и записи данных которые не более чем одно машинное слово, гарантируется на уровне процессора

Чисто на всякий случай. "Слово" - это довольно размытое понятие, которое зачастую зависит от контекста. Но даже если предположить под "словом" то, что ты имел в виду, то даже и в этом случае ты не полностью прав. В случаях, когда аппаратура позволяет строить обращения по невыровненному адресу (как это имеет место быть на intel'овской системе команд), обычно такие невыровненные обращения НЕ являются атомарными из-за особенностей работы контроллеров памяти. Контроллер памяти обычно работает только по выровненным адресам, а потому обращения по невыровненному адресу обычно отрабатываются в два приёма, а потому не являются атомарными

Сообщение от Undisputed А со стороны стандарта с++ есть подобные гарантии?

Просто чисто логически размышляя, стандарт такого не гарантирует, в противном случае не нужно было бы в стандарты вводить std::atomic и прочее

0