Petite question sur Task Run

Bonjour à tous,

j'ai une fonction qui prend du temps et qui bloque la fenetre.
Une fonction qui prend un Booleen en parametre et qui renvoi un Short.
Et j'ai besoin d'attendre que cette fonction soit terminé pour continuer.
J'ai donc appelé la fonction de cette manière :

Code:

---

Dim Ret As Short = Await Task.Run(Function() FonctionLente(True))

---

ça à l'air de fonctionner.
Mais je n'suis pas sur de comprendre ce que je fais.
J'avais tenté au début d'utiliser "Func()" à la place de "Function()",
mais ça ne fonctionnait pas, sans comprendre pourquoi.
Là j'ai l'impression d'appeler une fonction qui en appelle une autre.
Est-ce un Délégué ?
Est-ce la bonne façon de faire ?

En fait, Func ne passe pas car la syntaxe d'une lambda passe par le mot clé Function.
C'est même étonnant que ça compile avec Func, car il y a un problème de syntaxe.

En fait, Func est le nom d'un type délégué.
Tu as utilisé un type là où VB.Net attend la déclaration d'une expression lambda avec le mot clé Function.

Le code que tu as écrit peut s'écrire d'une autre manière, on peut le décomposer.
En le décomposant, on distingue clairement la déclaration du délégué et l'appel.

Peut s'écrire comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

' Déclaration d'un délégué de type Func(Of Short), c'est-à-dire une fonction ' qui ne prend aucun paramètre en entrée et retourne une valeur de type Short. ' On lui affecte une expression lambda qui, lorsqu'elle sera invoquée, ' appellera la fonction "FonctionLente" en lui passant l'argument True. Dim f As Func(Of Short) = Function() FonctionLente(True)   ' Lancement de l'exécution de "f" sur un thread du pool de threads, ' de manière asynchrone : "FonctionLente" s'exécute donc en arrière-plan, ' sans bloquer le thread appelant. ' Le mot-clé "Await" suspend la méthode courante (sans bloquer le thread) ' jusqu'à ce que la tâche soit terminée, puis récupère directement ' le résultat produit par "FonctionLente" (de type Short) et l'affecte à "Ret". Dim Ret = Await Task.Run(f)

---

Edit :
A noter, ce qui est important c'est le mot clé Function.
Ici, f est un délégué.
Il n'est pas exécuté tout de suite : FonctionLente(True) ne sera appelée que lorsque f sera invoquée, c'est-à-dire sur le thread du pool de threads lancé par Task.Run. L'exécution est donc bien asynchrone.

Si tu écris ceci :

Code:

---

Dim t = Task.Run(FonctionLente(True))

---

FonctionLente(True) s'exécute tout de suite, de manière synchrone, sur le thread appelant — exactement l'inverse de ce qu'on cherche à faire avec Task.Run.
Ensuite, son résultat (ici un Short) est passé en argument à Task.Run.
Mais puisque que Task.Run n'a pas de surcharge acceptant un Short en paramètre, ce code ne compile normalement pas.

J'ai une remarque à 2 balles (comme d'hab. :aie:).

Citation:

---

Code:

---

1 2 3 4 5 6

' Lancement de l'exécution de "f" sur un thread du pool de threads, ' de manière asynchrone : "FonctionLente" s'exécute donc en arrière-plan, ' sans bloquer le thread appelant. ' Le mot-clé "Await" suspend la méthode courante (sans bloquer le thread) ' jusqu'à ce que la tâche soit terminée, puis récupère directement ' le résultat produit par "FonctionLente" (de type Short) et l'affecte à "Ret".

---

---

A moins que VB.NET est un comportement complètement différent des autres langages .NET, car ce que je vais indiquer correspond à mes expériences en C# et pas en VB.NET, ce n'est pas toujours "exacte".

Ce qu'indique @popo n'est pas toujours "vrai" car en fonction du contexte de lancement (depuis l'explorateur, dans un site Web coté server, dans SQL Server, depuis une application console ...) et de l'AppDomain qui charge l'assembly les mécanismes d'exécution et de synchronisation varient énormément.

Oui, en fonction de comment vous lancez le bidule, le résultat du code peut varier grandement (d'un deadlock aléatoire à des valeurs "fausses"), enjoye :mouarf:.
Ce qu'explique @popo, c'est l'environnement "sympa" d'une application graphique dans un AppDomain "par défaut" de ce type d'application.

@popo Merci d'avoir passé du temps pour écrire toutes ces explications très très clair, j'ai tout compris :)

@bacelar Merci aussi pour toutes ces précisions :)

C'est bien de faire ce genre de remarque.
Mais, c'est mieux d'expliquer ce qui se passe plutôt que simplement dire "C'est pas vrai".
En l'occurrence, vous mélangez et/ou exagérez certaines choses.

Ce qui varie réellement selon l'hôte (WinForms, WPF, ASP.NET classique, ASP.NET Core, console, SQL CLR...), c'est où la continuation reprend après le Await, pas l'exécution de Task.Run elle-même.

Il y a "fond" de vérité dans ta remarque, mais tu as quelque peu exagéré sur la portée réelle du problème de ce bout de code précis.
Task.Run poste toujours le delegate sur le ThreadPool via TaskScheduler.Default.
Et Await ne bloque jamais le thread appelant : il transforme la méthode Async en machine à états et rend la main à l'appelant jusqu'à ce que la tâche se termine.
Ceci est garanti par le framework, il n'y a pas des comportements qui varient selon l'hôte.
Donc l'accusation "ça peut bloquer le thread" pour ce code précis (qui n'utilise que Await, jamais .Result/.Wait()) est en réalité peu probable dans l'absolu.

Ce qui varie réellement, c'est le SynchronizationContext.
Concrètement, à la fin de l'Await le compilateur capture SynchronizationContext.Current (ou TaskScheduler.Current s'il n'y en a pas) pour savoir où poster la continuation.

Dans WinForms/WPF, il y a un SynchronizationContext lié au thread UI (message loop / Dispatcher) → la suite revient sur le thread UI. C'est le comportement "sympa" que tu décris.

Dans une application Console ou un service windows, il n'y a pas de SynchronizationContext par défaut → la suite reprend simplement sur un thread du pool.

Pour Asp.Net classique, (System.Web), donc vieux Framework jusqu'à Framework 4.8, cela utilise AspNetSynchronizationContext qui a ses propres subtilité (c'est ici qu'est né le fameux problème de deadlock historique dont tu parles). Sauf que dans .Net d'aujourd'hui, le CORE (.Net 8, 9 , 10, etc.), cela n'utilise plus le vieux système, cela utilise ASP.NET Core qui n'installe aucun SynchronizationContext par défaut. Sans SynchronizationContext, le mécanisme précis du deadlock ASP.NET classique ne peut simplement pas se produire.

Dans le CLR SQL, cela ne provient pas du mécanisme Task.Run/Await.
C'est SQL Server qui restreint la création de threads et gère l'ordonnancement via son propre "host policy".

Après si on choisi volontairement de faire un blocage asynchone avec Result, .Wait() ou .GetAwaiter().GetResult(), on peut provoquer un blocage.
Mais le code que j'ai présenté ne le fait pas.

Donc, si on suit quelque règle de bases, il y a peu de chance que ça arrive avec un .Net moderne.

Règle n°1 : "async tout le long", jamais de blocage synchrone

Code:

---

1 2 3 4 5 6 7 8 9

' À éviter absolument sur le thread UI : Private Sub Button_Click(sender As Object, e As EventArgs) Dim resultat = ChargerDonneesAsync().Result ' <-- risque de deadlock End Sub   ' Bonne pratique : Private Async Sub Button_Click(sender As Object, e As EventArgs) Dim resultat = Await ChargerDonneesAsync() ' pas de blocage End Sub

---

Règle n°2 : ConfigureAwait(False) dans le code qui ne touche pas l'UI
Si on n'a pas d'UI, utiliser ConfigureAwait(False) après chaque Await devrait supprimer une bonne partie du risque.

Règle n°3 : ne jamais écrire un wrapper synchrone autour d'une méthode async.
C'est le pige classique !
Si tu expose une méthode non async qui appelle une méthode async avec .Result, tu augmentes le risque de le dead-lock.

Si on vraiment pas le choix d'avoir un point d'entrée synchrone, on peut limiter les dégâts en exécutant l'appel async sur un thread du pool, en dehors du contexte UI, puis en bloquant sur celui-là.

Code:

---

Dim resultat = Task.Run(Function() ChargerDonneesAsync()).GetAwaiter().GetResult()

---

Dans tous les cas, il y a une petite astuce que m'a donnée un collègue il y a quelque années :
Utiliser un analyseur pour détecter les cas dangereux.
Les analyseurs Roslyn Microsoft.VisualStudio.Threading.Analyzers (règles VSTHRD*) détectent ces patterns dangereux (VSTHRD002 "Avoid problematic synchronous waits", etc.) directement dans Visual Studio.

Bon, avec tout ces détail, j'ai certaiment fait naître encore plus de questions dans l'exprit de pqboot. :ptdr:
Mais pour résumer, le risque dont tu parles est très exagéré si on respecte les règles et qu'on arrête d'utilise le vieux Framework 4.x

Merci @popo pour cette mise au point.

"Ravi de voir que les choses ont évolués", dit une personne qui est resté bloqué sur des trucs qui n'existent plus depuis plus de 10 ans. :aie: