lock-free вот это вот всё

и нет, они не атомарные

и нет, они не атомарные

почему?

просто пользоваться тем, что это атомарные переменные

это не так.

Друзья! Вопрос, к сожалению, не про реальный мир, а про стандарт. Насколько я понял до текущего момента, стандарт абстрагирует треды под термин execution agent (an entity such as thread that may perform work in parallel with other execution agents), и добавляет замечание (Implementations or users may introduce other inds of agents such as processes or thread-poll tasks). И, подобно им, вводит концепции BasicLockable и Lockable типов, над unlock-lock вызовами которых работает syncronize-with отношение

Друзья! Вопрос, к сожалению, не про реальный мир, а про стандарт. Насколько я понял до текущего момента, стандарт абстрагирует треды под термин execution agent (an entity such as thread that may perform work in parallel with other execution agents), и добавляет замечание (Implementations or users may introduce other inds of agents such as processes or thread-poll tasks). И, подобно им, вводит концепции BasicLockable и Lockable типов, над unlock-lock вызовами которых работает syncronize-with отношение

ага

почему?

Ни разу нет

почему?

потому что операции инкремента/декремента не будут видны в других потоках потому что операции записи и чтения значения будут работать не так, как вы ожидаете

потому что операции инкремента/декремента не будут видны в других потоках потому что операции записи и чтения значения будут работать не так, как вы ожидаете

если пометить volatile будут видны

если пометить volatile будут видны

Тоже не будут

если пометить volatile будут видны

:)))

если пометить volatile будут видны

Ну вот ни разу не правда: https://godbolt.org/z/qv__KG

если пометить volatile будут видны

.. и она всё равно не будет атомарной.

если пометить volatile будут видны

нет, не будут

если пометить volatile будут видны

volatile просто запретит оптимизировать чтение и запись в память, а что там уже в кешах процессора — не его дело

потому что volatile не добавляет такой семантики

на каком-нибудь обрубке без кешей volatile, да, сделает своё дело

Но где такие остались?

на каком-нибудь обрубке без кешей volatile, да, сделает своё дело

там ещё и регистров не должно быть, чтобы оно и правда работало

Ну вот ни разу не правда: https://godbolt.org/z/qv__KG

немного про разницу: lock xadd DWORD PTR a[rip], eax - сразу меняет значение в памяти mov eax, DWORD PTR s[rip] - читает значение из памяти в регистр add eax, 1 - меняет регистр mov DWORD PTR s[rip], eax - записывает регистр обратно во втором случае, при операции "add eax, 1" другой поток может поменять значение и записать его в память. Мы же новое значение перетрём своим

потому что volatile не добавляет такой семантики

Жаль, я бы от джавового волатайла в плюсах не отказался

volatile обрубает кэширование вроде

там только барьера не хватать будет для полноценного atomic

немного про разницу: lock xadd DWORD PTR a[rip], eax - сразу меняет значение в памяти mov eax, DWORD PTR s[rip] - читает значение из памяти в регистр add eax, 1 - меняет регистр mov DWORD PTR s[rip], eax - записывает регистр обратно во втором случае, при операции "add eax, 1" другой поток может поменять значение и записать его в память. Мы же новое значение перетрём своим

я нигде не говорил про атомарный инкремент ;) только чтение-запись

я нигде не говорил про атомарный инкремент ;) только чтение-запись

там будет не то поведение, что вы ожидаете :)

если в одном потоке while (val) { do something }, в другом val = 0, если val - это volatile int на 32-х битном процессоре, будет норм работать )

я вот про такие простые вещи, если что

я нигде не говорил про атомарный инкремент ;) только чтение-запись

..и всё равно volatile не гарантирует happens-before

..и всё равно volatile не гарантирует happens-before

естественно

писал же, что барьера нет

я вот про такие простые вещи, если что

нет, не будет https://godbolt.org/z/RMAObJ разница в mfence/xchg (второй на x86 атомарен)

если в одном потоке while (val) { do something }, в другом val = 0, если val - это volatile int на 32-х битном процессоре, будет норм работать )

Здесь может выполниться лишние циклы, после val = 0.

Здесь может выполниться лишние циклы, после val = 0.

конечно

речь о ситуациях когда это не важно

Здесь может выполниться лишние циклы, после val = 0.

верно

нет, не будет https://godbolt.org/z/RMAObJ разница в mfence/xchg (второй на x86 атомарен)

я не про то и вообще для x86_64 надо long long

речь о ситуациях когда это не важно

ок теперь главный вопрос - ЗАЧЕМ так делать, если std::atomic - проще, переносимее и документирует поведение?

ок теперь главный вопрос - ЗАЧЕМ так делать, если std::atomic - проще, переносимее и документирует поведение?

ну для embed например, где компилятор C++11 или какой там надо, не завезли

это редкие ситуации, когда стандартный лок из ОС по какой-то причине не устраивает (слишком медленный например)

это что за суровый embedded такой, где архитектура x86 и много ядер?

это что за суровый embedded такой, где архитектура x86 и много ядер?

на arm всё то же самое

Можно ещё и в чатик по Яве закинуть :) Там один доклад про нетормозящую Яву

@jbaruch, @dmsol

и много ядер сейчас почти везде )

на arm всё то же самое

PowerPC шлет тебе привет ?

PowerPC шлет тебе привет ?

вот с этим я вообще не работал )) не знаю что там было раньше на маках

слишком молодой )

вот с этим я вообще не работал )) не знаю что там было раньше на маках

Да консольки жеж

Да и сервера есть

Да консольки жеж

а, ну там вообще отдельный разговор ))

Да и сервера есть

IBM Power в серверах это немного не то

на arm всё то же самое

на арм есть c++11

на арм есть c++11

если тулчейн не при царе горохе собирали ;)

кароч, я не спорю, что std::atomic здорово, просто вопросы по фактам были

если в одном потоке while (val) { do something }, в другом val = 0, если val - это volatile int на 32-х битном процессоре, будет норм работать )

очень редко когда надо писать такое говно )

кароч, я не спорю, что std::atomic здорово, просто вопросы по фактам были

В любом случае, то чем вы занялись - полезно ?

:)

Ну блин, обновление тулчейна раз в год-два даёт ~10% прироста производительности Это какие-то нездоровые наклонности - писать volatile чтобы что-то там сэкономить (ценой простреленных ног), и при этом не обновлять тулчейн (даст намного больший прирост производительности)

если в одном потоке while (val) { do something }, в другом val = 0, если val - это volatile int на 32-х битном процессоре, будет норм работать )

нет, и тут тоже не поможет

Ну блин, обновление тулчейна раз в год-два даёт ~10% прироста производительности Это какие-то нездоровые наклонности - писать volatile чтобы что-то там сэкономить (ценой простреленных ног), и при этом не обновлять тулчейн (даст намного больший прирост производительности)

да не, обычно это какие-нибудь китайцы с убердешевыми уберстарыми ip-камерами или чем там

ух, жуть

нет, и тут тоже не поможет

а что именно не поможет? цикл будет вечно тарабанить? )

а что именно не поможет? цикл будет вечно тарабанить? )

кстаааааааати да

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

очень редко когда надо писать такое говно )

Блин, вообще, вопрос я задал, потому что именно такой код ( :))) ), написал мой коллега, где val был volatile, и я начал раскидываться цитатами из Стандарта про UB. А треды использовались Qtшные и коллега возражал, что так как это не стандартные треды и примитивы синхронизации, то эти цитаты из Стандарта не эпплаятся

с вытесняющей многозадачностью полегче - рано или поздно ОС вытестин ваш цикл, зафлашит кеши

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

ну там linux обычно, с вытесняющей многозадачностью, к тому же там внутри while надо как-нибудь разрешить переключение контекста обычно, sleep там какой-нибудь

Блин, вообще, вопрос я задал, потому что именно такой код ( :))) ), написал мой коллега, где val был volatile, и я начал раскидываться цитатами из Стандарта про UB. А треды использовались Qtшные и коллега возражал, что так как это не стандартные треды и примитивы синхронизации, то эти цитаты из Стандарта не эпплаятся

не пропускай это на ревью. Спаси будущие поколения :)

Блин, вообще, вопрос я задал, потому что именно такой код ( :))) ), написал мой коллега, где val был volatile, и я начал раскидываться цитатами из Стандарта про UB. А треды использовались Qtшные и коллега возражал, что так как это не стандартные треды и примитивы синхронизации, то эти цитаты из Стандарта не эпплаятся

Стандартные примитивы синхронизации работают вне зависимости от того, используется std::thread или Qt thread

Блин, вообще, вопрос я задал, потому что именно такой код ( :))) ), написал мой коллега, где val был volatile, и я начал раскидываться цитатами из Стандарта про UB. А треды использовались Qtшные и коллега возражал, что так как это не стандартные треды и примитивы синхронизации, то эти цитаты из Стандарта не эпплаятся

аргументация такая же странная как и само действие ))

Блин, вообще, вопрос я задал, потому что именно такой код ( :))) ), написал мой коллега, где val был volatile, и я начал раскидываться цитатами из Стандарта про UB. А треды использовались Qtшные и коллега возражал, что так как это не стандартные треды и примитивы синхронизации, то эти цитаты из Стандарта не эпплаятся

При чём здесь qt-шные треды? Во-первых они реализованы на тех же примитивах ОС, во вторых - вопрос здесь в семантике volatile, а не тредов )

При чём здесь qt-шные треды? Во-первых они реализованы на тех же примитивах ОС, во вторых - вопрос здесь в семантике volatile, а не тредов )

Тоже pthread?

Тоже pthread?

да

Тоже pthread?

на linux - да

Тоже pthread?

ну на linux сложно представить что-то другое

или уже нет? )

Блин, вообще, вопрос я задал, потому что именно такой код ( :))) ), написал мой коллега, где val был volatile, и я начал раскидываться цитатами из Стандарта про UB. А треды использовались Qtшные и коллега возражал, что так как это не стандартные треды и примитивы синхронизации, то эти цитаты из Стандарта не эпплаятся

Ну там "Synchronization: Prior unlock() operations on the same object shall synchronize with (6.8.2) this operation." так что обязано работать вне зависимости от имплементации потоков

Стандартные примитивы синхронизации работают вне зависимости от того, используется std::thread или Qt thread

да, но коллега использовал в качестве "примитива" только volatile bool

да, но коллега использовал в качестве "примитива" только volatile bool

а можно код полностью, что оно там делать должно?

а можно код полностью, что оно там делать должно?

нельзя

но вообще без надобности нехорошо так писать в любом случае

нельзя

ок понел ))

я сдаюсь....

или уже нет? )

Ну а вдруг ?

переписал на smart pointer

да, но коллега использовал в качестве "примитива" только volatile bool

это типа спор о том, делает ли волатайл атомиком?

переписал на smart pointer

давно пора

можете поревьюить код?

Аллокаторов жеж развелось)

да, но коллега использовал в качестве "примитива" только volatile bool

"Он же размером с машинное слово", да?)

можете поревьюить код?

кидай на пастбин

ну гитхаб есть

И Даг Ли руку приложил, и МС, и Гугл

пастбин не осилю

это типа спор о том, делает ли волатайл атомиком?

да. Странно, что он до сих пор продолжается

https://github.com/Worsell/SomeSimpleProjects/tree/SimpleBinaryTree/scr/SimpleTree

это типа спор о том, делает ли волатайл атомиком?

если так вопрос ставить, то ответ конечно нет

вот короче гитхаб

volatile не делает никого атомиком в c++

есть такая проблема