Выполнение "асинхронного" кода на нескольких ядрах

Вопрос таков:

Насколько мне известно, код использующий Begin*/End* на самом деле не выполняется на нескольких ядрах, а только на одном (т.е. максимальная загрузка ЦП, если процессор имеет 4 ядра - 25%).

Хотелось бы узнать, как вы с этим боритесь. Интересно то, что если создать как минимум 4 обычных Thread, и запустить в них бесконечный цикл (разумеется, без всяких там Thread.Sleep), то загрузка ЦП будет вполне себе достигать 100%.

Речь, в основном, идет о коде сетевых приложений (серверах).

0

Все просто - TPL

1

Спасибо, freeba, но меня больше интересует как это делается более сложными способами (как говорится, как под капотом).

0

Под капотом те же Thread из ThreadPool. В любом случае реализацию никто не мешает посмотреть - исходники открыты. По крайней мере для .NET Core.

0

Сообщение от jahtemg (как говорится, как под капотом

Тогда уточните, что вам требуется - параллельность данных или параллельность задач. В зависимости от цели используются разные приемы.

0

Конкретная, хоть и надуманая задача:

Нужно сделать сервер (эмулятор) онлайн игры (мморпг).

Есть класс, отвечающий за храниение хэндлеров пакетов (классика, ushort опкод и делегат, собственно на метод-обработчик логики).

Дело в том, что обрабатывать всё это желательно сразу на нескольких ядрах, т.к. есть некоторая возможность, что сервер будет жрать весьма значитальное количество ресурсов ЦП (разумеется, не только ЦП).

Допустим, у нас есть контекст клиента (сессия), который использует BeginReceive/EndReceive/BeginSend/EndSend. Из EndReceive (то что получено сервером от игрового клиента) мы вызываем метод в классе, который хранит делегаты на методы-обработчики, допустим,

Затем, просто вызываем обработчик

Естественно, все обработчики будут выполнятся на одном ядре, как я и писал выше. А это значит, что если метод-обработчик весьма ресурсоемок, то результат - высокая нагрузка на 1 ядро ЦП (допустим, аж 25%), а этого, теоретически, может быть и недостаточно для поддержания геймплея без задержек.


Мои вариант:
Запустить некоторое количество потоков, из которых запускать контексты клиента. Разумеется, с синхронизацией нужно будет изрядно помахаться...

Собственно, как вы бы решили эту проблему ?

0

jahtemg, Элементарная задача. Вешаем асинхронный обработчик запросов, т.е. каждый запрос будет обрабатываться в отдельном таске, а для синхронизации хватит обычного ConcurrentDictionary. Таким образом за нагрузку на ядра будет отвечать TPL.

0

Меня интересуют именно варианты решения задачи без TPL.

0

jahtemg, а какая разница? Вместо тасков можно треды создавать - принцип один.

0

Собственно, мой вариант - верный ? ConcurrentDictionary для синхронизации ? Может вы имели в виду ConcurrentQueue ?

0

Сообщение от jahtemg Собственно, мой вариант - верный ? ConcurrentDictionary для синхронизации ? Может вы имели в виду ConcurrentQueue ?

Эм, плохо представляю как приспособить очередь под хранение сессии.

Набросал пример с асинхронным сервером, разница между использованием тасков и потоков для обработки - одна строка.
Производительность примерно одинаковая, но микрософт уже давно рекомендует использовать TPL.

PS: Это тестовый пример - в боевых условиях, сокеты не переподключаются на каждый запрос.

Вложения

CF.Test.7z (36.3 Кб, 5 просмотров)

0

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

Про ConcurrentQueue - я имел в виду то, что можно принятые подключения добавлять в очередь (SessionWorkItem) и затем оттуда вытягивать и запускать в одном из предварительно созданных потоках (вполне типичный producer-consumer?).

0

А зачем? На MSDN рекомендуют не сильно увлекаться ручной установкой ограничений.

Пул потоков предоставляет новые рабочие потоки или потоки завершения ввода-вывода по запросу, пока не будет достигнут минимум для каждой категории. При достижении минимума пул потоков может создавать дополнительные потоки в этой категории или ожидать завершения некоторых задач. Начиная с .NET Framework 4 пул потоков создает и уничтожает рабочие потоки в целях оптимизации пропускной способности, которая определяется как количество задач, завершаемых за единицу времени. Слишком малое количество потоков может препятствовать оптимальному использованию доступных ресурсов, тогда как слишком большое их количество может усиливать конкуренцию за ресурсы. Можно использовать SetMinThreads метод для увеличения минимального количества потоков. Однако необоснованное увеличение этих значений может привести к снижению производительности. Если одновременно запускается слишком много задач, все они могут выполняться слишком медленно. В большинстве случаев пул потоков работает наилучшим образом, если он использует собственный алгоритм выделения потоков.

Сообщение от jahtemg Про ConcurrentQueue - я имел в виду то, что можно принятые подключения добавлять в очередь (SessionWorkItem) и затем оттуда вытягивать и запускать в одном из предварительно созданных потоках (вполне типичный producer-consumer?).

Принятые подключения проще заносить в список и вешать event отслеживающий поступление данных. Как только данные поступили - их сразу на обработку в пул потоков. Вроде так проще.

0