Consumindo o padrão assíncrono baseado em tarefa

Quando você usa o TAP (padrão assíncrono baseado em tarefa) para trabalhar com operações assíncronas, você pode usar retornos de chamada para obter uma espera sem bloqueio. Para tarefas, isso é feito por meio de métodos como Task.ContinueWith. O suporte assíncrono baseado em linguagem oculta retornos de chamada, permitindo que operações assíncronas sejam aguardadas dentro do fluxo de controle normal, e o código gerado pelo compilador fornece esse mesmo suporte no nível da API.

Suspendendo a execução com Await

Você pode usar a palavra-chave await em C# e o Operador Await no Visual Basic para aguardar Task e Task<TResult> objetos de forma assíncrona. Quando você está aguardando um Task, a expressão await é do tipo void. Quando você está aguardando um Task<TResult>, a expressão await é do tipo TResult. Uma await expressão deve ocorrer dentro do corpo de um método assíncrono. (Esses recursos de linguagem foram introduzidos no .NET Framework 4.5.)

Nos bastidores, a funcionalidade await instala um retorno de chamada na tarefa pelo uso de uma continuação. Esse retorno de chamada retoma o método assíncrono no ponto de suspensão. Quando o método assíncrono é retomado, se a operação de espera foi concluída com êxito e era uma Task<TResult>, o respectivo TResult é retornado. Se o Task ou Task<TResult> que foi aguardado terminou no estado Canceled, uma exceção OperationCanceledException será lançada. Se o Task ou Task<TResult> que foi aguardado terminou no estado Faulted, uma exceção que causou a falha será lançada. Uma Task falha pode ser resultado de várias exceções, mas apenas uma dessas exceções é propagada. No entanto, a Task.Exception propriedade retorna uma exceção AggregateException que contém todos os erros.

Se um objeto de contexto de sincronização (SynchronizationContext) estiver associado ao thread que estava executando o método assíncrono no momento da suspensão (por exemplo, se a propriedade SynchronizationContext.Current não estiver null), o método assíncrono será retomado nesse mesmo contexto de sincronização usando o método Post do contexto. Caso contrário, ele depende do agendador de tarefas (TaskScheduler objeto) que era atual no momento da suspensão. Normalmente, esse é o agendador de tarefas padrão (TaskScheduler.Default), que tem como destino o pool de threads. Este agendador de tarefas determina se a operação assíncrona aguardada deve ser retomada onde foi concluída ou se a retomada deve ser agendada. O agendador padrão geralmente permite que a continuação seja executada no thread em que a operação aguardada foi concluída.

Quando um método assíncrono é chamado, ele executa o corpo da função de modo síncrono até a primeira expressão await em uma instância aguardável que ainda não tenha foi concluída, no ponto em que a invocação retorna ao chamador. Se o método assíncrono não retornar void, um objeto Task ou Task<TResult> será retornado para representar a computação em andamento. Em um método assíncrono não nulo, se uma instrução return for encontrada ou o final do corpo do método for atingido, a tarefa será concluída no estado final RanToCompletion. Se uma exceção não tratada fizer com que o controle deixe o corpo do método assíncrono, a tarefa termina no estado Faulted. Caso essa exceção seja uma OperationCanceledException, a tarefa terminará no estado Canceled. Dessa forma, o resultado ou exceção é eventualmente publicado.

Há várias variações importantes desse comportamento. Por motivos de desempenho, se uma tarefa já tiver sido concluída quando a tarefa for aguardada, o controle não será gerado e a função continuará sendo executada. Além disso, retornar ao contexto original nem sempre é o comportamento desejado e pode ser alterado; isso é descrito com mais detalhes na próxima seção.

Configurando a suspensão e a retomada com Yield e ConfigureAwait

Vários métodos fornecem mais controle sobre a execução de um método assíncrono. Por exemplo, você pode usar o Task.Yield método para introduzir um ponto de rendimento no método assíncrono:

public class Task : …
{
    public static YieldAwaitable Yield();
    …
}

Isso é equivalente à postagem assíncrona ou ao agendamento de volta ao contexto atual.

Task.Run(async delegate
{
    for(int i=0; i<1000000; i++)
    {
        await Task.Yield(); // fork the continuation into a separate work item
        ...
    }
});

Você também pode usar o Task.ConfigureAwait método para melhor controle sobre suspensão e retomada em um método assíncrono. Conforme mencionado anteriormente, por padrão, o contexto atual é capturado no momento em que um método assíncrono é suspenso e esse contexto capturado é usado para invocar a continuação do método assíncrono após a retomada. Em muitos casos, esse é o comportamento exato desejado. Em outros casos, talvez você não se importe com o contexto de continuação e possa obter um melhor desempenho evitando essas postagens de volta ao contexto original. Para habilitar isso, use o método Task.ConfigureAwait para informar à operação de espera que não capture e retome no contexto, mas sim continue a execução no ponto em que a operação assíncrona que estava sendo aguardada foi concluída, seja qual for esse ponto:

await someTask.ConfigureAwait(continueOnCapturedContext:false);

Cancelando uma operação assíncrona

A partir do .NET Framework 4, os métodos TAP que dão suporte ao cancelamento fornecem pelo menos uma sobrecarga que aceita um token de cancelamento (CancellationToken objeto).

Um token de cancelamento é criado por meio de uma fonte de token de cancelamento (CancellationTokenSource objeto). A propriedade Token da fonte retorna o token de cancelamento que sinalizará quando o método Cancel da fonte será chamado. Por exemplo, se você quiser baixar uma única página da Web e quiser poder cancelar a operação, crie um CancellationTokenSource objeto, passe seu token para o método TAP e chame o método da Cancel origem quando estiver pronto para cancelar a operação:

var cts = new CancellationTokenSource();
string result = await DownloadStringTaskAsync(url, cts.Token);
… // at some point later, potentially on another thread
cts.Cancel();

Para cancelar várias invocações assíncronas, você pode passar o mesmo token para todas as invocações:

var cts = new CancellationTokenSource();
    IList<string> results = await Task.WhenAll(from url in urls select DownloadStringTaskAsync(url, cts.Token));
    // at some point later, potentially on another thread
    …
    cts.Cancel();

Ou você pode passar o mesmo token para um subconjunto seletivo de operações:

var cts = new CancellationTokenSource();
    byte [] data = await DownloadDataAsync(url, cts.Token);
    await SaveToDiskAsync(outputPath, data, CancellationToken.None);
    … // at some point later, potentially on another thread
    cts.Cancel();

Importante

As solicitações de cancelamento podem ser iniciadas a partir de qualquer thread.

Você pode passar o CancellationToken.None valor para qualquer método que aceite um token de cancelamento para indicar que o cancelamento nunca será solicitado. Isso faz com que a CancellationToken.CanBeCanceled propriedade retorne falsee o método chamado pode otimizar adequadamente. Para fins de teste, você também pode passar um token de cancelamento previamente cancelado que é instanciado pelo uso do construtor que aceita um valor booliano para indicar se o token deve iniciar em um estado não cancelável ou já cancelado.

Essa abordagem de cancelamento tem várias vantagens:

• Você pode passar o mesmo token de cancelamento para qualquer número de operações assíncronas e síncronas.

• A mesma solicitação de cancelamento pode ser proliferada para qualquer número de ouvintes.

• O desenvolvedor da API assíncrona está no controle completo de se o cancelamento pode ser solicitado e quando ele pode entrar em vigor.

• O código que consome a API pode determinar seletivamente as invocações assíncronas para as quais as solicitações de cancelamento serão propagadas.

Monitorando o progresso

Alguns métodos assíncronos expõem o progresso por meio de uma interface de progresso passada para o método assíncrono. Por exemplo, considere uma função que baixa de forma assíncrona uma cadeia de caracteres de texto e, ao longo do caminho, gera atualizações de progresso que incluem o percentual do download concluído até agora. Esse método pode ser consumido em um aplicativo WPF (Windows Presentation Foundation), da seguinte maneira:

private async void btnDownload_Click(object sender, RoutedEventArgs e)
{
    btnDownload.IsEnabled = false;
    try
    {
        txtResult.Text = await DownloadStringTaskAsync(txtUrl.Text,
            new Progress<int>(p => pbDownloadProgress.Value = p));
    }
    finally { btnDownload.IsEnabled = true; }
}

Usando os combinadores embutidos baseados em tarefas

O System.Threading.Tasks namespace inclui vários métodos para compor e trabalhar com tarefas.

Task.Run

A classe Task inclui vários métodos Run que permitem descarregar com facilidade o trabalho como um Task ou Task<TResult> para o pool de threads, por exemplo:

public async void button1_Click(object sender, EventArgs e)
{
    textBox1.Text = await Task.Run(() =>
    {
        // … do compute-bound work here
        return answer;
    });
}

Alguns desses métodos Run, como a sobrecarga de Task.Run(Func<Task>), existe como um atalho para o método TaskFactory.StartNew. Esta sobrecarga permite que você use await dentro do trabalho descarregado, por exemplo:

public async void button1_Click(object sender, EventArgs e)
{
    pictureBox1.Image = await Task.Run(async() =>
    {
        using(Bitmap bmp1 = await DownloadFirstImageAsync())
        using(Bitmap bmp2 = await DownloadSecondImageAsync())
        return Mashup(bmp1, bmp2);
    });
}

Essas sobrecargas são logicamente equivalentes ao uso do TaskFactory.StartNew método em conjunto com o Unwrap método de extensão na Biblioteca Paralela de Tarefas.

Task.FromResult

Use o método FromResult em cenários nos quais os dados talvez já estejam disponíveis e apenas precisem ser retornados de um método de retorno de tarefas elevado para uma Task<TResult>:

public Task<int> GetValueAsync(string key)
{
    int cachedValue;
    return TryGetCachedValue(out cachedValue) ?
        Task.FromResult(cachedValue) :
        GetValueAsyncInternal();
}

private async Task<int> GetValueAsyncInternal(string key)
{
    …
}

Task.WhenAll

Use o WhenAll método para aguardar de forma assíncrona várias operações assíncronas que são representadas como tarefas. O método tem várias sobrecargas que dão suporte a um conjunto de tarefas não genéricas ou a um conjunto não uniforme de tarefas genéricas (por exemplo, aguardando de forma assíncrona por várias operações de retorno nulo ou aguardando de forma assíncrona vários métodos de retorno de valor em que cada valor pode ter um tipo diferente) e para dar suporte a um conjunto uniforme de tarefas genéricas (como esperar de forma assíncrona por vários TResultmétodos de retorno de valor).

Digamos que você queira enviar mensagens de email para vários clientes. Você pode sobrepor o envio das mensagens para não aguardar a conclusão de uma mensagem antes de enviar a próxima. Você também pode descobrir quando as operações de envio foram concluídas e se ocorreram erros:

IEnumerable<Task> asyncOps = from addr in addrs select SendMailAsync(addr);
await Task.WhenAll(asyncOps);

Esse código não tratará explicitamente exceções que possam ocorrer, mas permitirá que as exceções sejam propagadas para fora do await na tarefa resultante de WhenAll. Para lidar com as exceções, você pode usar código como o seguinte:

IEnumerable<Task> asyncOps = from addr in addrs select SendMailAsync(addr);
try
{
    await Task.WhenAll(asyncOps);
}
catch(Exception exc)
{
    ...
}

Nesse caso, se qualquer operação assíncrona falhar, todas as exceções serão reunidas em uma AggregateException exceção, que é retornada do método Task e armazenada no WhenAll. No entanto, apenas uma dessas exceções é propagada pela await palavra-chave. Se você quiser examinar todas as exceções, poderá reescrever o código anterior da seguinte maneira:

Task [] asyncOps = (from addr in addrs select SendMailAsync(addr)).ToArray();
try
{
    await Task.WhenAll(asyncOps);
}
catch(Exception exc)
{
    foreach(Task faulted in asyncOps.Where(t => t.IsFaulted))
    {
        … // work with faulted and faulted.Exception
    }
}

Vamos considerar um exemplo de como baixar vários arquivos da Web de forma assíncrona. Nesse caso, todas as operações assíncronas têm tipos de resultados homogêneos e é fácil acessar os resultados:

string [] pages = await Task.WhenAll(
    from url in urls select DownloadStringTaskAsync(url));

Você pode usar as mesmas técnicas de tratamento de exceção que discutimos no cenário anterior de retorno nulo:

Task<string> [] asyncOps =
    (from url in urls select DownloadStringTaskAsync(url)).ToArray();
try
{
    string [] pages = await Task.WhenAll(asyncOps);
    ...
}
catch(Exception exc)
{
    foreach(Task<string> faulted in asyncOps.Where(t => t.IsFaulted))
    {
        … // work with faulted and faulted.Exception
    }
}

Task.WhenAny

Você pode usar o WhenAny método para aguardar assíncronamente apenas uma das várias operações assíncronas representadas como tarefas a serem concluídas. Esse método atende a quatro casos de uso primários:

• Redundância: executar uma operação várias vezes e selecionar a que é concluída primeiro (por exemplo, entrar em contato com vários serviços Web de cotação de ações que produzirão um único resultado e selecionar aquele que concluir o mais rápido).

• Intercalação: iniciar várias operações e aguardar que todas eles sejam concluídas, mas processando-as conforme são concluídas.

• Limitação: permitir que operações adicionais comecem conforme outras forem concluídas. Essa é uma extensão do cenário de intercalação.

• Saída precoce: por exemplo, uma operação representada pela tarefa t1 pode ser agrupada em uma tarefa WhenAny com outra tarefa t2 e você pode aguardar na tarefa WhenAny. A tarefa t2 pode representar um tempo limite ou cancelamento ou algum outro sinal que faça com que a WhenAny tarefa seja concluída antes da conclusão do t1.

Redundância

Considere um caso em que você deseja tomar uma decisão sobre se comprar uma ação. Há vários serviços Web de recomendação de ações em que você confia, mas dependendo da carga diária, cada serviço pode acabar sendo lento em momentos diferentes. Você pode usar o WhenAny método para receber uma notificação quando qualquer operação for concluída:

var recommendations = new List<Task<bool>>()
{
    GetBuyRecommendation1Async(symbol),
    GetBuyRecommendation2Async(symbol),
    GetBuyRecommendation3Async(symbol)
};
Task<bool> recommendation = await Task.WhenAny(recommendations);
if (await recommendation) BuyStock(symbol);

Ao contrário de WhenAll, que retorna os resultados desembrulhados de todas as tarefas que foram concluídas com êxito, WhenAny retorna apenas a tarefa que foi concluída. Se uma tarefa falhar, é importante saber que ela falhou e, se uma tarefa for bem-sucedida, é importante saber a qual tarefa o valor retornado está associado. Portanto, você precisa acessar o resultado da tarefa retornada ou aguardá-la ainda mais, como mostra este exemplo.

Assim como WhenAll, você deve ser capaz de acomodar exceções. Devido a você receber novamente a tarefa concluída, você poderá esperar a tarefa retornada para então propagar os erros e aplicar try/catch a eles adequadamente; por exemplo:

Task<bool> [] recommendations = …;
while(recommendations.Count > 0)
{
    Task<bool> recommendation = await Task.WhenAny(recommendations);
    try
    {
        if (await recommendation) BuyStock(symbol);
        break;
    }
    catch(WebException exc)
    {
        recommendations.Remove(recommendation);
    }
}

Além disso, mesmo que uma primeira tarefa seja concluída com êxito, as tarefas subsequentes poderão falhar. Neste ponto, você tem várias opções para lidar com exceções: você pode aguardar até que todas as tarefas iniciadas tenham sido concluídas, nesse caso, você pode usar o WhenAll método ou pode decidir que todas as exceções são importantes e devem ser registradas em log. Para isso, você pode usar continuações para receber uma notificação quando as tarefas forem concluídas de forma assíncrona:

foreach(Task recommendation in recommendations)
{
    var ignored = recommendation.ContinueWith(
        t => { if (t.IsFaulted) Log(t.Exception); });
}

ou:

foreach(Task recommendation in recommendations)
{
    var ignored = recommendation.ContinueWith(
        t => Log(t.Exception), TaskContinuationOptions.OnlyOnFaulted);
}

ou até mesmo:

private static async void LogCompletionIfFailed(IEnumerable<Task> tasks)
{
    foreach(var task in tasks)
    {
        try { await task; }
        catch(Exception exc) { Log(exc); }
    }
}
…
LogCompletionIfFailed(recommendations);

Por fim, talvez você queira cancelar todas as operações restantes:

var cts = new CancellationTokenSource();
var recommendations = new List<Task<bool>>()
{
    GetBuyRecommendation1Async(symbol, cts.Token),
    GetBuyRecommendation2Async(symbol, cts.Token),
    GetBuyRecommendation3Async(symbol, cts.Token)
};

Task<bool> recommendation = await Task.WhenAny(recommendations);
cts.Cancel();
if (await recommendation) BuyStock(symbol);

Intercalação

Considere um caso em que você está baixando imagens da Web e processando cada imagem (por exemplo, adicionando a imagem a um controle de interface do usuário). Você processa as imagens sequencialmente no thread da interface do usuário, mas deseja baixar as imagens da maneira mais simultânea possível. Além disso, você não deseja manter a adição das imagens à interface do usuário até que todas elas sejam baixadas. Em vez disso, você quer adicioná-las conforme forem concluídas.

List<Task<Bitmap>> imageTasks =
    (from imageUrl in urls select GetBitmapAsync(imageUrl)).ToList();
while(imageTasks.Count > 0)
{
    try
    {
        Task<Bitmap> imageTask = await Task.WhenAny(imageTasks);
        imageTasks.Remove(imageTask);

        Bitmap image = await imageTask;
        panel.AddImage(image);
    }
    catch{}
}

Você também pode aplicar interpolação para um cenário que envolve o processamento de recursos computacionais no ThreadPool das imagens baixadas; por exemplo:

List<Task<Bitmap>> imageTasks =
    (from imageUrl in urls select GetBitmapAsync(imageUrl)
         .ContinueWith(t => ConvertImage(t.Result)).ToList();
while(imageTasks.Count > 0)
{
    try
    {
        Task<Bitmap> imageTask = await Task.WhenAny(imageTasks);
        imageTasks.Remove(imageTask);

        Bitmap image = await imageTask;
        panel.AddImage(image);
    }
    catch{}
}

Limitação de Velocidade

Considere o exemplo de intercalação, exceto que o usuário está baixando um número tão grande de imagens que os downloads precisam ser limitados; por exemplo, você deseja que apenas um número específico de downloads ocorram simultaneamente. Para isso, você pode iniciar um subconjunto das operações assíncronas. À medida que as operações forem concluídas, você poderá iniciar operações adicionais para tomar seu lugar:

const int CONCURRENCY_LEVEL = 15;
Uri [] urls = …;
int nextIndex = 0;
var imageTasks = new List<Task<Bitmap>>();
while(nextIndex < CONCURRENCY_LEVEL && nextIndex < urls.Length)
{
    imageTasks.Add(GetBitmapAsync(urls[nextIndex]));
    nextIndex++;
}

while(imageTasks.Count > 0)
{
    try
    {
        Task<Bitmap> imageTask = await Task.WhenAny(imageTasks);
        imageTasks.Remove(imageTask);

        Bitmap image = await imageTask;
        panel.AddImage(image);
    }
    catch(Exception exc) { Log(exc); }

    if (nextIndex < urls.Length)
    {
        imageTasks.Add(GetBitmapAsync(urls[nextIndex]));
        nextIndex++;
    }
}

Saída precoce

Considere que você está aguardando de forma assíncrona a conclusão de uma operação ao responder simultaneamente à solicitação de cancelamento de um usuário (por exemplo, o usuário clicou em um botão cancelar). O código a seguir ilustra este cenário:

private CancellationTokenSource m_cts;

public void btnCancel_Click(object sender, EventArgs e)
{
    if (m_cts != null) m_cts.Cancel();
}

public async void btnRun_Click(object sender, EventArgs e)
{
    m_cts = new CancellationTokenSource();
    btnRun.Enabled = false;
    try
    {
        Task<Bitmap> imageDownload = GetBitmapAsync(txtUrl.Text);
        await UntilCompletionOrCancellation(imageDownload, m_cts.Token);
        if (imageDownload.IsCompleted)
        {
            Bitmap image = await imageDownload;
            panel.AddImage(image);
        }
        else imageDownload.ContinueWith(t => Log(t));
    }
    finally { btnRun.Enabled = true; }
}

private static async Task UntilCompletionOrCancellation(
    Task asyncOp, CancellationToken ct)
{
    var tcs = new TaskCompletionSource<bool>();
    using(ct.Register(() => tcs.TrySetResult(true)))
        await Task.WhenAny(asyncOp, tcs.Task);
    return asyncOp;
}

Essa implementação reabilita a interface do usuário assim que você decide sair, mas não as cancela as operações assíncronas subjacentes. Outra alternativa seria cancelar as operações pendentes quando você decide sair, mas não restabelecer a interface do usuário até que as operações sejam concluídas, possivelmente devido a um encerramento precoce devido à solicitação de cancelamento:

private CancellationTokenSource m_cts;

public async void btnRun_Click(object sender, EventArgs e)
{
    m_cts = new CancellationTokenSource();

    btnRun.Enabled = false;
    try
    {
        Task<Bitmap> imageDownload = GetBitmapAsync(txtUrl.Text, m_cts.Token);
        await UntilCompletionOrCancellation(imageDownload, m_cts.Token);
        Bitmap image = await imageDownload;
        panel.AddImage(image);
    }
    catch(OperationCanceledException) {}
    finally { btnRun.Enabled = true; }
}

Outro exemplo de resgate antecipado envolve o uso do método WhenAny em conjunto com o método Delay, conforme discutido na próxima seção.

Task.Delay

Você pode usar o Task.Delay método para introduzir pausas na execução de um método assíncrono. Isso é útil para muitos tipos de funcionalidade, incluindo a criação de loops de sondagem e o adiamento do tratamento da entrada do usuário por um período predeterminado de tempo. O método Task.Delay também pode ser útil em combinação com o Task.WhenAny para implementação de tempos limite em esperas.

Se uma tarefa que faz parte de uma operação assíncrona maior (por exemplo, um serviço Web ASP.NET) demorar muito para ser concluída, a operação geral poderá sofrer, especialmente se nunca for concluída. Por esse motivo, é importante poder definir um tempo limite ao aguardar uma operação assíncrona. Os métodos Task.Waite Task.WaitAllTask.WaitAnysíncronos aceitam valores de tempo limite, mas os métodos correspondentes TaskFactory.ContinueWhenAll/TaskFactory.ContinueWhenAnye mencionados Task.WhenAll/Task.WhenAny anteriormente não. Em vez disso, você pode usar Task.Delay e Task.WhenAny em combinação para implementar um tempo limite.

Por exemplo, em seu aplicativo de interface do usuário, digamos que você queira baixar uma imagem e desabilitar a interface do usuário enquanto a imagem estiver sendo baixada. No entanto, se o download demorar muito, é recomendável habilitar novamente a interface do usuário e descartar o download.

public async void btnDownload_Click(object sender, EventArgs e)
{
    btnDownload.Enabled = false;
    try
    {
        Task<Bitmap> download = GetBitmapAsync(url);
        if (download == await Task.WhenAny(download, Task.Delay(3000)))
        {
            Bitmap bmp = await download;
            pictureBox.Image = bmp;
            status.Text = "Downloaded";
        }
        else
        {
            pictureBox.Image = null;
            status.Text = "Timed out";
            var ignored = download.ContinueWith(
                t => Trace("Task finally completed"));
        }
    }
    finally { btnDownload.Enabled = true; }
}

O mesmo se aplica a vários downloads, porque WhenAll retorna uma tarefa:

public async void btnDownload_Click(object sender, RoutedEventArgs e)
{
    btnDownload.Enabled = false;
    try
    {
        Task<Bitmap[]> downloads =
            Task.WhenAll(from url in urls select GetBitmapAsync(url));
        if (downloads == await Task.WhenAny(downloads, Task.Delay(3000)))
        {
            foreach(var bmp in downloads.Result) panel.AddImage(bmp);
            status.Text = "Downloaded";
        }
        else
        {
            status.Text = "Timed out";
            downloads.ContinueWith(t => Log(t));
        }
    }
    finally { btnDownload.Enabled = true; }
}

Compilando combinadores baseados em tarefas

Como uma tarefa é capaz de representar completamente uma operação assíncrona e fornecer funcionalidades síncronas e assíncronas para ingressar na operação, recuperar seus resultados e assim por diante, você pode criar bibliotecas úteis de combinadores que compõem tarefas para criar padrões maiores. Conforme discutido na seção anterior, o .NET inclui vários combinadores internos, mas você também pode criar seus próprios. As seções a seguir fornecem vários exemplos de possíveis métodos e tipos de combinadores.

RetryOnFault

Em muitas situações, talvez você queira repetir uma operação se uma tentativa anterior falhar. Para código síncrono, você pode criar um método auxiliar, como RetryOnFault no exemplo a seguir, para fazer isso:

public static T RetryOnFault<T>(
    Func<T> function, int maxTries)
{
    for(int i=0; i<maxTries; i++)
    {
        try { return function(); }
        catch { if (i == maxTries-1) throw; }
    }
    return default(T);
}

Você pode criar um método auxiliar quase idêntico para operações assíncronas que são implementadas com TAP e, portanto, retornar tarefas:

public static async Task<T> RetryOnFault<T>(
    Func<Task<T>> function, int maxTries)
{
    for(int i=0; i<maxTries; i++)
    {
        try { return await function().ConfigureAwait(false); }
        catch { if (i == maxTries-1) throw; }
    }
    return default(T);
}

Em seguida, você pode usar esse combinador para codificar novas tentativas na lógica do aplicativo; por exemplo:

// Download the URL, trying up to three times in case of failure
string pageContents = await RetryOnFault(
    () => DownloadStringTaskAsync(url), 3);

Você pode estender ainda mais a RetryOnFault função. Por exemplo, a função pode aceitar outra Func<Task> que será invocada entre novas tentativas para determinar quando tentar a operação novamente; por exemplo:

public static async Task<T> RetryOnFault<T>(
    Func<Task<T>> function, int maxTries, Func<Task> retryWhen)
{
    for(int i=0; i<maxTries; i++)
    {
        try { return await function().ConfigureAwait(false); }
        catch { if (i == maxTries-1) throw; }
        await retryWhen().ConfigureAwait(false);
    }
    return default(T);
}

Em seguida, você pode usar a função da seguinte maneira para aguardar um segundo antes de repetir a operação:

// Download the URL, trying up to three times in case of failure,
// and delaying for a second between retries
string pageContents = await RetryOnFault(
    () => DownloadStringTaskAsync(url), 3, () => Task.Delay(1000));

NeedOnlyOne

Às vezes, você pode aproveitar a redundância para melhorar a latência e as chances de sucesso de uma operação. Considere vários serviços web que fornecem cotações de ações, mas em vários momentos do dia, cada serviço pode fornecer diferentes níveis de qualidade e tempos de resposta. Para lidar com essas flutuações, você pode emitir solicitações para todos os serviços Web e, assim que receber uma resposta de uma, cancele as solicitações restantes. Você pode implementar uma função auxiliar para facilitar a implementação desse padrão comum de inicialização de várias operações, aguardando qualquer uma e cancelando o restante. A NeedOnlyOne função no exemplo a seguir ilustra este cenário:

public static async Task<T> NeedOnlyOne(
    params Func<CancellationToken,Task<T>> [] functions)
{
    var cts = new CancellationTokenSource();
    var tasks = (from function in functions
                 select function(cts.Token)).ToArray();
    var completed = await Task.WhenAny(tasks).ConfigureAwait(false);
    cts.Cancel();
    foreach(var task in tasks)
    {
        var ignored = task.ContinueWith(
            t => Log(t), TaskContinuationOptions.OnlyOnFaulted);
    }
    return completed;
}

Em seguida, você pode usar essa função da seguinte maneira:

double currentPrice = await NeedOnlyOne(
    ct => GetCurrentPriceFromServer1Async("msft", ct),
    ct => GetCurrentPriceFromServer2Async("msft", ct),
    ct => GetCurrentPriceFromServer3Async("msft", ct));

Operações intercaladas

Há um possível problema de desempenho ao usar o método WhenAny para oferecer suporte a um cenário de intercalação ao trabalhar com grandes conjuntos de tarefas. Todas as chamadas para WhenAny fazem uma continuação ser registrada com cada tarefa. Para um número N de tarefas, isso resulta em O(N²) continuações criadas durante o tempo de vida da operação de intercalação. Se você estiver trabalhando com um grande conjunto de tarefas, poderá usar um combinador (Interleaved no exemplo a seguir) para resolver o problema de desempenho:

static IEnumerable<Task<T>> Interleaved<T>(IEnumerable<Task<T>> tasks)
{
    var inputTasks = tasks.ToList();
    var sources = (from _ in Enumerable.Range(0, inputTasks.Count)
                   select new TaskCompletionSource<T>()).ToList();
    int nextTaskIndex = -1;
    foreach (var inputTask in inputTasks)
    {
        inputTask.ContinueWith(completed =>
        {
            var source = sources[Interlocked.Increment(ref nextTaskIndex)];
            if (completed.IsFaulted)
                source.TrySetException(completed.Exception.InnerExceptions);
            else if (completed.IsCanceled)
                source.TrySetCanceled();
            else
                source.TrySetResult(completed.Result);
        }, CancellationToken.None,
           TaskContinuationOptions.ExecuteSynchronously,
           TaskScheduler.Default);
    }
    return from source in sources
           select source.Task;
}

Em seguida, você pode usar o combinador para processar os resultados das tarefas conforme elas são concluídas; por exemplo:

IEnumerable<Task<int>> tasks = ...;
foreach(var task in Interleaved(tasks))
{
    int result = await task;
    …
}

WhenAllOrFirstException

Em determinados cenários de dispersão/coleta, talvez você queira aguardar todas as tarefas em um conjunto, a menos que uma delas apresente falha, nesse caso, você deseja parar de esperar assim que uma exceção ocorrer. Você pode fazer isso com um método combinador, como WhenAllOrFirstException no exemplo a seguir:

public static Task<T[]> WhenAllOrFirstException<T>(IEnumerable<Task<T>> tasks)
{
    var inputs = tasks.ToList();
    var ce = new CountdownEvent(inputs.Count);
    var tcs = new TaskCompletionSource<T[]>();

    Action<Task> onCompleted = (Task completed) =>
    {
        if (completed.IsFaulted)
            tcs.TrySetException(completed.Exception.InnerExceptions);
        if (ce.Signal() && !tcs.Task.IsCompleted)
            tcs.TrySetResult(inputs.Select(t => t.Result).ToArray());
    };

    foreach (var t in inputs) t.ContinueWith(onCompleted);
    return tcs.Task;
}

Criando estruturas de dados baseadas em tarefas

Além da capacidade de criar combinadores personalizados baseados em tarefas, ter uma estrutura de dados em Task e Task<TResult> que representa tanto os resultados de uma operação assíncrona quanto a sincronização necessária para sincronizar-se com ela torna-o um tipo poderoso para construir estruturas de dados personalizadas a serem usadas em cenários assíncronos.

AsyncCache

Um aspecto importante de uma tarefa é que ela pode ser enviada para vários consumidores, todos os quais podem esperar por ela, registrar continuações com ela, obter seu resultado ou exceções (no caso de Task<TResult>) e assim por diante. Isso torna Task e Task<TResult> perfeitamente adequados para serem usados em uma infraestrutura de cache assíncrona. Aqui está um exemplo de um cache assíncrono pequeno, mas poderoso, criado com Task<TResult> como base:

public class AsyncCache<TKey, TValue>
{
    private readonly Func<TKey, Task<TValue>> _valueFactory;
    private readonly ConcurrentDictionary<TKey, Lazy<Task<TValue>>> _map;

    public AsyncCache(Func<TKey, Task<TValue>> valueFactory)
    {
        if (valueFactory == null) throw new ArgumentNullException("valueFactory");
        _valueFactory = valueFactory;
        _map = new ConcurrentDictionary<TKey, Lazy<Task<TValue>>>();
    }

    public Task<TValue> this[TKey key]
    {
        get
        {
            if (key == null) throw new ArgumentNullException("key");
            return _map.GetOrAdd(key, toAdd =>
                new Lazy<Task<TValue>>(() => _valueFactory(toAdd))).Value;
        }
    }
}

A classe AsyncCache<TKey, TValue> aceita como delegado para seu construtor uma função que usa um TKey e retorna um Task<TResult>. Todos os valores acessados anteriormente do cache são armazenados no dicionário interno e garante AsyncCache que apenas uma tarefa seja gerada por chave, mesmo que o cache seja acessado simultaneamente.

Por exemplo, você pode criar um cache para páginas da Web baixadas:

private AsyncCache<string,string> m_webPages =
    new AsyncCache<string,string>(DownloadStringTaskAsync);

Em seguida, você pode usar esse cache em métodos assíncronos sempre que precisar do conteúdo de uma página da Web. A AsyncCache classe garante que você esteja baixando o mínimo possível de páginas e armazene os resultados em cache.

private async void btnDownload_Click(object sender, RoutedEventArgs e)
{
    btnDownload.IsEnabled = false;
    try
    {
        txtContents.Text = await m_webPages["https://www.microsoft.com"];
    }
    finally { btnDownload.IsEnabled = true; }
}

AsyncProducerConsumerCollection

Você também pode usar tarefas para criar estruturas de dados para coordenar atividades assíncronas. Considere um dos padrões clássicos de design paralelo: produtor/consumidor. Nesse padrão, produtores geram dados que são consumidos pelos consumidores e produtores e consumidores podem executar em paralelo. Por exemplo, o consumidor processa o item 1, que foi gerado anteriormente por um produtor que agora está produzindo o item 2. Para o padrão de produtor/consumidor, você invariavelmente precisa de alguma estrutura de dados para armazenar o trabalho criado pelos produtores para que os consumidores possam ser notificados sobre novos dados e encontrá-los quando disponíveis.

Eis aqui uma estrutura de dados simples criada sobre tarefas que permitem que os métodos assíncronos sejam usados como produtores e consumidores:

public class AsyncProducerConsumerCollection<T>
{
    private readonly Queue<T> m_collection = new Queue<T>();
    private readonly Queue<TaskCompletionSource<T>> m_waiting =
        new Queue<TaskCompletionSource<T>>();

    public void Add(T item)
    {
        TaskCompletionSource<T> tcs = null;
        lock (m_collection)
        {
            if (m_waiting.Count > 0) tcs = m_waiting.Dequeue();
            else m_collection.Enqueue(item);
        }
        if (tcs != null) tcs.TrySetResult(item);
    }

    public Task<T> Take()
    {
        lock (m_collection)
        {
            if (m_collection.Count > 0)
            {
                return Task.FromResult(m_collection.Dequeue());
            }
            else
            {
                var tcs = new TaskCompletionSource<T>();
                m_waiting.Enqueue(tcs);
                return tcs.Task;
            }
        }
    }
}

Com essa estrutura de dados em vigor, você pode escrever código como o seguinte:

private static AsyncProducerConsumerCollection<int> m_data = …;
…
private static async Task ConsumerAsync()
{
    while(true)
    {
        int nextItem = await m_data.Take();
        ProcessNextItem(nextItem);
    }
}
…
private static void Produce(int data)
{
    m_data.Add(data);
}

O System.Threading.Tasks.Dataflow namespace inclui o BufferBlock<T> tipo, que você pode usar de maneira semelhante, mas sem precisar criar um tipo de coleção personalizado:

private static BufferBlock<int> m_data = …;
…
private static async Task ConsumerAsync()
{
    while(true)
    {
        int nextItem = await m_data.ReceiveAsync();
        ProcessNextItem(nextItem);
    }
}
…
private static void Produce(int data)
{
    m_data.Post(data);
}

Observação

O System.Threading.Tasks.Dataflow namespace está disponível como um pacote NuGet. Para instalar o assembly que contém o System.Threading.Tasks.Dataflow namespace, abra seu projeto no Visual Studio, escolha Gerenciar Pacotes NuGet no menu Projeto e pesquise online pelo System.Threading.Tasks.Dataflow pacote.

Consulte também

• TAP (Padrão Assíncrono baseado em tarefa)
• Implementando o padrão assíncrono baseado em tarefa
• Interoperabilidade com outros padrões e tipos assíncronos