ThreadPool и методы с циклами while (true)?

Question

ThreadPool и методы с циклами while (true)?

1

ThreadPool использует переработку потоков для оптимальной производительности, используя несколько классов Thread. Однако как это применимо к методам обработки с циклами while внутри ThreadPool?

В качестве примера, если бы мы применили поток в ThreadPool к клиенту, подключенному к TCP-серверу, этому клиенту понадобился бы цикл while для проверки входящих данных. Цикл может быть отключен для отключения клиента, но только если сервер закрывается или клиент требует отключения.

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

С другой стороны мне было предложено использовать асинхронные методы Network.BeginReceive и NetworkStream.EndReceive, чтобы избежать одновременного объединения потоков для экономии использования ОЗУ и использования ЦП. Это правда или нет?

user3519915 15 май 2014, в 23:41

Источник

Теги:

c#

multithreading

network-programming

2 ответа

3

В любом случае один и тот же объем памяти используется, если клиенты остаются подключенными.

Пока это правда. Это зависит от вашего приложения, чтобы определить, какое состояние он должен поддерживать для каждого клиента.

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

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

С другой стороны мне было предложено использовать асинхронные методы Network.BeginReceive и NetworkStream.EndReceive, чтобы избежать одновременного объединения потоков для экономии использования ОЗУ и использования ЦП. Это правда или нет?

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

Jon 15 май 2014, в 19:24

Ещё вопросы

DBK · Accepted Answer · 2014-05-15T20-51-00.000Z

Ты прав. Медленные блокирующие коды могут вызывать слабые характеристики как на стороне клиента, так и на стороне сервера. Вы можете запускать медленную работу в отдельном потоке, и это может работать достаточно хорошо на стороне клиента, но может не помочь на стороне сервера. Наличие методов блокировки на сервере может снизить общую производительность сервера, поскольку это может привести к ситуации, когда на вашем сервере нет большого количества потоков, и все блокируются. Таким образом, даже простой запрос может занять много времени. Лучше использовать асинхронные API-интерфейсы, если они доступны для задач с медленным запуском, точно так же, как и в ситуации, в которой вы находитесь. (Обратите внимание: даже если асинхронные операции недоступны, вы можете реализовать их путем реализации пользовательского класса awaiter). Это лучше для клиентов, а также серверов. Основной асинхронный код - уменьшить количество потоков. Поскольку серверы могут иметь большее количество запросов одновременно, потому что уменьшение количества потоков для обработки конкретного клиента не позволяет повысить масштабируемость.

Если вам не нужно больше контролировать потоки или пул потоков, вы можете пойти с асинхронным подходом.

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

Ваш сервер имеет большое количество запущенных потоков, и все они заблокированы. Таким образом, даже простой запрос может занять много времени »- что ??
Зависит от того, как вы определяете «заблокирован». Если вы говорите о NoDelay для TcpClient, я установил значение true, чтобы избежать блокировки.
Блокировка - любая длительная операция
Запросы не должны занимать много времени, хотя использование памяти будет стремительно расти. С 1024 клиентов будет ГБ памяти.