différence entre Asynchrone et Synchrone .net 4.5

Au cours de ma lecture sur la Programmation Asynchrone .Net 4.5 async et await mots-clés
J'ai lu Ici le paragraphe suivant

De Traitement Des Requêtes Asynchrones

Dans les applications web qui voit un grand nombre de requêtes simultanées à
start-up ou a un éclaté de la charge (d'où la simultanéité augmente soudainement),
faire ces appels aux services web asynchrones va augmenter la
la réactivité de votre application. Une requête asynchrone prend
la même quantité de temps pour les processus synchrone demande. Pour
exemple, si une demande qui fait un appel de service web qui nécessite deux
secondes pour terminer, la demande prend deux secondes s'il est
réalisées de manière synchrone ou asynchrone. Cependant, lors d'une
appel asynchrone, un thread n'est pas bloqué de répondre à d'autres
les demandes pendant qu'il attend la première demande de remplir. Par conséquent,
des requêtes asynchrones empêcher demande de files d'attente et le pool de threads de croissance
quand il y a beaucoup de demandes simultanées qui invoquent la longue
les opérations.

pour les mots en gras, je ne pouvais pas comprendre comment Une requête asynchrone prend la même quantité de temps pour le processus synchrone demande?

Par exemple:

public async Task MyMethod()
{
    Task<int> longRunningTask = LongRunningOperation();
    //indeed you can do independent to the int result work here 

    //and now we call await on the task 
    int result = await longRunningTask;
    //use the result 
    Console.WriteLine(result);
}

public async Task<int> LongRunningOperation() //assume we return an int from this long running operation 
{
    await Task.Delay(1000); //1 seconds delay
    return 1;
}

Ce que je comprends que LongRunningOperation() commence l'exécution de la première ligne de l'appel ici Task<int> longRunningTask = LongRunningOperation(); et retourne la valeur une fois l'appel await,
donc, de mon point de vue code asynchrone plus vite que synchrone, c'est bien cela?

Une autre question:

Ce que je comprends que le thread principal de travail sur l'exécution de MyMethod() pas bloqué dans l'attente d' LongRunningOperation() être accompli, mais il revient à pool de threads pour servir une autre demande. donc, il y a un autre thread attribué à LongRunningOperation(); pour l'exécuter?

Si oui quelle est donc la différence entre la Programmation Asynchrone et le Multithreading Programmation ?

Mise à jour:

disons que le code devient comme ça:

public async Task MyMethod()
    {
        Task<int> longRunningTask = LongRunningOperation();
        //indeed you can do independent to the int result work here 
        DoIndependentWork();
        //and now we call await on the task 
        int result = await longRunningTask;
        //use the result 
        Console.WriteLine(result);
    }

    public async Task<int> LongRunningOperation() //assume we return an int from this long running operation 
    {
        DoSomeWorkNeedsExecution();
        await Task.Delay(1000); //1 seconds delay
        return 1;
    }

Dans ce cas, LongRunningOperation() être exécuté par un autre thread pendant DoIndependentWork() exécution?

Il vous manque quelques bases importantes. Difficile de donner une bonne réponse. Vous avez besoin d'un tutoriel. Découvrez ce qui attend les ne.
Il va toujours prendre la même quantité de temps pour effectuer le travail, le code asynchrone simplement exécute le travail dans un ordre différent. Le truc qui prend plus de temps peut obtenir déchargées à un autre thread. De sorte que la tâche prendra encore du temps, mais l'application n'est tout simplement pas attendre pour la tâche à effectuer.

OriginalL'auteur Abraham Josef | 2015-01-02

  1. 20

    Les opérations asynchrones ne sont pas plus rapide. Si vous attendez 10 secondes en mode asynchrone (c'est à dire await Task.Delay(10000)) ou synchrone (c'est à dire Thread.Sleep(10000)) il prendrait la même 10 secondes. La seule différence serait que le premier ne permettrait pas de tenir un fil lors de l'attente mais le second.

    Maintenant, si vous lancez une tâche et ne pas attendre qu'elle se termine immédiatement, vous pouvez utiliser le même thread pour faire un autre travail, mais il n'a pas "d'accélérer" l'opération asynchrone d'exécution:

    var task = Task.Delay(10000);
//processing
await task; //will complete only after 10 seconds

    À propos de votre deuxième question: Task.Delay (comme d'autres vraiment opérations asynchrones) n'a pas besoin d'un thread à exécuter et ainsi de il n'y a pas de fil. Task.Delay est mis en œuvre à l'aide d'un System.Threading.Timer que vous le feu et il déclenche un événement quand il est fait, dans l'intervalle, il n'a pas besoin d'un fil, car il n'y a pas de code à exécuter.

    Ainsi, lorsque le thread en cours d'exécution MyMethod atteint le await longRunningTask il est libéré (tant que longRunningTask n'a pas encore terminé). Si c'était un ThreadPool fil il sera de retour à la ThreadPool où il peut traiter un autre code dans votre application.

    Concernant la mise à jour du flux serait donc:

    • MyMethod commence le traitement
    • LongRunningOperation commence le traitement
    • DoSomeWorkNeedsExecution est exécutée dans le thread appelant
    • Un await est atteint dans LongRunningOperation et donc une chaude tâche est retourné.
    • DoIndependentWork est exécuté par le même thread appelant (LongRunningOperation est toujours "en cours", pas de fil est nécessaire)
    • Un await est atteint dans MyMethod. Si la tâche est achevée le même thread va procéder de façon synchrone, si elle n'est pas alors une chaude tâche serait retourné qui viendrait compléter par la suite.

    Donc le fait que vous êtes en utilisant async-await vous permet d'utiliser un thread qui autrement seraient bloqués en attente de façon synchrone pour exécuter, CPU-intensive de travail.

    Grâce l3arnon pour votre réponse rapide, "dans l'intervalle, il n'a pas besoin d'un fil, car il n'y a pas de code à exécuter." pour cela, supposons que longRunningTask a une grande quantité de code à exécuter, un autre thread plutôt que le thread principal sera attribué à celui-ci?
    Si ce travail est intensif pour le CPU (c'est à dire pas asynchrone) il y a ensuite 2 options. Si c'est avant la await il sera exécuté sur le thread appelant. Si c'est après, puis il sera exécuté sur un fil en fonction de la SynchronizationContext (en général il n'en est pas un, donc un thread du pool serait utilisé).
    Si le travail est asynchrone (par exemple, I/O) alors pas de fil est nécessaire.
    Merci beaucoup
    Puis-je vous demander si possible pour vous expliquer ce qui est le plus bénéfique?

    OriginalL'auteur i3arnon

  2. 5

    En compte la différence entre:

    Thread.Sleep(1000);

    et

    await Task.Delay(1000);

    deux va en prendre un deuxième pour l'exécuter. Cependant, dans le premier cas, le thread courant sera bloqué (et toutes ses ressources inutiles) tandis que dans le second cas, le thread actuel peut faire autre chose que de l'utile (par exemple. au service d'une autre demande).

    L'asynchronicité n'est pas à propos de la vitesse des séquences d'instructions, mais être capable de faire des choses quand synchrone code block.

    Re. Une autre question

    Le fil(s) libéré sera utilisé pour d'autres choses; il n'y aura pas de fil attribué jusqu'à ce que l'opération est terminée. Cela est possible parce que l'OS sous-jacent est lui-même asynchrone. Dans l'exemple ci-dessus, une minuterie est utilisée, ce qui est signalé par un fil à ramasser quand un thread est gratuit, plutôt qu'un thread a été arrêté pour un interne.

    OriginalL'auteur Richard

  3. 2

    (bâtiment sur I3arnon réponse)

    Ce n'est pas tout à fait vrai que des opérations synchrones et des opérations à l'aide de async-await sera, dans l'ensemble, prenez le même temps.

    Il y a une certaine logique supplémentaire impliqué dans async-await. Contrôles de la fin de l'awaiters et d'une machine à état sont impliqués. Cela rend certaines opérations asynchrones prendre plus de temps que celle d'un fonctionnement synchrone.

    D'autre part, la plupart des opérations adaptées pour async-await sont naturellement asynchrone et il ya un supplément de traitement impliqués pour le faire paraître et se sentir synchrone. Dans ces cas, l'opération asynchrone est prend moins de temps que la machine synchrone homologue.

    La citation sur la question est liée à des applications web. Pour les applications web, les opérations asynchrones sont plus au sujet de la signification du nombre maximum de requêtes sur un délai acceptable que l'économie de quelques microsecondes de chaque demande. Sur l'autre main, si une commutation de contexte est en cause, il finit par prendre plus de temps et c'est pourquoi à l'aide de Task.Run dans une application web n'a plus de mal que de bien à l'application.

    Si vous voulez en savoir plus sur async-awit, lire les articles sur mon async-awit curation.

    OriginalL'auteur Paulo Morgado