Затраты на использование блокировок вместо атомарных

Question

Кто-нибудь знает об опубликованных тестах издержек блокировки вместо того, чтобы полагаться только на атомарные операции / встроенные функции (в многопроцессорной системе) только?

Меня особенно интересуют общие выводы, например что-то вроде «независимо от платформы, блокировка, по крайней мере, в X раз медленнее, чем внутренняя. ”(Вот почему я не могу просто сравнить себя.)

Меня интересуют прямые сравнения, напримернасколько быстрее используется

#pragma omp atomic
++x;

вместо

#pragma omp critical
++x;

(при условии, что любое другое обновление x также критично).

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

Answer 1

Я не знаю, где находятся конкретные исследования, но вряд ли вы найдете где-либо однозначный ответ «лучше замки».Это очень сильно зависит от того, как вы их используете, насколько они противоречивы и для чего вы используете примитивы.Если все, что вам нужно, это увеличивать числа, то да, вы, вероятно, обнаружите, что атомарные примитивы быстрее, чем блокировки, но если вы хотите выполнять сравнение и замену нескольких слов, или сложные обновления древовидных структур и т. Д., ВыВыясните, что код без блокировок не только намного сложнее и сложнее в отладке, но и то, что преимущества в производительности по сравнению с хорошо спроектированной реализацией на основе блокировок в лучшем случае неубедительны и едва ли стоят существенного увеличения сложности.TANSTAAFL.

Answer 2

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

Итак, старый резервный ответ на вопросы производительности поднимает своюПодумайте еще раз: измерьте их в вашей ситуации и выберите более быструю.

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

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

Answer 3

MS выполнила некоторые тесты для новых классов одновременных коллекций в .NET 4.

http://blogs.msdn.com/b/pfxteam/archive/2010/04/26/9997562.aspx

Не C / C ++, но основные принципы те же: используйте платформу CAS /блокированные операции вместо блокирования, где вы можете.

Клифф Клик также имеет некоторые тесты в своей хэш-таблице без блокировки:В этом вопросе - использование методов без блокировки против блокировки сильно зависит от алгоритма и точного варианта использования.

Answer 4

Меня особенно интересуют общие выводы, например, что-то вроде «независимо от платформы, блокировка, по крайней мере, в X раз медленнее встроенной».

Боюсь, что тамнет общего заключения, потому что эта проблема связана с атомным дизайном инструкций архитектора, расположением кэша и шиной памяти.Они могут сильно отличаться между x86 и MIPS.Вы можете сделать тест на архитекторах, которых вы можете использовать, и сравнить их.Конструкция замка может сильно повлиять на тест, поэтому даже если вы найдете отчет, вам просто не следует в это верить.