Средства и методы разработки

Проще поставить дескриптор рекорда (задание на транзакцию) в очередь и подождать флага окончания записи, занимаясь другими делами. Ведь процессу важно не рулить буфером, о котором ему по-хорошему вообще знать не нужно (не его это дело), а приготовить данные и записать. Если данные приготовлены, то некий буфер данных (рекорд) процесса всё-равно должен быть блокирован пока он не перегрузился в буфер (обсуждаемый). Но в этом случае буфер это всего-лишь FIFO устройства асинхронного вывода - его вообще может не быть. А если есть этот буфер и достаточной длины, то очередь заданий быстро разгрузится в него и никто ничего не заметит. И всё прямоугольно, и адекватно оценивается по ресурсоемкости - знаешь максимальную интенсивность потока записей (в единицах записи) - знаешь какой буфер может понадобиться дабы было незаметно - если не получается прозрачно, значит флаг окончания записи нужно отдавать процессу и пусть разблокирует свой буферок после разрешения (окончания записи). Для всяких приоритетностей можно, например, держать N очередей и разгребалку после них ставить - тупо и неженственно;) Обычно больше буквально 4-5 приоритетов наворачивать себе дороже независимо от реализации. А 4 очереди это просто. Можно ещё добавлять более приоритетные транзакции прямо сортируя очередь, но, ИМХО, это более гиморно, потому как нужно лочить очередь, хоть и ненадолго, а правильные выгребалки работать должны быстро и не стОит их тормозить. А если не хочется процессу выделять статические буферы, то тут проще с прямыми механизмами менеджмента памяти разбираться, а не кольцевые буферы окучивать