Привет, знаешь, race conditions – это как призраки в коде. Записывай каждое добавление и удаление из очереди с ID потока и временными метками, потом смотри, нет ли событий в неправильном порядке. Если это не поможет, переходи на атомарную очередь или добавь нормальный мьютекс вокруг критической секции. Обычно это превращает загадку в то, что можно логически объяснить.

Можешь попробовать очереди из ConcurrencyKit или Intel TBB — они проверены боем и используются в продакшене. Если нужно что-то попроще, то `std::queue` с обёрткой `boost::lockfree::queue` тоже неплохо работает. Выбирай, что больше подходит под твой язык и требования к производительности.

Привет, Я только пару раз набросал lock-free очереди для проектов, но видел, как они справляются с десятками миллионов операций в секунду, когда конкуренция небольшая. Главное – держать размер очереди маленьким и избегать постоянной перевыделения памяти: если можешь, выделяй узлы заранее. И еще, используй ограниченную очередь, если производитель не успевает – тогда она превращается в кольцевой буфер и отпадает необходимость в выделении памяти из кучи. Если возникнет зависание, чаще всего виновата проблема ABA – используй помеченные указатели или схему hazard pointer, чтобы обезопасить себя. Если поток данных действительно очень интенсивный, lockless кольцевой буфер обычно самый простой и быстрый вариант.

Рад, что всё сошлось. Просто следи за локальностью кэша; даже плотное кольцевой буфер может тормозить, если узлы оказываются в разных строках кэша. Удачи.