А например следующие 2 цитаты стандарта сойдут за гарантию того, что не-seq-операция в некоторых случаях может переупорядочиваться с seq-операцией?

1. (из 1-й цитаты): Любое использование не-seq-операций даже если все остальные seq-операции - нарушает последовательную согласованность (sequential consistency).

2. (из 2-й цитаты): Последовательная согласованность "sequential consistency" - когда операции в нескольких потоках выполняются по очереди, где следующая операция видит все предыдущие операции полностью завершенными.

Т.е. если многопоточная программа состоит только из seq-операций и мы добавляем одну не-seq-операцию, то аннулируем гарантию последовательной согласованности, т.е. не все операции теперь выполняются по очереди как в одном порядке, и нет единого порядка.


Сами цитаты:

Любое использование не-seq-операций даже если все остальные seq-операции - нарушает последовательную согласованность (sequential consistency):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4606.pdf § 29.3
8 [ Note: memory_order_seq_cst ensures sequential consistency only for a program that is free of data races and uses exclusively memory_order_seq_cst operations. Any use of weaker ordering will invalidate this guarantee unless extreme care is used. In particular, memory_order_seq_cst fences ensure a total order only for the fences themselves. Fences cannot, in general, be used to restore sequential consistency for atomic operations with weaker ordering specifications. — end note ]

автор 8. memory_order_seq_cst обеспечивает последовательную согласованность только для программы , в которой нет гонок данных (data-races) и которая использует исключительно только memory_order_seq_cst операции. Любое использование более слабого упорядочивания аннулирует гарантию последовательной согласованности , за исключением если это не используется крайне осторожно. В частности, memory_order_seq_cst барьеры обеспечивают общий порядок только для самих барьеров. Барьеры, в общем случае, не могут восстановить последовательную согласованность для атомарных операций использующих более слабое упорядочивание, чем memory_order_seq_cst.

[прим. ред. Т.е. тут прямо сказано, что "Любое использование более слабого упорядочивания аннулирует гарантию последовательной согласованности", т.е. использование любой не-seq_cst операции среди всех других seq_cst операций - аннулирует последовательную согласованность ]





А тут описывается термин последовательная согласованность "sequential consistency" - когда операции в нескольких потоках выполняются по очереди, где следующая операция видит все предыдущии полностью завершенными:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4606.pdf § 1.10.2
19 Two actions are potentially concurrent if
(19.1) — they are performed by different threads , or
(19.2) — they are unsequenced, and at least one is performed by a signal handler.

... [ Note: It can be shown that programs that correctly use mutexes and memory_order_seq_cst operations to prevent all data races and use no other synchronization operations behave as if the operations executed by their constituent threads were simply interleaved, with each value computation of an object being taken from the last side effect on that object in that interleaving. This is normally referred to as “sequential consistency”. However, this applies only to data-race-free programs, and data-race-free programs cannot observe most program transformations that do not change single-threaded program semantics. In fact, most single-threaded program transformations continue to be allowed, since any program that behaves differently as a result must perform an undefined operation. — end note ]

автор 19 Два действия потенциально конкурируют (исполняются одновременно) если
(19.1) - они исполняются в разных потоках , или
(19.2) - они не последовательны, и как минимум одно из них выполняется обработчиком сигнала.
...
Можно показать, что программа правильно использующая мьютексы и memory_order_seq_cst-операции для предотвращения гонок данных и не использующая других операций синхронизации ведет себя так, как если бы операции выполняемые их потоками (в разных потоках) - были просто чередованием операций [прим. ред: как если бы выполнялись в одном потоке], где каждая следующая операция видит все предыдущими операции полностью завершенными со всеми их сторонними эффектами (со всеми side-effect). Это как правило называют "последовательная согласованность". Однако, это применимо только к программам без гонок данных (data-race-free, т.е. без многопоточных ошибок), и такие программы без гонок данных не могут наблюдать большинство преобразований [прим.ред. переупорядочиваний] программы, которые не изменяют однопоточную семантику. На самом деле, большинство однопоточных преобразований [прим.ред. переупорядочиваний] программы по прежнему возможны, т.к. любая программа которая ведёт себя по разному в результате должна выполнять неопределенную операцию. [прим.ред. последнюю часть предложения я сам не понял :) но это не важно ]


Про libcds ещё подумаю, в любом случае если и буду начинать то со статьи или мануала.

khizmaxПо поводу статей. А если взглянуть так: стандарт - набор аксиом. На любой аксиоматике, если она не противоречива, зиждется стройное здание теории - набор следствий (теорем), вытекающих из аксиом; в конце концов цепочка этих выводов приводит к утверждениям, которые легко претворять в жизнь и легко им следовать. Core guide for memory ordering, так сказать.
Я имею ввиду, что кто-то может сказать, что в стандарте есть какая-нибудь бредовая гарантия, что, например: все обычные float-переменных упорядочены.
Оно там где-то есть, где именно этот некий человек не помнит, ну а вы все просто плохо ищите
А т.к. опровержения всех бредовых мыслей в стандарте конечно же нет, то таким людям никогда не докажешь что нет строго порядка у обычных float.

Anatoly Moskovsky http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4606.pdf § 29.3
8 [ Note: memory_order_seq_cst ensures sequential consistency only for a program that is free of data races and uses exclusively memory_order_seq_cst operations. Any use of weaker ordering will invalidate this guarantee unless extreme care is used. In particular, memory_order_seq_cst fences ensure a total order only for the fences themselves. Fences cannot, in general, be used to restore sequential consistency for atomic operations with weaker ordering specifications. — end note ]
Что-то сильно ограничили они. Если исходить из этой цитаты, выходит что т.к. в любой реальной программе всегда есть операции без барьеров , то seq_cst не дает вообще никаких гарантий.
А это явно не так. Т.е. есть еще какие-то условия.
Видимо детальное описание что когда и с чем может иметь или менять порядок, а что не может - составляло множество страниц, поэтому они решили ограничится дополнительной фразой "unless extreme care is used"
Но по крайней мере эта цитата стандарта точно говорит, что в приведенных мною выше примерах не гарантируется "sequential consistency" для всех операций, а значит не гарантируется "single total order" для всех операций и не гарантируется по очередность выполнения инструкций.


Anatoly MoskovskyВася УткинОбкладывайте критическую секцию снаружи std::atomic_thread_fence(std::memory_order_seq_cst); https://godbolt.org/g/CT89i5
ни одна муха не пролетит в неё, и увидите по изменению производительности - кому лучше знать :)
Ну, в С++ мьютексы реализованы через вызовы фукнций, а вызов функции, даже если она потом инлайнится, это барьер , так что через него муха точно не пролетит, по крайней мере при компиляции.
Вы имеете ввиду, что вызов любой функции в C++ инициирует spilling-всех переменных? Есть цитата стандарта? :)
Иначе все что вы писали в переменные до вызова этой функции так и останется в регистрах процессора надолго.

khizmaxТеперь я понимаю, откуда у Страуструпа & Co родилась идея C++ Core Guidelines: посмотрели они на 100500 страниц стандарта и подумали: "каждая фраза - правда, а вместе - какой-то винегрет. Надо как-то объяснить народу..."
Но пока что про memory_order_seq_cst они написали только 2 строчки )
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines Exception Atomic variables can be used simply and safely , as long as you are using the sequentially consistent memory model (memory_order_seq_cst), which is the default.
Это легко и безопасно, а вы говорите мрак