"Привязанные к CPU" - это уж совсем лютые какие-то lock-free примитивы, я про такие даже не слышал...

Ну. libatomic такая: разное поведение на разных процессорах. Человек не правильно понял спецификацию (или она некорректная), отладился у себя, а потом завесил кластер на полдня. Бывает...

OK, неточно выразился - я имел в виду гонки, которые приводят к потере/искажению данных.
В этом смысле критерий корректности - целостность данных, который вполне обеспечивается lock-free примитивами (про которые я знаю).

ну нет,
гонка - это просто когда между двумя обращениями к одной ячейке памяти, одно из которых запись, не гарантируется happens-before.
в контексте C/C++ гонки на неатомарых переменных — это UB, остальные гонки это уже забота программиста lock-free алгоритмов

Ну. Речь же не о примитивах, а о структурах данных, которые поверх ваяют пользователи

ну вот "целостность" данных — это уже критерий специфичный для каждой конкретной структуры данных и гарантий на нее

например, что такое по-вашему lock-free stack ??

Классические (по меньшей мере) lock-free структуры типа очередей тоже строятся так, чтобы не терять данные. 🤷‍♀️

Да. Но каждый ли пользователь умеет это накодить процессоронезависимым образом? Даже в intel tbb встречаются косячки

Если мы говорим про корректность, то, очевидно, lock-free stack должен уточнять (refine) спецификацию stack. Спецификацию на стек в виде Abstract Data Type можно найти в Википедии и примерно всех учебниках, рассказывающих про ADT.
То, что он на самом деле lock-free - немного другой вопрос, формализующийся, обычно, в TLA+ или, там, сетях Петри.
Я ответил на вопрос "что такое lock-free stack по-моему"? 😊
Какой аспект Вы хотели узнать?

Моё утверждение не о том, что lock-free плохо. А о том, что к нему прибегают, когда нужно выжимать производительность. Корректности добиваться с этим кодом тяжело

Ошибки реализации потому и называются ошибками, по-моему. В lock-full алгоритмах и структурах они тоже бывают сплошь и рядом, ибо concurrency is hard. Никто же не говорит, что их не нужно исправлять, а тем более - целенаправленно вносить?

Ну. Речь о том, что вероятность накосячить с lock-free гораздо выше, чем с lock-full. Поэтому, я и говорю, что на такое идут, когда производительность нужна позарез. Ну, то есть, мы осознанно идём по минному полю, потому что миллисекунды имеют значение.

локфри же дает не сколько производительность по моему, сколько предсказуемость

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

ну хорошо, давайте рассмотрим не стек, а список (со списком мне проще показать мой поинт :)
Вот приходит один поток и говорит, хочу посчитать сумму элементов в списке.
В это время второй поток берёт и добавляет в середину новую ноду.
Что должна вернуть сумма? Должна она увидеть новую ноду или нет ?

Вы серьёзно считаете, что есть какое-то абсолютное "должно" или "правильно" без спецификации что именно ожидается в каком случае? 😉

ну мой поинт в этом же и был, для каждой конкретной лок-фри структуры данных у нас будут свои гарантии

и они часто не интринтуитивны, потому-что в lock-free часто отсутствует понятие "глобального" времени/памяти, и гонки это норма

Для структур-то гарантии одинаковые - не терять (закоммиченные) данные. Это для алгоритмов могут быть разные требования. 😊