Есть сетевое приложение, где нужно развязать сетевую часть и бизнес-логику через общий буфер, в который сетевая часть пишет и берет своё, а бизнес-логика своё. Ходят слухи, что для этого используют паттерн disruptor.  Мне он тоже кажется подходящей кандидатурой, но хочется уточнить некоторые моменты.
Здесь буффер дисраптора описан состоящим из слотов или entry. Дальнейшее изучение (пока по диагонали правда) явовской оригинальной версии дисраптора показало, что в качестве слота используется либо указатель, либо простая структура (та самая entry), имеющая члены-указатели на данные и/или различные флаги. Т.о. если я использую boost::asio, в startRead() я должен выделить необходимое количество памяти, передать его в async_read_X, затем в handleRead() я должен запросить у disruptor'а свободный слот и присвоить указатель на ранее выделенный буфер одному из полей этого слота и затем закоммиттить полученный слот. Далее опять выделение памяти и по новой?. 
Т.е. как я понял, я не могу:
а) использовать в качестве слота char
б) в startRead() попросить disruptor выделить из своего внутреннего буфера свободное место (как boost::asio::buffer(), for example), чтобы я мог его передать в async_read_X без выделения памяти каждый раз?
в) в handleRead просто закомиттить запрошеный слот (если произойдет сбой, то испорченный слот можно закомиттить испорченным и потребители его просто проигнорируют)? 

Просвятите, пожалуйста, насчет такой возможности.

мне показалось что ты изучаешь жава реализацию дисраптора. если да, то плюсовая реализация тут: http://code.google.com/p/disruptor-cpp/


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

Добавлено @ 14:55
не уверен что понял вопрос..по этому и ответ получился какой-то сумбурный =)

Это сообщение отредактировал(а) boostcoder - 28.11.2011, 15:24

Явовскую реализацию я смотрел, т.к. плюсовая ссылается на ее документацию. Но за ссылку все равно спасибо.
Ответ как раз то, что нужно. =) 
Просто я в самом начале попытался реализовать свой простой disruptor как массив байтов (circular_buffer<char>) - вырожденный вариант Entry, вроде как память экономить - и в итоге такая хня получилась возникли сложности в управлении памятью - нужны уже непростые алгоритмы, либо Entry делать как массив байтов, но тогда возможен перерасход памяти. Деваться некуда стало, пришлось подробнее читать про оригинал, ряд вопрос снялся. Но  решил еще уточнить у знающих людей. Уже задав вопрос здесь пришел к выводу, что оптимально будет сделать  в Entry указатели, а память выделять из предварительно выделенного глобального буфера - собственно о том же и ответ.
Т.о. правильнее будет просто прописать размер типового буфера в Entry как настройку приложения и переложить проблему баланса между быстродействием и расходом памяти с плеч программиста на плечи администратора приложения - пусть он сам подбирает необходимый ему размер буфера?
Пойду дальше курить disruptor.

да. ну можно таки еще и про пул буферов/объектов подумать. что-то типа boost.pool.

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

Теперь по теме - благодарю за ссылку, уже изучаю.