Плохо ли открывать слишком много потоков в приложении?

Question

У меня есть приложение на C # winform. это имеет много форм с различными функциями. Эти формы переносятся в службу WCF. например

form1 постоянно вызывает serviceMethod1 и обновляет результаты

form2 постоянно вызывает serviceMethod2 и обновляет результаты

Вызовы выполняются в разных потоках для каждой формы, но это заканчивается слишком большим количеством потоков, поскольку у нас много форм. Это плохо и почему? и есть ли способ избежать этого, учитывая мой сценарий?

Привет

Answer 1

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

Одной альтернативой может быть использование Timer, хотя (звучит как System.Timers.Timer или System.Threading.Timer было бы наиболее подходящим) - планировать каждый вызов службы, производится на регулярной основе, и таймер будет использовать пул потоков для запуска вызовов. Я подозреваю, что, хотя вы говорите, что звоните в сервисы «постоянно», на самом деле вы имеете в виду, что делаете это регулярно - именно для такой ситуации и подходит таймер.

Answer 2

Вы можете использовать асинхронный прокси WCF

В Visual Studio, когда вы добавляете веб-ссылку, вы можете установить флажок «Генерировать асинхронные операции», чтобы создать асинхронный прокси.

Answer 3

Если честно ответить на вопрос: это полностью зависит от ОС и дизайна приложения, но этот вопрос может указывать на недостаток в дизайне программы.

Деталь: Вы хотите узнать требования к выделению потока в вашей целевой архитектуре / ОС, а также сохранить свои потоки относительно занятыми / избегать опроса и правильно настроить приоритеты, если у вас действительно много потоков. «Многих» потоков может быть 8 (или меньше, если они заняты) или 100+, если у них относительно мало работы, в конечном итоге это зависит от ваших потребностей и дизайна.

В качестве тестов для некоторых тестов / объектов / операций я использовал более 100, а иногда и более 1000 рабочих потоков. Никаких взрывов не произошло, хотя у меня никогда не было реальной необходимости , чтобы эти операции были , а параллельными в приложении доставки (если только вышеупомянутые программы не используются в очень необычных обстоятельствах), имело больше смысла помещать фактическую реализацию в некоторый централизованный диспетчер задач. Если у вас есть приложения, критичные ко времени / в реальном времени, то эти задачи могут быть лучше в другом потоке. Если они недолговечны, рассмотрим пул потоков ... ну, есть много способов атаковать многие проблемные классы ...

Answer 4

С зелеными нитями это не проблема. Зеленые потоки являются своего рода виртуальными потоками, что вы обычно получаете с Java и C #.

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

Answer 5

Как правило, вы не получите ничего, имея больше потоков, чем у вас ядер ЦП. Из общего правила есть исключения, но я сомневаюсь, что они применимы к вашему делу.

С точки зрения ОС, потоки больше не являются легкими, какими они были раньше, а стоят почти так же дорого, как и полные процессы. Правильная реализация синхронизации потоков - непростая задача, отладка многопоточных приложений намного сложнее, чем однопоточных.

Answer 6

Хотя потоки проводят большую часть своего времени в ожидании ответа сервера - даже сотни потоков вряд ли снизят производительность (с точки зрения использования процессора). В противном случае используйте пул потоков и ставите в очередь задачи «запросить и обновить форму один раз» после завершения предыдущего обновления.

Более важной проблемой может быть загрузка службы с большим количеством одновременных запросов.