Dans une application multithread, comprendre le flux d'exécution est crucial. Lorsqu'ils rencontrent l'énigmatique mot-clé « attendre », les développeurs se posent souvent la question suivante : « Quel thread orchestre la reprise du code après le « attendre » ? »
Considérez l'extrait de code suivant :
private void MyMethod() { Task task = MyAsyncMethod(); task.Wait(); } private async Task MyAsyncMethod() { //Code before await await MyOtherAsyncMethod(); //Code after await }
En supposant que ce code fonctionne dans une application monothread, cela devient perplexe : comment le code après le mot-clé 'await' peut-il s'exécuter si le le fil de discussion est verrouillé par 'task.Wait()' ?
La réponse réside dans le comportement sophistiqué du mot-clé 'await'. Il redonne le contrôle à l'appelant, permettant ainsi à d'autres opérations asynchrones de se poursuivre. La suite de la tâche 'en attente' (le code après 'attendre') est programmée pour s'exécuter sur un thread conforme au contexte de synchronisation actuel.
Dans ce scénario, si la fonction 'MyMethod()' s'exécute sur un thread d'interface utilisateur, le code après « attendre » s'exécuterait également sur le thread d'interface utilisateur une fois « MyOtherAsyncMethod() » se termine.
Cependant, il est important de noter que le fil exact utilisé pour la suite n'est pas garanti. Dans les applications multithread, la suite peut s'exécuter sur n'importe quel thread disponible du pool de threads. Cependant, le contexte de synchronisation garantit que le code après 'wait' est exécuté de manière cohérente par rapport au thread d'origine.
Dans l'exemple donné, en appelant 'task.Wait()', le principal le thread sera bloqué indéfiniment, empêchant la suite de s'exécuter. Pour éviter cela, les opérations asynchrones doivent être correctement attendues sans bloquer le thread principal.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!