Вопрос о дизайне пула потоков
У меня есть вопрос о дизайне. Я хочу, чтобы некоторая обратная связь знала, подходит ли ThreadPool для клиентской программы, я пишу.
У меня есть клиент, выполняющий как услуга обработку записей базы данных. Каждая из этих записей содержит информацию о соединении к внешним FTP-сайтам [в основном, это - очередь файлов для передачи]. Многие из них к тому же хосту, просто переместив различные файлы. Поэтому я собираю в группу их хостом. Я хочу смочь создать новый поток на хост. Я действительно не забочусь, когда передачи заканчиваются, они просто должны сделать всю работу (или попытаться сделать), им присвоили и затем завершаются, после того как они закончены, очистив все ресурсы, которые они использовали в процессе.
Я ожидаю не больше, чем 10-25 соединений, которые будут установлены. После того как очередь передачи пуста, программа будет просто ожидать, пока не будут записи в очереди снова.
Действительно ли ThreadPool является хорошим кандидатом на это, или я должен использовать другой подход?
Править: По большей части это - единственное значительное пользовательское приложение, работающее на сервере.
3 ответа
Судя по тому, что вы описали, катушка с резьбой подошла бы хорошо.
Проблемы:
Поток пула потоков не поддерживает работу вашего процесса при завершении работы. Убедитесь, что вы хотите именно такого поведения.
В более раннем чтении связывание пула потоков с долгосрочными задачами, когда приложение могло ожидать входящих соединений (например, веб-приложение), могло быть плохим. Однако похоже, что у вас работает выделенная служба Windows, поэтому я не думаю, что это проблема.
Тот факт, что вы запускаете 10 заданий в пул потоков, не означает, что он немедленно отправит 10 потоков для выполнения работы - вы делегируете решение о том, сколько потоков использовать .net и o / s.
Нет, пул потоков не подходит. Пул потоков действительно предназначен для «коротких задач, требующих фоновой обработки», поскольку структура зависит от доступности потоков пула потоков, а длительные процессы могут исчерпать пул потоков.
FTP-переводы занимают относительно много времени (даже с разумным тайм-аутом), поэтому они не подходят. Вы можете обойтись, используя пул потоков, но вы также можете столкнуться с необъяснимыми ошибками, если используете его. Это зависит от того, насколько ваше приложение использует функции фреймворка, зависящие от пула потоков (асинхронные делегаты и т. Д.).
В теме MSDN « Управляемый пул потоков » предлагаются хорошие рекомендации, когда не использовать потоки пула потоков:
Существует несколько сценариев, в которых целесообразно создать и управлять своими собственными потоками вместо использования потоков пула потоков:
- Вам нужен поток переднего плана.
- Вам требуется, чтобы у потока был определенный приоритет.
- У вас есть задачи, которые вызывают блокировку потока на длительные периоды времени. В пул потоков имеет максимальное количество потоков, поэтому большое количество заблокированных потоки пула потоков могут помешать задачи с момента запуска.
- Вам нужно поместить потоки в однопоточную квартиру. Все Потоки ThreadPool находятся в многопоточная квартира.
- У вас должна быть стабильная идентификация, связанная с потоком, или чтобы посвятить ветку задаче.
ThreadPool было бы неплохо, поскольку он позволяет вам сконцентрироваться на настройке заданий, помещенных в очередь для потоков, вместо того, чтобы беспокоиться об инициализации и очистке отдельных потоков.
Но как вы хотите, чтобы это работало? Собираетесь ли вы поставить в очередь несколько заданий в пул для хоста или у вас будет поток для каждого хоста, который считывает задания из своей собственной очереди?