многопоточность — повышение очереди без блокировки c ++ против общей очереди
Я довольно новичок в многопоточном программировании, я просто знаю наиболее распространенную очередь Producer-Consumer-Queue.
Я использую библиотеки boost c ++ и не знаю, лучше ли использовать boost :: lockfree :: queue или класс-оболочку для std :: queue, использующей `mutex` и` condition_variable`.
Где лучше использовать структуры данных без блокировки, а где лучше использовать простую реализацию, основанную на `mutex` и` condition_variables`?
Решение
Попробуйте оба в вашем приложении, посмотрите, что работает лучше всего.
Как правило, опрос очереди без блокировки работает лучше всего, когда в очереди почти всегда есть записи, блокировка очереди работает лучше всего, когда очередь почти всегда пуста.
Недостатком блокирующих очередей является задержка, обычно порядка 2-20 мкс, из-за сигнализации ядра. Это можно смягчить, разработав систему так, чтобы работа, выполняемая потоками потребителя для каждого элемента в очереди, занимала намного больше времени, чем этот интервал.
Недостатком неблокирующих очередей является потеря ресурсов процессора и пропускной способности памяти при опросе пустой очереди. Этого можно избежать, спроектировав систему так, чтобы очередь редко была пустой.
Как уже намекали комментаторы, неблокирующая очередь является очень плохой идеей в однопроцессорных системах.
Другие решения
(Справочная)
Начиная с 1.54, вы должны знать о некоторых требованиях
- T должен иметь конструктор копирования
- T должен иметь тривиальный оператор присваивания
- Т должен иметь тривиальный деструктор
- T должен иметь конструктор копирования
- T должен иметь конструктор по умолчанию
- T должен быть копируемым
Вы также можете использовать очередь без блокировки, чтобы избежать инверсия приоритетов в приложении в реальном времени.
Например, OpenSL на Android предоставляет обратные вызовы очереди аудиобуфера в потоке с высоким приоритетом. Если этому потоку приходится ждать блокировок, удерживаемых потоком с более низким приоритетом, его высокоприоритетное планирование ничего не значит, обратные вызовы становятся нерегулярными, и вы можете начать опустошать свой аудиобуфер — что приводит к некоторым неприятным хлопающим звукам.
Решение сводится к тому, чтобы задать вопрос: «будет блокировать раздор быть проблемой для решения задачи? «
Блокировка в параллельной среде решает две разные проблемы
- правильность: убедитесь, что код действительно выполняет то, что задумано. Не допускать вмешательства других потоков.
- пропускная способность / масштабируемость: обеспечивает устойчивый высокий поток параллельных операций, проходящих через систему. Позволяют увеличить производительность системы, добавив больше ресурсов.
Эти две проблемы являются антагонистическими целями. классический подход это защитить общий структура данных с глобальные замки. Это обеспечивает 100% корректность, но предотвращает увеличение производительности и особенно уровня параллелизма выше определенной степени, поскольку общие блокировки приводят к «перегрузке трафика»
Кстати, вам нужно быть осторожным при использовании термина «блокировка свободна». Строго говоря, совместные операции никогда не могут быть свободны на 100%. Но возможно организовать сотрудничество разумно, чтобы уменьшить влияние блокирования на тех партнеров, которые действительно необходимо получить доступ к одному и тому же элементу одновременно.