Многопоточность на основе сообщений или пул потоков для коротких и необычных действий?

Question

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

Теперь мне нужно реализовать функцию моего приложения, которая также могла быиметь собственную ветку издателя / подписчика.Единственная проблема заключается в том, что этот поток на самом деле будет выполнять очень мало работы.Ожидается, что он будет получать сообщения от издателя каждые 10 минут или около того.Когда сообщение получено, оно выполнит некоторую работу, но ничего, что должно занять более нескольких сотен миллисекунд.

Поэтому я начал задаваться вопросом, был ли на самом деле хороший выбор для спящего потока 99,9% времени.Для такого рода операций существует пул потоков, но поскольку я не могу контролировать, какой поток будут получать мои сообщения, я вынужден прибегнуть к уродливым, подверженным ошибкам блокировкам.

Мой вопрос: действительно ли этопроблема с точки зрения ресурсов, чтобы оставить поток без дела, ожидая подавляющее большинство времени?Использование общей многопоточности после использования хорошей архитектуры, основанной на сообщениях, похоже на возвращение во времени, плюс это будет единственная часть приложения с блокировками.Но я продолжаю задаваться вопросом "Я делаю что-то здесь не так?"с этой веткой.

Редактировать : спасибо всем, прочитав каждый из ваших ответов, я решил, что с другой веткой проблем не было.Мое приложение останется согласованным только с многопоточностью на основе сообщений, и если у меня действительно будет проблема с производительностью (но это не должно иметь место), я буду исследовать дальше.

Answer 1

Я бы на самом деле утверждал, что использование ThreadPool для потока, который спит большую часть времени, является плохим выбором дизайна -

Наличие одного потока в спящем режиме (или, что лучше, ожидание события) имеет очень мало накладных расходов в вашем приложении. Основным недостатком использования выделенного потока является то, что поток должен иметь свой собственный выделенный стек, поэтому вы будете использовать немного дополнительной памяти по сравнению с потоком пула потоков.

Answer 2

Звучит как идеальный сценарий для использования Task. По умолчанию они используют пул потоков, но имеют гораздо более развитый API.

Answer 3

Хотя каждое действие в PoolFiber может выполняться в отдельном потоке пула, действия для определенного PoolFiber выполняются последовательно, а не параллельно, только один поток пула за раз.

PoolFiber должен делать то, что вы ищете.

Answer 4

Разве вы не можете использовать для этого Ретланга PoolFiber? Он не поддерживается выделенным потоком, таким как ThreadFiber, но вместо этого .Net пул потоков. Это означает, что вы можете продолжать использовать ту же семантику Retlang, которую вы используете в своем приложении, не поддерживая свободный поток.

Answer 5

Вы должны рассмотреть возможность использования F #.Он отлично подходит для программирования логически однопоточных агентов без записи потоков (например, агенты могут переключаться между потоками информации о ThreadPool, но по-прежнему отвечают на сообщения сериализованным образом, и поступающее сообщение в их почтовом ящике их будит и планирует работу ThreadPool).

http://blogs.msdn.com/b/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx

Answer 6

Я бы сказал, что наличие выделенного потока для получения этих сообщений нормально.Я бы даже сказал, что это будет предпочтительный метод.Это не так, как будто вы просто создаете темы волей-неволей или что-то в этом роде.Мы говорим об одном дополнительном потоке, и он не будет потреблять много ресурсов (возможно, немного стекового пространства).Преимущество в том, что не нужно беспокоиться о дополнительной синхронизации общего состояния (помимо передачи сообщений, разумеется), на мой взгляд, превосходит недостатки.

Answer 7

Я думаю, что это в основном вопрос оптимизации.Есть ли у вашего приложения проблемы с производительностью (в частности, проблема с памятью)?Если нет, то оставьте поток без дела и сохраняйте свой код чище.Изучите другие варианты, когда у вас появится реальная причина.