Quand utiliser TaskCompletionSource <T>?

AFAIK, tout ce qu'il sait, c'est qu'à un moment donné, sa SetResultou SetExceptionméthode est appelée pour compléter l' Task<T>exposition à travers sa Taskpropriété.

En d'autres termes, il agit en tant que producteur pour a Task<TResult>et son achèvement.

J'ai vu ici l'exemple:

Si j'ai besoin d'un moyen d'exécuter un Func de manière asynchrone et d'avoir une tâche pour représenter cette opération.

public static Task<T> RunAsync<T>(Func<T> function) 
{ 
    if (function == null) throw new ArgumentNullException(“function”); 
    var tcs = new TaskCompletionSource<T>(); 
    ThreadPool.QueueUserWorkItem(_ => 
    { 
        try 
        {  
            T result = function(); 
            tcs.SetResult(result);  
        } 
        catch(Exception exc) { tcs.SetException(exc); } 
    }); 
    return tcs.Task; 
}

Ce qui pourrait être utilisé * si je n'ai pas Task.Factory.StartNew- mais je n'avoir .Task.Factory.StartNew

Question:

Quelqu'un peut -il expliquer par exemple s'il vous plaît un scénario lié directement à TaskCompletionSource et non à une hypothétique situation dans laquelle je n'ai pas Task.Factory.StartNew?

Je l'utilise principalement lorsque seule une API basée sur les événements est disponible ( par exemple les sockets Windows Phone 8 ):

public Task<Args> SomeApiWrapper()
{
    TaskCompletionSource<Args> tcs = new TaskCompletionSource<Args>(); 

    var obj = new SomeApi();

    // will get raised, when the work is done
    obj.Done += (args) => 
    {
        // this will notify the caller 
        // of the SomeApiWrapper that 
        // the task just completed
        tcs.SetResult(args);
    }

    // start the work
    obj.Do();

    return tcs.Task;
}

Il est donc particulièrement utile lorsqu'il est utilisé avec le asyncmot clé C # 5 .

Dans mes expériences, TaskCompletionSourceest idéal pour emballer les anciens modèles asynchrones au async/awaitmodèle moderne .

L'exemple le plus bénéfique auquel je peux penser est lorsque je travaille avec Socket. Il a l'ancienne APM et les modèles EAP, mais pas les awaitable Taskméthodes TcpListeneret TcpClientont.

J'ai personnellement plusieurs problèmes avec la NetworkStreamclasse et je préfère le brut Socket. Étant donné que j'aime aussi le async/awaitmotif, j'ai créé une classe d'extension SocketExtenderqui crée plusieurs méthodes d'extension pour Socket.

Toutes ces méthodes utilisent TaskCompletionSource<T>pour encapsuler les appels asynchrones comme suit:

    public static Task<Socket> AcceptAsync(this Socket socket)
    {
        if (socket == null)
            throw new ArgumentNullException("socket");

        var tcs = new TaskCompletionSource<Socket>();

        socket.BeginAccept(asyncResult =>
        {
            try
            {
                var s = asyncResult.AsyncState as Socket;
                var client = s.EndAccept(asyncResult);

                tcs.SetResult(client);
            }
            catch (Exception ex)
            {
                tcs.SetException(ex);
            }

        }, socket);

        return tcs.Task;
    }

Je passe le socketdans les BeginAcceptméthodes afin que j'obtienne une légère augmentation des performances du compilateur sans avoir à hisser le paramètre local.

Ensuite, la beauté de tout cela:

 var listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
 listener.Bind(new IPEndPoint(IPAddress.Loopback, 2610));
 listener.Listen(10);

 var client = await listener.AcceptAsync();

Pour moi, un scénario classique d'utilisation TaskCompletionSourceest quand il est possible que ma méthode ne doive pas nécessairement faire une opération longue. Ce qu'il nous permet de faire, c'est de choisir les cas spécifiques où nous aimerions utiliser un nouveau fil.

Un bon exemple pour cela est lorsque vous utilisez un cache. Vous pouvez avoir une GetResourceAsyncméthode qui recherche dans le cache la ressource demandée et renvoie immédiatement (sans utiliser de nouveau thread, en utilisant TaskCompletionSource) si la ressource a été trouvée. Seulement si la ressource n'a pas été trouvée, nous aimerions utiliser un nouveau thread et le récupérer en utilisant Task.Run().

Un exemple de code peut être vu ici: Comment exécuter de manière conditionnelle un code de manière asynchrone à l'aide de tâches

Dans cet article de blog , Levi Botelho décrit comment utiliser le TaskCompletionSourcepour écrire un wrapper asynchrone pour un processus de telle sorte que vous puissiez le lancer et attendre sa fin.

public static Task RunProcessAsync(string processPath)
{
    var tcs = new TaskCompletionSource<object>();
    var process = new Process
    {
        EnableRaisingEvents = true,
        StartInfo = new ProcessStartInfo(processPath)
        {
            RedirectStandardError = true,
            UseShellExecute = false
        }
    };
    process.Exited += (sender, args) =>
    {
        if (process.ExitCode != 0)
        {
            var errorMessage = process.StandardError.ReadToEnd();
            tcs.SetException(new InvalidOperationException("The process did not exit correctly. " +
                "The corresponding error message was: " + errorMessage));
        }
        else
        {
            tcs.SetResult(null);
        }
        process.Dispose();
    };
    process.Start();
    return tcs.Task;
}

et son utilisation

await RunProcessAsync("myexecutable.exe");

Il semble que personne n'ait mentionné, mais je suppose que les tests unitaires peuvent également être considérés comme assez réels .

Je trouve TaskCompletionSourceutile lorsque l'on se moque d'une dépendance avec une méthode asynchrone.

Dans le programme en cours de test:

public interface IEntityFacade
{
  Task<Entity> GetByIdAsync(string id);
}

Dans les tests unitaires:

// set up mock dependency (here with NSubstitute)

TaskCompletionSource<Entity> queryTaskDriver = new TaskCompletionSource<Entity>();

IEntityFacade entityFacade = Substitute.For<IEntityFacade>();

entityFacade.GetByIdAsync(Arg.Any<string>()).Returns(queryTaskDriver.Task);

// later on, in the "Act" phase

private void When_Task_Completes_Successfully()
{
  queryTaskDriver.SetResult(someExpectedEntity);
  // ...
}

private void When_Task_Gives_Error()
{
  queryTaskDriver.SetException(someExpectedException);
  // ...
}

Après tout, cette utilisation de TaskCompletionSource semble être un autre cas «d'un objet Task qui n'exécute pas de code».

TaskCompletionSource est utilisé pour créer des objets Task qui n'exécutent pas de code. Dans les scénarios du monde réel, TaskCompletionSource est idéal pour les opérations liées aux E / S. De cette façon, vous obtenez tous les avantages des tâches (par exemple, les valeurs de retour, les continuations, etc.) sans bloquer un thread pendant la durée de l'opération. Si votre "fonction" est une opération liée aux E / S, il n'est pas recommandé de bloquer un thread à l'aide d'une nouvelle tâche . Au lieu de cela, à l'aide de TaskCompletionSource , vous pouvez créer une tâche esclave pour simplement indiquer quand votre opération liée aux E / S se termine ou si elle ne fonctionne pas.

Il y a un exemple du monde réel avec une explication décente dans cet article du blog "Programmation parallèle avec .NET" . Vous devriez vraiment le lire, mais voici quand même un résumé.

Le billet de blog montre deux implémentations pour:

"une méthode d'usine pour créer des tâches" différées ", celles qui ne seront pas réellement planifiées jusqu'à ce qu'un délai d'expiration fourni par l'utilisateur se soit produit."

La première implémentation illustrée est basée sur Task<>et présente deux défauts majeurs. Le deuxième post d'implémentation continue à les atténuer en utilisant TaskCompletionSource<>.

Voici cette deuxième implémentation:

public static Task StartNewDelayed(int millisecondsDelay, Action action)
{
    // Validate arguments
    if (millisecondsDelay < 0)
        throw new ArgumentOutOfRangeException("millisecondsDelay");
    if (action == null) throw new ArgumentNullException("action");

    // Create a trigger used to start the task
    var tcs = new TaskCompletionSource<object>();

    // Start a timer that will trigger it
    var timer = new Timer(
        _ => tcs.SetResult(null), null, millisecondsDelay, Timeout.Infinite);

    // Create and return a task that will be scheduled when the trigger fires.
    return tcs.Task.ContinueWith(_ =>
    {
        timer.Dispose();
        action();
    });
}

Cela peut simplifier les choses à l'excès, mais la source TaskCompletion permet d'attendre un événement. Étant donné que tcs.SetResult n'est défini que lorsque l'événement se produit, l'appelant peut attendre la tâche.

Regardez cette vidéo pour plus d'informations:

http://channel9.msdn.com/Series/Three-Essential-Tips-for-Async/Lucian03-TipsForAsyncThreadsAndDatabinding

Je scénario réel où j'ai utilisé TaskCompletionSourceest lors de la mise en œuvre d'une file d'attente de téléchargement. Dans mon cas, si l'utilisateur démarre 100 téléchargements, je ne veux pas tous les déclencher en même temps et donc au lieu de renvoyer une tâche structurée, je renvoie une tâche attachée àTaskCompletionSource . Une fois le téléchargement terminé, le thread qui fonctionne, la file d'attente termine la tâche.

Le concept clé ici est que je fais un découplage lorsqu'un client demande qu'une tâche soit démarrée à partir du moment où elle démarre réellement. Dans ce cas, parce que je ne veux pas que le client ait à gérer la gestion des ressources.

notez que vous pouvez utiliser async / wait dans .net 4 tant que vous utilisez un compilateur C # 5 (VS 2012+) voir ici pour plus de détails.

J'ai utilisé TaskCompletionSourcepour exécuter une tâche jusqu'à ce qu'elle soit annulée. Dans ce cas, c'est un abonné ServiceBus que je souhaite normalement exécuter aussi longtemps que l'application s'exécute.

public async Task RunUntilCancellation(
    CancellationToken cancellationToken,
    Func<Task> onCancel)
{
    var doneReceiving = new TaskCompletionSource<bool>();

    cancellationToken.Register(
        async () =>
        {
            await onCancel();
            doneReceiving.SetResult(true); // Signal to quit message listener
        });

    await doneReceiving.Task.ConfigureAwait(false); // Listen until quit signal is received.
}

TaskCompletionSourceest aux tâches comme WaitHandleau fil. Et nous pouvons donc utiliser TaskCompletionSource pour effectuer une signalisation précise .

Un exemple est ma réponse à cette question: délai ContentDialog après avoir cliqué sur OK