Pull to refresh

Comments 4

«Если требуется атомарная обработка блоков данных, объёмами в несколько десятков мегабайт, то использование мьютексов было бы намного эффективнее.»
Это очень зависит от того насколько трудоёмка функция обработки данных. Если копирование намного быстрее, то скорее всего более эффективно будет скопировать и освободить указатель.
И в любом случае флажки-спинлоки в 99% случаев более эффективны нежели мьютексы.
Когда-то также интересовался этой темой. Даже написал свою реализацию lock-free очереди (GitHub, StackExchange).
Идея там простая: есть 2 потока, один пишет в очередь, другой из нее читает. Внутри очереди есть 2 подочереди — одна для писателя, другая для читателя. Когда читатель вычитывает свою подочередь, он забирает подочередь писателя, а писатель начинает новую.
В базовам варианте (один читатель, один писатель) для синхронизации используется единственная atomic переменная.
Это понятно, но в данной статье я специально не стал затрагивать тему lock-free стэков и очередей, т.к. на эту тему информации в сети можно найти сколько угодно. Тут была именно попытка реализовать что-то наподобие критических секций, без использования медленных мьютексов.
Просто как вариант.
Если гарантированно, что писатель один, а читателей сколько угодно, то см. «Non-blocking Write Protocol» в Real-Time Systems: Design Principles for Distributed Embedded Applications. Решается одной atomic переменной, как указал HaronK
Формат данных не важен (очередь, стек, и т.п. — просто блок данных)
Sign up to leave a comment.

Articles