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

Синхронизации между потоками записи и чтения в очередь вроде пока не трубуется

Вот как технически правильно задизайнить систему пока не решил, рассматриваю пока паттерн Producer/Consumer..., есть у кого примеры желательно с кодом?

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

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

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

DШ>Привет...ищу информацию по следующей задачке, над которой ломаю голову:
DШ>есть очередь задач (формируется на основе соотвествующей таблицы в db), какой-то/какие-то компоненты могут писать в очередь,
DШ>другие компоненты читают и запускают (причем задачи должны запускаться асинхронно), должне быть некий механиз оповещения, что положена в очередь такая то задача, а также такая то обработана — кто должен отвечать за нотификацию события пока не понятно, врроде бы можно такую функцию возложить и на саму очередь (enqueue, dequeue), но в тоже время за сам факт обработки задачи отвечает соотвествующий компонент, вытащивший задачу на обработку...

Первое что пришло в голову:
Я бы добавил ввел синтетичекую сущность "Событие в очереди" которая содержит
в себе ссылку на событие и атриубут "Статус" принимающий следующие значения :
"В ожиданни обработки", "Обрабатывается".

Осн. сценарри:

Добавление события в очередь:
создается обьект типа "Событие в очереди" со статусом "В ожиданни обработки",
очередь рассылает соотв. сообщения.

Компонент берет событие из очереди для обработки:
статус соотв. обьекта "Событие в очереди"
переходт в "Обрабатывается", очередь рассылает сообщение "Началась обработка события".


Компонент завершает обработку события:
компонент посылает очереди уведомление о завершении обработки, очередь удаляет соот.
обьект "Событие в очереди", рассылает сообщение "Закончилась обработка события".

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

DШ>Привет...ищу информацию по следующей задачке, над которой ломаю голову:
DШ>есть очередь задач (формируется на основе соотвествующей таблицы в db), какой-то/какие-то компоненты могут писать в очередь,
DШ>другие компоненты читают и запускают (причем задачи должны запускаться асинхронно), должне быть некий механиз оповещения, что положена в очередь такая то задача, а также такая то обработана — кто должен отвечать за нотификацию события пока не понятно, врроде бы можно такую функцию возложить и на саму очередь (enqueue, dequeue), но в тоже время за сам факт обработки задачи отвечает соотвествующий компонент, вытащивший задачу на обработку...

DШ>Синхронизации между потоками записи и чтения в очередь вроде пока не трубуется

DШ>Вот как технически правильно задизайнить систему пока не решил, рассматриваю пока паттерн Producer/Consumer..., есть у кого примеры желательно с кодом?

Producer/Consumer + Data Polling мне кажется Вам подойдет.

More iterator fun with the producer/consumer pattern пример реализации Producer/Consumer.

В Вашем случае Вы запускаете N потоков, которые находятся в режиме ожидания. При появлении новой задачи в очереди (пока что мы говорим про очередь в памяти, а не в базе), очередной поток просыпается и начинает обрабатывать эту задачу. То есть, нотификация осуществляется самим механизмом очереди. Теперь надо как-то получить задачи. Вы можете запустить отдельный поток, который будет с определенным интервалом стучаться в базу (Data Polling) и забирать свеживе задачи. Полученные задачи будут отправляться в очередь. В худшем случае вы получите простой в размере интервала опроса базы.

[....]
P>Producer/Consumer + Data Polling мне кажется Вам подойдет.

P>More iterator fun with the producer/consumer pattern пример реализации Producer/Consumer.

интересная статья...но лично мне больше понравилась статья Joseph Albahari
http://www.albahari.com/threading/part4.html в разделе касающейся реализации producer|consumer

P>В Вашем случае Вы запускаете N потоков, которые находятся в режиме ожидания. При появлении новой задачи в очереди (пока что мы говорим про очередь в памяти, а не в базе), очередной поток просыпается и начинает обрабатывать эту задачу. То есть, нотификация осуществляется самим механизмом очереди. Теперь надо как-то получить задачи. Вы можете запустить отдельный поток, который будет с определенным интервалом стучаться в базу (Data Polling) и забирать свеживе задачи. Полученные задачи будут отправляться в очередь. В худшем случае вы получите простой в размере интервала опроса базы.