Я ошибку valgrind'ом нашёл, запустив memcheck в QtCreator. Иначе
когда-нибудь грохнулось бы при работе. Не повезло найти ошибку в
работе, потому что при разрушении объекта память не изменялась. Зачем "изобрать велосипед" (очереди и мьютексы), если уже имеются проверенные, работающие и устраивающие алгоритмы и структуры данных?
Проблема не в очереди, а во времени жизни объекта из очереди. Если 1000 раз в секунду будет выделяться память для структуры размером 10 кБ и заполняться всего несколько десятков байт для передачи обрабатывающей задачи, то наиболее очевидным вариантом являются "умные указатели", которые обеспечивают нормальное время жизни объекта, и при создании которых не производится заполнение всей структуры целиком (я веду речь о std::make_shared<class Test>).
При работе с классическими очередями делать 2000 раз в секунду memcpy (1000 для переноса в очередь и 1000 для вычитывания из очереди) для 10 кБ структуры при использовании десятка байт это говнокодинг. Делать 1000 разных очередей по 10 байт это тоже говнокодинг.
Обычно в ядрах RTOS есть возможности типа "блок памяти фиксированного размера", и очередь состоит из указателей на эти блоки. Если написать свой аллокатор для std::queue, то на ПК ситуация будет идентична RTOS.