Есть главный поток приложения. Дополнительно создается служебный поток, который по аппаратно генерируемому событию просыпается и обрабатывает свежепоступившие данные. После обработки служебный поток должен сохранить данные в какую то структуру/массив (пока что используется STLный vector).

Время обработки данных в служебном потоке ограничено 40 миллисекундами, т.е. служебный поток должен хватать данные и обрабатывать в риал-тайме и он не имеет право пропускать данные. С этим проблем нет, но поступающими данными пользуется главный поток приложения.
Главный поток также осуществляет дальнейшую обработку всего массива полученных данных. Главный поток не критичен по времени и для него допустимы любые задержки обработки вплоть до секунды.

Вопрос: каким образом изящно обеспечить конкурентный доступ к массиву поступающих данных не имея возможности его надолго блокировать ?

Все что мне лезет на ум: блокировать массив, копировать нужный кусок данных и мигом его разблокировать, чтобы служебный поток имел время на добавление данных.

Буду очень признателен за совет.

служебный поток под вновьпоступившие данные выделяет память, после обработки он сообщает адрес буфера главному потоку и забывает об этом буфере. сохранение данных в массив/структуру для обработки главным потоком и освобождение памяти ложаться на главный поток (или еще один поток, который и будет заниматься только этим). а поток-получатель данных только выделяет память и набивает ее данными и не ждет никого

Спасибо за совет. Как раз процедура обработки в главном потоке специально заточена под поступление чанков из нного количества сэмплов.

Есть еще одно осложнение: служебный поток работает на двух изображениях 768x576 и в зависимости режима работы главного потока эти изображения нужно выводить в то или иное окно.
Сэмплы после обработки изображений занимают копейки, но под изображения выделять память и освобождать ее в темпе 25 двойных кадров в секунду как то не очень...выделение памяти на куче - операция не очень быстрая.

Наверное в главном потоке нужно сделать один раз выделяемый буффер и копировать каждый раз туда, затем уведомлять об обновлении. Тем более главный поток имеет право пропускать вывод кадров в окна, если это необходимо.

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

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