Является ли асинхронное ожидание неподходящим для достижения динамического параллелизма? - PullRequest
4 голосов
/ 09 июля 2019

Я пишу сервис, который будет работать на ASP.NET Core (2.2).Работа, выполняемая в контексте запроса / ответа, сильно загружает ЦП, и нет необходимости полагаться на ввод-вывод или другие сетевые сервисы.Из-за характера выполняемой работы динамический параллелизм кажется лучшим подходом.Дело не в том, чтобы вызывать Parallel.ForEach, а в том, чтобы создавать и запускать задачи по мере необходимости.

Это фон.Что мне не удалось выяснить, так это: есть ли преимущество или недостаток в использовании асинхронного шаблона await?Я могу создавать Задачи и ждать их, используя блокирующие вызовы, такие как Task.WaitAll и Task.WaitAny, или я могу создавать Задачи и ожидать их, используя неблокирующие вызовы, такие как Task.WhenAll и Task.WhenAny.

Я видел совет на различных веб-сайтах (и особенно в книге Стивена Клири «Параллельность в C # Cookbook», глава 3.4), чтобы использовать методы Task.Wait * для достижения динамического параллелизма, но я не совсем понимаю, почему.Есть ли присущи преимущества блокирующих вызовов при динамическом параллелизме?Разве асинхронный / ожидающий подход не дает своего преимущества, освобождая вызывающую задачу, пока она ожидает завершения вызываемой задачи?

1 Ответ

1 голос
/ 09 июля 2019

Динамический параллелизм предшествует async и await, и обычно это делается в той части кода, где требуется блокировка, но вы можете await выполнить задачу, связанную с процессором, как выможет await задача, связанная с вводом / выводом.

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

...