сравнить и обменять на процессоре x86

Question

сравнить и обменять на процессоре x86

Например, на 64-разрядных процессорах Intel i3, i5, i7 x86 верно, что CAS гарантирует только атомную скорость при макс. Размер объекта 8 байт?

на процессоре x86 инструкция блокировки добавляется к операции CAS, например. CMPXCHG, что означает, что вся строка кэша заблокирована для чтения процессора, так std::atomic::compare_exchange_weak() не вернет ошибку по причине ложного сбоя?

Если процессор x86 использовать lock при работе CAS, каков прирост производительности, если использовать свободное от блокировок программирование вместо использования std :: mutex на общем ресурсе?

Если я хочу написать свободный список заблокированных ссылок, например. Я делаю атомную нагрузку на указатель узла заголовка и сравниваю его с std::atomic::compare_exchange_weak() чтобы увидеть какие-либо изменения были сделаны. В этом случае применяется проблема ABA на процессоре x86?

2

c++cas lock-free multithreading

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

У вас есть несколько вопросов здесь 🙂

Операция CAS всегда атомарна по определению. Сказав это, зависит от вашего оборудования, какие (если таковые имеются) поддерживаются операции CAS, включая максимальное количество байтов, которые можно поменять местами для такой операции. Некоторые процессоры (например, ARM) напрямую не поддерживают CAS. Процессоры x86-64 поддерживают 8-байтовый CAS, и все современные также поддерживают 16-байтовый CAS (обычно называемый CAS двойной ширины) через CMPXCHG16b инструкция.
Я не уверен, что CAS может внезапно выйти из строя на упомянутых вами процессорах (хотя я знаю, что на некоторых платформах это не так). Я не знаю достаточно об архитектуре кеша на этих конкретных процессорах. Однако базовая аппаратная реализация не имеет значения при выборе между compare_exchange_weak а также compare_exchange_strong: вы должны использовать тот, который имеет смысл для того, что вы делаете, — слабый обмен, если вы просто пишете типичный небольшой цикл CAS (где дополнительная работа по ложному отказу незначительна), и сильный обмен в противном случае. Это также делает ваш код более переносимым и надежным.
Вам нужно измерить. Это почти полностью зависит от того, что делает ваше приложение (и если ваше приложение действительно ограничено из-за чрезвычайно высокой конкуренции за общие ресурсы, оно может выиграть от редизайна, который в первую очередь требует меньшего количества общего доступа). В общем std::mutex является «достаточно хорошим» (на самом деле довольно производительным большую часть времени), но если у вас есть очень небольшие объемы работы внутри блокировки в условиях высокой конкуренции, издержки блокировки действительно могут затмить объем фактической работы, а алгоритм без блокировки может значительно увеличить пропускную способность.
ABA абсолютно относится к x86. Это проблема, которая возникает из-за фундаментальной природы самого CAS, независимо от аппаратной реализации. я написал немного об этом здесь.

Мой совет — быть очень осторожным при написании кода без блокировки. Тестирование чрезвычайно сложно, и он может работать (даже в производственном процессе) в течение многих лет, прежде чем ошибка станет видимой в некотором угловом случае (например, на немного другом оборудовании, или при использовании при других рабочих нагрузках и т. Д.). Не начинайте писать структуру данных общего назначения, такую как связанный список, потому что правильная обработка вставок и удалений — это кошмар в общем случае (по крайней мере, если ваша цель — поддерживать высокую производительность в условиях конкуренции, что как правило, потому что именно поэтому вы в конечном итоге написали структуру данных без блокировки). Вместо этого выясните, какой именно минимум операций требуется вашей конкретной прикладной логике, и реализуйте только те из них. Связанный список без блокировки, доступный только для добавления, довольно прост для написания; Благодаря возможности АБА включить удаление головы или хвоста намного, намного сложнее.

4