Kann ich Task.Wait sicher verwenden, wenn SynchronizationContext.Current null ist?

Question

Warum ist es nicht 100% sicher, Task.Wait() und Task.Result aufzurufen, wenn SynchronizationContext.Current null ist?

Ich habe einen Multi-Thread aber synchronen Service. Ich ersetze eine der synchronen Methoden durch einen Aufruf von HttpClient.PostAsXmlAsync. Die Implementierung verwendet .Result, um diese in eine synchrone Methode umzuwandeln, um zu vermeiden, dass das gesamte Projekt geändert wird. Wir erhalten jedoch die typischen Deadlock-Probleme, die gut dokumentiert sind.

Ich verstehe nicht, wie es zu einem Deadlock kommen könnte, wenn es keinen Synchronisationskontext gibt.

Answer 1

Die Methode HttpClient.PostAsXmlAsync ist eine Erweiterungsmethode, die HttpClient.SendAsync im Hintergrund ausführt. SendAsync Methode ist asynchrone Methode.
So rufen Sie asynchrone Methode auf "synchrone" Weise - die zu dem sehr gut dokumentierten Deadlock führen, wie Sie selbst bemerkt haben.

... dass in ein synchrones Verfahren zu konvertieren, zu vermeiden, dass das gesamte Projekt

Ändern

gesamte Anwendung Pipeline async Wechsel zu vermeiden - nicht async verwenden.
async-await ist ein Zombie-Virus, die alle über Ihre Anwendung zu verbreiten, wenn Sie es verwendet beginnen :)

Answer 2

Wenn kein Synchronisationskontext ist, wird die typical problems with blocking auf async Code passieren. Es ist jedoch nicht zu 100% sicher: Wenn der Thread zum Thread-Pool gehört, verhindert das Blockieren, dass der Thread in den Pool zurückkehrt, was dazu führen kann, dass Ihnen Thread-Thread-Threads ausgehen.

In meinem Fall wurde das Problem tatsächlich von unserem Unternehmens-Proxy-Server verursacht. Bei genügend Zeit würden die Fäden tatsächlich zurückkommen. Ich änderte meinen Code, um den HttpClient an einen HttpClientHandler mit UseProxy = false zu übergeben, und die Probleme gingen weg.