Qt

Т.е. QLinkedList не только потокобезопасен, но и не использует примитивы синхронизации?

А разве кьютовские контейнеры потокобезопасны вообще? Я думал, что нет.

Не знаю, я просто сказал первое, что пришло в голову

The container classes are implicitly shared, they are reentrant, and they are optimized for speed, low memory consumption, and minimal inline code expansion, resulting in smaller executables. In addition, they are thread-safe in situations where they are used as read-only containers by all threads used to access them.

Я использовал. Была одна задачка, где производительность сильно проседала на переключениях контекста процесс/ядро. Замена обычной очереди на неблокирующую помогла, боттлнек рассосался.

In addition, they are thread-safe in situations where they are used as read-only containers by all threads used to access them.

Это ещё надо постараться, чтоб сделать контейнер, не являющийся каким-нибудь кешем, непотокобезопасным, когда все только читают.

Самопальная очередь или из либы какой?

Самопальная, по статье.

у неблокирующихся контейнеров разложены одни грабли...

...приходится использовать нечто вроде сборщика мусора, что может привести либо к неумеренному потреблению памяти, либо к тормозам. собственно, это свойственно всем сборщикам мусора.

дополню сам себя: при нормальном расположении колец сатурна (что встречается в реальных задачах довольно часто) рвёт блокирующиеся аналоги экспоненциально с ростом конкурентности.

Сам ещё не пробовал, но есть cишная либа ConcurrencyKit.

И ещё на rsdn remark много чего писал по поводу lock-free.

boost::lockfree, tbb, но я бы посоветовал использовать стандартные с блокировками, т.к. lockfree реализации только развиваются и граблей полно, если ты четко не знаешь как оно работает, то не стоит даже пытаться.

Профит офигительный, это очевидно. На практике дальше кольцевого буфера редко приходится залезать.

Профит офигительный, это очевидно

Не совсем очевидно, потому что реализация может нести существенный оверхед. Бывает, что используют GC и избыточное выделение/копирование памяти. Смотря какая структура данных реализуется.

Друг использует для телекома, но только на Си. Говорит, что польза есть. Там у них в телекоме это сразу проявляется, поскольку рилтайм, высокая нагрузка, все такое.

Не совсем очевидно, потому что реализация может нести существенный оверхед.

Ну это смотря какой конкретный случай. Ряд структур реализовывать lock-free не стоит, т.к. проще становится просто перейти на другие и в целом выиграть.

Бывает, что используют GC и избыточное выделение/копирование памяти. Смотря какая структура данных реализуется.

Выделение памяти очень сомнительно для lock-free, т.к. избавляясь от блокировок, ты начинаешь терять на управлении памятью, где затуп дает эффект, эквивалентный блокировкам. Я бы просто не называл алгоритмы использованием с управления памятью «lock-free».

http://www.1024cores.net/