Здравствуйте, vdimas, Вы писали:

V>·>Я просил объяснить что значит вот это: "схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть". Я просил пояснить какая именно "схема из двух очередней", альтернативная кольцевому буферу является "правльной"?
V>Ты не можешь НИЧЕГО тут спрашивать до тех пор, пока не поймешь принципы работы кольцевого буфера.
V>Тебе ведь всё еще кажется, что продюссеры и консюмеры бегают по кругу по памяти (потому что такова реализация на основе массива фиксированного размера). Но по семантике продюсеры и консюмеры стоят на месте — это просто два разных процесса (потока), а м/у ними бегают навстречу друг другу пустые и полные ячейки памяти (элементы).
Какая разница? Движение относительно.

V>·>И с какого бодуна кольцевой буфер это внезапно "две очереди"?
V>Потому что две очереди образуют структуру данных "Circular Linked List" с такой же точно семантикой.
Неправда, ты опять толком не разобрался. Кольцевой буфер это вполне конктреная имплементация очереди. Ознакомься хотя бы с вики https://en.wikipedia.org/wiki/Circular_buffer

A circular buffer, circular queue, cyclic buffer or ring buffer is a data structure that uses a single, fixed-size buffer as if it were connected end-to-end

V>·>А как реализованы эти очереди-то?
V>Linked List.
Это слишком теоретично и абстрактно. Вспомни-ка, что для linked list нужна динамическая память, а значит менеджер памяти, который сам по себе некая структура данных. Может в обычном приложении это не имеет значение, т.к. менеджер памяти это некий такой абстрактный всемогутер, работающий нулевое время, но когда рассуждаешь в терминах LL надо сразу говорить как это ляжет на конкретное железо. Как как этот самый linked list будет реализован на обычном железе с его кешами, многопоточной обработкой, постраничным доступом, prefetch-ем етс?

V>·>У тебя причина со следствием перепутаны. Ветер дует потому что деревья качаются. Кольцевой буфер это и есть реализация очереди, притом _одной_ очереди
V>"Одной очереди"?
V>Ты действительно не понимаешь или троллишь, я чего-то понять не могу? )))
Я использую общепринятую терминологию, я тебе уже несколько ссылок послал именно с таким пониманием. Зачем ты настаиваешь на своей странной интерпретации понятий?

V>Когда Читатель не справляется, мы вынуждены блокировать Писателя, верно?
Вариантов много. Можно отреджектить, можно заблокировать, можно дропать, можно динамически отресайзить.

V>А почему, не понял еще? )) Потому что его очередью является очередь пустых элементов, и эта очередь пуста.
V>Так вот, в случае реализации такой же схемы на "Circular Linked List", если очередь пустых элементов пуста, то мы можем легко добавить новый пустой элемент, выделив его из памяти.
Проблема linked list что он не очень friendly к железу. Создаёт лишние индирекции и требует хитрого менеджера памяти.

Здравствуйте, vdimas, Вы писали:

V>·>Я просил объяснить что значит вот это: "схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть". Я просил пояснить какая именно "схема из двух очередней", альтернативная кольцевому буферу является "правльной"?
V>Ты не можешь НИЧЕГО тут спрашивать до тех пор, пока не поймешь принципы работы кольцевого буфера.
V>Тебе ведь всё еще кажется, что продюссеры и консюмеры бегают по кругу по памяти (потому что такова реализация на основе массива фиксированного размера). Но по семантике продюсеры и консюмеры стоят на месте — это просто два разных процесса (потока), а м/у ними бегают навстречу друг другу пустые и полные ячейки памяти (элементы).
Какая разница? Движение относительно.

V>·>И с какого бодуна кольцевой буфер это внезапно "две очереди"?
V>Потому что две очереди образуют структуру данных "Circular Linked List" с такой же точно семантикой.
Неправда, ты опять толком не разобрался. Кольцевой буфер это вполне конктреная имплементация очереди. Ознакомься хотя бы с вики https://en.wikipedia.org/wiki/Circular_buffer

A circular buffer, circular queue, cyclic buffer or ring buffer is a data structure that uses a single, fixed-size buffer as if it were connected end-to-end

V>·>А как реализованы эти очереди-то?
V>Linked List.
Это слишком теоретично и абстрактно. Вспомни-ка, что для linked list нужна динамическая память, а значит менеджер памяти, который сам по себе некая структура данных. Может в обычном приложении это не имеет значение, т.к. менеджер памяти это некий такой абстрактный всемогутер, работающий нулевое время, но когда рассуждаешь в терминах LL надо сразу говорить как это ляжет на конкретное железо. Как как этот самый linked list будет реализован на обычном железе с его кешами, многопоточной обработкой, постраничным доступом, prefetch-ем етс?

V>·>У тебя причина со следствием перепутаны. Ветер дует потому что деревья качаются. Кольцевой буфер это и есть реализация очереди, притом _одной_ очереди
V>"Одной очереди"?
V>Ты действительно не понимаешь или троллишь, я чего-то понять не могу? )))
Я использую общепринятую терминологию, я тебе уже несколько ссылок послал именно с таким пониманием. Зачем ты настаиваешь на своей странной интерпретации понятий?

V>Когда Читатель не справляется, мы вынуждены блокировать Писателя, верно?
Вариантов много. Можно отреджектить, можно заблокировать, можно дропать, можно динамически отресайзить.

V>А почему, не понял еще? )) Потому что его очередью является очередь пустых элементов, и эта очередь пуста.
V>Так вот, в случае реализации такой же схемы на "Circular Linked List", если очередь пустых элементов пуста, то мы можем легко добавить новый пустой элемент, выделив его из памяти.
Проблема linked list что он не очень friendly к железу. Создаёт лишние индирекции и требует хитрого менеджера памяти.
Кстати, размер памяти тоже таки fixed size, что делать если память закончится? Так что этот твой подход полезен в случае приложения с множеством таких очередей, между которыми будет перераспределяться свободная память.
В случае LL-системы там таких буферов немного, и их количество фиксированно. Поэтому проще просто выделить нужные объёмы памяти под каждый и не надеяться на то что менеджер всегда может предоставить любой объём памяти.