Всем доброго времени суток!
Столкнулся с, как мне кажется, не тривиальной проблемой.
Суть вопроса:
Есть много тредов которые пишут в очередь сообщений (предположим 30);
И есть один тред который читает из очереди.
(проблема один писатель/много читателей но наоборот).
Понятно, что чисто статистически один тред не может справится с 30-ю, поэтому к гадалке не ходи будет переполнение очереди.
Вот и ломаю голову, как решать проблему. Такое решение как поднять кол-во читающих из очереди тредов не кажется мне елегантным, т.к. не известно на сколько подымать, кол-во пишущих тредов постоянно изменяется...
Вот я и решил обратится к "всемирному разуму". Может кто подкинет идейку?
Зарание всем благодарен.
Regards,
typhoon “Any fool can write code that a computer can understand. Good programmers write code that humans can understand”. Martin Fowler, “Refactoring: Improving the Design of Existing Code”.
Здравствуйте, typhoon777, Вы писали:
T>Всем доброго времени суток! T>Столкнулся с, как мне кажется, не тривиальной проблемой. T>Суть вопроса: T>Есть много тредов которые пишут в очередь сообщений (предположим 30); T>И есть один тред который читает из очереди. T>(проблема один писатель/много читателей но наоборот).
T>Понятно, что чисто статистически один тред не может справится с 30-ю, поэтому к гадалке не ходи будет переполнение очереди.
T>Вот и ломаю голову, как решать проблему. Такое решение как поднять кол-во читающих из очереди тредов не кажется мне елегантным, т.к. не известно на сколько подымать, кол-во пишущих тредов постоянно изменяется...
T>Вот я и решил обратится к "всемирному разуму". Может кто подкинет идейку? T>Зарание всем благодарен.
Треды разные бывают. Можно читателю поставить такой высокий приоритет, что писатели не учпеют и вздохнуть пока читатель быстро всё вычитает.
Можно пойти и с другого конца — научить писателей проверять есть ли свободное время в очереди.
Здравствуйте, typhoon777, Вы писали:
T>Всем доброго времени суток! T>Столкнулся с, как мне кажется, не тривиальной проблемой. T>Суть вопроса: T>Есть много тредов которые пишут в очередь сообщений (предположим 30); T>И есть один тред который читает из очереди. T>(проблема один писатель/много читателей но наоборот).
T>Понятно, что чисто статистически один тред не может справится с 30-ю, поэтому к гадалке не ходи будет переполнение очереди.
T>Вот и ломаю голову, как решать проблему. Такое решение как поднять кол-во читающих из очереди тредов не кажется мне елегантным, т.к. не известно на сколько подымать, кол-во пишущих тредов постоянно изменяется...
T>Вот я и решил обратится к "всемирному разуму". Может кто подкинет идейку? T>Зарание всем благодарен.
Здравствуйте, typhoon777, Вы писали:
T>Понятно, что чисто статистически один тред не может справится с 30-ю, поэтому к гадалке не ходи будет переполнение очереди.
Далеко не факт, зависит от интенсивности записи.
Могу предложить следующее решение — не давать получить управление пишущим потокам если читающий поток активен и очередь не пуста.
Здравствуйте, typhoon777, Вы писали: T>Понятно, что чисто статистически один тред не может справится с 30-ю, поэтому к гадалке не ходи будет переполнение очереди.
Ничего подобного. Статистика здесь ни о чем не говорит. Вопрос только в соотношении производительности читателей и писателей. В клинических случаях один писатель может толпу читателей забодать. Поэтому к гадалке ходить действительно не нужно.
T>Вот и ломаю голову, как решать проблему. Такое решение как поднять кол-во читающих из очереди тредов не кажется мне елегантным, т.к. не известно на сколько подымать, кол-во пишущих тредов постоянно изменяется...
Ну, есть такой параметр — "длина очереди".
С ним и нужно работать. К примеру, можно искусственно его ограничить. Это означает, что очередной писатель запишет в очередь не "мгновенно", а подождет, пока читатель выгребет очередное сообщение и освободит место.
Если скорость разгребания очереди не слишком связана с CPU (пример: отправка почты по SMTP. Основное время тратится на ожидание отправки/прихода подтверждения), то имеет смысл следить за средней длиной очереди и регулировать количество выгребающих потоков соответственно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
