Может ли async / await оставаться в тупике, если используется ConfigureAwait (false)?

Question

Согласно этой ссылке может возникнуть тупик с асинхронным / ожидающим при определенных сценариях.

Тем не менее, может ли произойти тупик, если я всегда использую ConfigureAwait(false)?

Например: task.ConfigureAwait(false).GetAwaiter().GetResult()

Вместо: task.GetAwaiter().GetResult()

Answer 1

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

Просто используйте await.Это await, который может освободить ваш текущий контекст.

Answer 2

Да, он все еще может зайти в тупик, ConfigureAwait(false) придется реализовать во всех вложенных ожиданиях, некоторые из которых вы можете не контролировать.

Лучший подход - не полагаться на него, просто не смешивать синхронные и не async вызовы, пусть Асинхронное / Ожидание распространяется.

Единственный надежный (и противоречивый) способ убедиться, что он не заблокирован (без await) - это разгрузить / Обернуть в другое задание и Wait это, или быть в структуре, которая не имеет SynchronizationContext

Answer 3

Как видно из названия, ConfigureAwait() влияет только на асинхронный await. Это не влияет на синхронные ожидания, такие как Task.Wait(), Task.Result и Task.GetAwaiter().GetResult().

ConfigureAwait(false) означает примерно «Мне все равно, какой поток кода после этого асинхронного ожидания будет возобновлен», поэтому, если исходный поток (точнее SynchronizationContext) будет заблокирован чем-то, он все равно продолжит другая нить. Но синхронное ожидание, подобное GetAwaiter().GetResult(), никогда не переключает потоки.