-2
votes

Si le thread d'appel sera bloqué si la tâche est appelée dans la fonction de retour de la tâche

J'essaie de ne pas créer de tâche code> redondante code> dans mon code et j'écris Task code> Fonctions de retour au lieu de Async Task Code> Fonctions où il est possible. .

Lorsqu'il est nécessaire de sauvegarder la valeur renvoyée par une fonction code> async code>, je suis obligé de rendre la fonction renvoyer la fonction async tâche code> et appelle fonction avec attendre .

example:pre ,xxxxp>Que j'ai écrit à la place: p> xxx pré>

mais je J'ai peur de bloquer le fil d'appel comme un code synchrone. p>

await SomeWorkAsync(); //main thread block


1 commentaires

Tâche.Result bloque le fil d'appel: docs.microsoft.com/en-us/dotnet/api/...


3 Réponses :


0
votes

Si vous souhaitez enregistrer votre auto, appelez simplement

public async Task SomeWorkAsync()
{
   someGlobalVariable = await AnotherWorkAsync();
}


4 commentaires

Oui, cela fait l'affaire si un autre utworkasync est async tâche mais dans mon cas c'est async tâche et j'ai besoin du résultat de Un autre ukworkasync


Ce n'est toujours pas ce que je veux dire. Classe qui appellera CertainworkAsync ne sait rien de la variable privée individuelglobalvariable . Il est nécessaire d'obtenir de la valeur et de définir cette variable à l'intérieur


Eh bien, maintenant c'est la même chose que j'écris dans l'exemple :) Il semble qu'il n'y ait pas d'autre moyen


@ Денисперевозчиков Il semble impossible ce que vous demandez. Si vous voulez ne pas bloquer le fil, il n'y a pas d'autre moyen que d'utiliser attendre mot-clé. Toutes les autres options bloqueraient le fil et le code d'exécution synchrone



1
votes

J'essaie de ne pas créer d'objets de tâches redondants dans mon code et j'écris des fonctions de retour de tâche au lieu des fonctions de tâche asynchronisées où elle est possible.

Ce n'est pas courant ni la façon prévue de travailler avec le TPL.

c'est faux: xxx

Vous devez utiliser xxx

uniquement dans des circonstances strictes devrait Vous utilisez .result pour obtenir le résultat d'une tâche .


9 commentaires

Merci d'avoir chiming dans, je dois aller me coucher et votre explication est bien meilleure


@Thegeneral Sans problème, bon sommeil :)


Vous ne devriez jamais utiliser .result. Au lieu de cela, vous devriez utiliser .getawaiter (). GetResult (). Il n'y a aucune circonstance où vous pouvez utiliser .result et ne peut pas utiliser .GETAWAITER (). GETRESULT ()


@Olegi Si vous envisagez l'avertissement de ne pas utiliser .getawaiter () dans le résumé de la fonction, car cela est censé être utilisé à l'intérieur par le compilateur, vous devez préférer utiliser .result


@Camiloterevinto N ° N ° .Result va envelopper toutes vos exceptions en agrégateException, à l'exception de celle-ci, elle se comporte absolument identique à celle de .getawaiter (). GetResult (). Il n'y a aucun cas d'usage dans lequel vous devez utiliser .result


J'ai lu dans certains articles qu'il est mauvais pratique d'ajouter async uniquement pour un appel avec attendre car il crée une nouvelle tâche et charges gc


@ Денисперевозчиков et Stephen Cleary, l'un des principaux développeurs, dit de ne pas s'inquiéter de l'extrême petite surcharge ajoutée. Veuillez prendre le temps de lire: blog.stephancleary.com/2016/12 /elling-async-await.html Il y a trop de BS sur le TPL. Il y a des cas où async / attendre peut être évité, mais pas dans l'affaire dans votre question


@ Денисперевозчиков Vous avez mal compris async mot-clé. Cela ne fait que donner la possibilité d'appeler une méthode en attente avec attendre mot-clé


@Onegi c'est complètement faux. En utilisant attendre ajoute une machine d'état dans le code généré. Que, bien que petit, ajoute des frais généraux



0
votes

Pour répondre à votre question:

  1. Oui, appelant .result bloquera votre fil.
  2. Voir mon commentaire sur pourquoi je pense qu'il est préférable d'utiliser attendre et de ne pas renverser une tâche: https://stackoverflow.com/ A / 54211382/918058

0 commentaires