Установка значения по умолчанию ssh ключевой объект

Я узнаю об async / await и столкнулся с ситуацией, когда мне нужно синхронно вызывать метод async. Как я могу это сделать?

blockquote>

Лучший ответ: нет, детали зависят от того, что такое «ситуация».

Это свойство getter / сеттер? В большинстве случаев лучше иметь асинхронные методы, чем «асинхронные свойства». (Для получения дополнительной информации см. мое сообщение в блоге о асинхронных свойствах ).

Является ли это MVVM-приложением и вы хотите выполнить привязку асинхронных данных? Затем используйте что-то вроде my NotifyTask , как описано в моей статье MSDN об асинхронной привязке данных .

Является ли это конструктором? Тогда вы, вероятно, захотите рассмотреть асинхронный заводский метод. (Для получения дополнительной информации см. Сообщение в блоге в асинхронных конструкторах ).

Почти всегда есть лучший ответ, чем делать sync-over-async.

Если это невозможно для вашей ситуации (и вы знаете это, задав здесь вопрос , описывающий ситуацию ), я бы рекомендовал просто использовать синхронный код. Асинк всего наилучшего; синхронизация полностью наилучшая. Sync-over-async не рекомендуется.

Однако существует несколько ситуаций, когда требуется синхронизация по-асинхронному. В частности, вы ограничены вызывающим кодом, чтобы вы имели синхронизацию (и не имеете абсолютно никакого способа переосмыслить или переструктурировать свой код, чтобы разрешить асинхронность), и вы имеете для вызова асинхронного кода. Это очень редкая ситуация, но время от времени она появляется.

В этом случае вам нужно будет использовать один из хаков, описанный в моей статье о brownfield async development , в частности:

• Блокировка (например, GetAwaiter().GetResult()). Обратите внимание, что это может вызвать взаимоблокировки (как я описываю в своем блоге).
• Запуск кода в потоке пула потоков (например, Task.Run(..).GetAwaiter().GetResult()). Обратите внимание, что это будет работать, только если асинхронный код может быть запущен в потоке пула потоков (т. Е. Не зависит от контекста пользовательского интерфейса или ASP.NET).
• Вложенные петли сообщений. Обратите внимание, что это будет работать, только если асинхронный код принимает только однопоточный контекст, а не специфический контекст (много UI и ASP.NET-кода ожидают определенный контекст).

Вложенные петли сообщений являются наиболее опасными из всех хаков, потому что это вызывает повторное включение . Re-entrancy чрезвычайно сложно понять, и (IMO) является причиной большинства ошибок приложений в Windows. В частности, если вы находитесь в потоке пользовательского интерфейса и блокируете рабочую очередь (ожидая завершения работы async), тогда CLR на самом деле выполняет некоторую пересылку сообщений для вас - на самом деле это будет обрабатывать некоторые сообщения Win32 из вашего кода . О, и вы не знаете, какие сообщения - когда Крис Брумме говорит: «Было бы здорово точно знать, что будет накачано? К сожалению, накачка - это черное искусство, которое находится за пределами смертного понимание. , тогда мы действительно не надеемся узнать.

Итак, когда вы блокируете это в потоке пользовательского интерфейса, вы просите о проблемах. Другая цитата из одной статьи: «Время от времени клиенты внутри или вне компании обнаруживают, что мы перекачиваем сообщения во время управляемой блокировки в STA [поток пользовательского интерфейса]. Это законная проблема, потому что они знают, что это очень сложно для написания кода, который является надежным перед лицом повторной установки ».

Да, это так. Очень сложно написать код, который является надежным в плане повторного размещения. И вложенные петли сообщений force вы должны написать код, который является надежным перед лицом повторной установки. Вот почему принятый (и наиболее востребованный) ответ на этот вопрос является чрезвычайно опасным на практике.

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

Если вы окажетесь в этом углу, я бы рекомендовал использовать что-то например Dispatcher.PushFrame для приложений WPF , зацикливание с помощью Application.DoEvents для приложений WinForm и для общего случая, мой собственный AsyncContext.Run .