LINUX.ORG.RU
Форум — Development  

планировщик ввода-вывода на с/с++


0

0

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

* есть фифо в виде темплейта, параметрами коей являются тип хранимых данных, индексный тип (для счётчиков/размеров), операция смещения (functor), data storage, block states. Фифо непростая, иначе бы не стал её делать, хранит данные блоками произвольной длины (кратной типу), причём каждый блок может увеличиваться в несколько приёмов, для чего и нужна операция смещения, чтобы сместить блок, если он вылез за верхнюю границу буфера (буфер тоже разный мб - сплошной кусок или порезанный на равные куски). Выделение/освобождение блоков - операция конкурентная и может выполняться в разных тредах/процессах одновременно, по сути получился template-конструктор, подставляя разные параметры в который получается фифо для разных типов данных/хранилищ данных/синхро-примитивов. Реализовал для тредов (pthreads/boost::thread), UNIX processes, зашла речь об distributed fifo, вот тут и возник сабж.

* описанние фифо помещено для понимания, что хотелось бы написать интерфейс для "слейва ввода-вывода" подобный вышеописанному темплейту, параметрами которого дб коротенькие (как и в случае фифо) классы (тем не менее содержащие весь необходимый функционал), реализующие конкретный специфичный случай, например: асинхронный ввод-вывод в том же треде (когда слейв как dedicated поток управления отсутствует), или в slave треде/процессе, балансировка нагрузки если несколько разных фифо обслуживаются одним IO slave, фифо дублируемое на mirror hosts и тд. Изучаю разный софт по теме: http://www.monkey.org/~provos/libevent/, http://liboop.ofb.net/. Конкретные реализации main loop'ов мне мало интересны, хотелось бы иметь легко адаптируемый под конкретную задачу подход.

хотелось бы услышать какие-нибудь (желательно ценные :) ) идеи по такому интерфейсу

ЗЫ повторю: замечания вроде "вот ссылка на проект N c планировщиком M" мне не интересны, интересны идеи (или ссылки на них) интерфейса, в который, например, легко интегрируется любой планировщик или интерфейс ввода-вывода.

ЗЗЫ идеи "жирных" интерфейсов (под каждый конкретный случай своя реализация) идут лесом, нужен конструктор.

★★

Прочитал три раза и все равно не понимаю. Почему одновременно и "ФИФО", и "планировщик ввода/вывода"? Если есть ФИФО, то все действия делаются последовательно, и планировать нечего? Или там этих ФИФО много? Можешь интерфейс к одному фифо привести? И что от шедулера ожидают, какую дисциплину обслуживания? любую/"справедливую"/еще-какую?

anyway, в список "софта по теме" я бы добавил ACE: http://www.cs.wustl.edu/~schmidt/ACE.html Оно вроде больше делает чем libevent и liboop.

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy

фифо к тому, что это в данном контексте не алгоритм планировщика (сорри если запутал), а структура через которую потоки управления обмениваются данными, я её описал к тому, чтобы пояснить, как хотелось бы реализовать ввод-вывод. К асе до кучи можно добавить корбо и исе и ещё много чего, фишка в том, что хотелось бы написать интерфейс, на который без проблем ложится и асе и исе и корбо и селект со товарищами и ангел с нимбом и чёрт с рогами и копытами. Завуалированная суть вопроса была в том, не делал ли кто анализ совместимости этих вещей, общие черты и различия (про падших ангелов я в курсе). Без такого анализа разговор на тему интерфейса, допускающего безболезненную адаптацию на любой event-driven framework бессмысленен.

filin ★★
() автор топика
Ответ на: комментарий от filin

" структура через которую потоки управления обмениваются данными " - по всей видимости это т.н. ОпСервер (OpServer c++ idiome). Тобишь сокет, умеющий последовательно выполнять функции, подписанные на него. Такая абстрация реализована в библиотеке BOOST\SIGNALS (www.boost.org), если компилятор твой с ней справится. или можешь аналогичную свою либу зафигачить. Я представляю ЭТО так:

class Менджер_потоков { ... void ВЫПОЛНИТЬ_ХЭНДЛЕРЫ_ПОДПИСЧИКОВ([параметры]);

public: Тип_соединение ПОДПИСАТЬ_ПОТОК( Тип_поток& ); Тип_соединение ОТПИСАТЬ_ПОТОК( Тип_соединение );

};

лично я использовал подобное в Билдере, например, чтобы динамически добовлять код к VCL событиям.

anonymous
()
Ответ на: комментарий от filin

>структура через которую потоки управления обмениваются данными

Может стоить использовать что-то в этом роде template <class F> class AbstructSocket

{

.....

std::list<F> handlersList_; - список подписчиков

...

typedef ... Conection; - тип-соединение. Содержит данные, достаточные для выполнения функции-члена Disconect( Conection conection );

public:

Conection Subscribe(F handler); // подписать хендлера

bool Disconect( Conection conection ); // отписать соединение

template< типы аргументов > SetSignal( аргументы... ); // соответсвенно, выполнить все подписанные хендлеры

};

Здесь шаблонный параметр F - сущьность, имеющая

1)оператор вызова () с соответсвующей сигнатурой

2) семантику первого класса

Подойдет функция, указатель на функцию, класс-функтор, патерн Loki::Functor.

Моё дело подать идею, уточнение секции public и реализация за тобой.

binf
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development