Я и имел ввиду, именно, входные. Например, файл пишется чанками по 10 МБ, а FFT обрабатывает 100 КБ.

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

Для простоты допустим емкость кольцевого буфера всего 10 точек, как Вы возьмете для отрисовки напр 5 последних?

последних пришедших/считанных

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

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

Что-то похожее я давненько реализовывал. 
Все выкрутасы с общим буфером у блокировками между писателями и читателями оказались для меня тормозными.
В конце концов пришел к схеме с разными буферами.

Один поток читает данные и отправляет через очередь сообщений потребителям.
Каждый потребитель находится в своем потоке, собирает данные, формирует свой буфер и следит за ним, обрабатывает данные - отображает или записывает.

Так у меня работает быстрее.

Мне кажется можно сделать проще, без прыжков и столь же lock-free

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

- потребитель знает "свой" блок данных и маркирует его готовым если данные больше не нужны, затем берет новый блок продвигаясь от хвоста к голове. Если прибыло много новых блоков, потребитель может маркировать 2 и более и взять последний. Хвост подсекается когда маркирован всеми потребителями

В принципе это можно делать с любым контейнером, при нормальном размере блока блокировки не страшны. Если хочется lock-free то просто свой двухсвязный список + атомарный счетчик блоков (хотя вероятно и QLinkedList подойдет).

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