Async / await en .NET

Pourquoi un simple .Result peut figer toute une application ? Déroulez pas à pas le thread, la continuation et le contexte de synchronisation.

En .NET, await ne crée pas de thread : il libère le thread courant et enregistre une continuation (le code qui suit) à reprendre plus tard. Encore faut-il que ce thread soit libre pour la reprendre… Choisissez un scénario et avancez pas à pas.

Scénarios préparés (l'outil n'exécute pas de code) : les étapes sont tracées à la main pour illustrer le comportement réel du runtime .NET.

Synchrone vs async/await : le thread libéré

Même appel à une base de données ou à une API : l'attente d'entrée/sortie (I/O) dure exactement le même temps. La différence n'est pas la vitesse, c'est ce que devient le thread pendant l'attente.

Deux chronologies, une seule attente d'I/O
SYNCHRONE (BLOQUANT) 1 thread calcul attente I/O (BDD / HTTP) thread BLOQUÉ — ne fait rien suite 1 thread immobilisé pendant toute l'attente Même durée d'attente I/O des deux côtés — seul l'async libère le thread ASYNC / AWAIT 1 thread await ↓ reprise ↓ calcul thread RENDU au pool libre — sert d'autres requêtes continuation I/O en cours en arrière-plan (réseau / disque) Thread libéré pendant l'attente, puis la suite reprend (souvent sur un autre thread) temps → début I/O fin I/O

await ne rend pas l'I/O plus rapide : il libère le thread pendant l'attente, qui peut servir d'autres requêtes. Résultat : on encaisse beaucoup plus de requêtes simultanées avec le même nombre de threads.

Thread principal / UI

Continuation en attente

Tâche (Task)

Console

Retour aux outils