¿Cuándo se debe usar TaskCompletionSource <T>?

AFAIK, todo lo que sabe es que en algún momento, es SetResultoSetException método está siendo llamado para completar el Task<T>expuestos a través de su Taskpropiedad.

En otras palabras, actúa como el productor de un Task<TResult> ay su finalización.

Vi aqui el ejemplo:

Si necesito una forma de ejecutar un Func de forma asincrónica y tengo una Tarea para representar esa operación.

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; 
}

Que podría usarse * si no tuviera Task.Factory.StartNew... Pero sí tengo Task.Factory.StartNew.

Pregunta:

Por favor alguien puede explicar por ejemplo, un escenario relacionado directamente a TaskCompletionSource y no a una hipotética situación en la que no tengo Task.Factory.StartNew?

Principalmente lo uso cuando solo hay disponible una API basada en eventos ( por ejemplo, sockets de 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;
}

Por lo tanto, es especialmente útil cuando se usa junto con la asyncpalabra clave C # 5 .

En mi experiencia, TaskCompletionSourcees ideal para envolver viejos patrones asincrónicos a los modernosasync/await patrón .

El ejemplo más beneficioso que se me ocurre es cuando trabajo Socket. Tiene la edad APM y patrones de EAP, pero no los awaitable Taskmétodos que TcpListenery TcpClienttienen.

Personalmente tengo varios problemas con la NetworkStreamclase y prefiero el crudo Socket. Siendo que también amo el async/awaitpatrón, creé una clase de extensión SocketExtenderque crea varios métodos de extensión Socket.

Todos estos métodos se utilizan TaskCompletionSource<T>para ajustar las llamadas asincrónicas de la siguiente manera:

    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;
    }

Paso socketelBeginAccept métodos de modo que consiga un ligero aumento de rendimiento del compilador no tener que levantar el parámetro local.

Entonces la belleza de todo:

 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();

Para mí, un escenario clásico para usar TaskCompletionSourcees cuando es posible que mi método no necesariamente tenga que hacer una operación que mucho tiempo. Lo que nos permite hacer es elegir los casos específicos en los que nos gustaría usar un nuevo hilo.

Un buen ejemplo de esto es cuando usa un caché. Puede tener un GetResourceAsyncmétodo, que busca en la memoria caché el recurso solicitado y devuelve de inmediato (sin usar un nuevo hilo, usando TaskCompletionSource) si se encontró el recurso. Solo si no se encontró el recurso, nos gustaría usar un nuevo hilo y recuperarlo usando Task.Run().

Aquí se puede ver un ejemplo de código: cómo ejecutar un código de forma asincrónica utilizando tareas

En esta publicación de blog , Levi Botelho describe cómo usar el TaskCompletionSourcepara escribir un contenedor asíncrono para un Proceso de modo que pueda iniciarlo y esperar su finalización.

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;
}

y su uso

await RunProcessAsync("myexecutable.exe");

Parece que nadie lo mencionó, pero supongo que las pruebas unitarias también se pueden considerar en la vida real .

Me parece TaskCompletionSourceútil cuando me burlo de una dependencia con un método asíncrono.

En el programa real bajo prueba:

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

En pruebas unitarias:

// 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);
  // ...
}

Después de todo, este uso de TaskCompletionSource parece otro caso de "un objeto Task que no ejecuta código".

TaskCompletionSource se usa para crear objetos Task que no ejecutan código. En escenarios del mundo real, TaskCompletionSource es ideal para operaciones vinculadas de E / S. De esta manera, obtiene todos los beneficios de las tareas (por ejemplo, valores de retorno, continuaciones, etc.) sin bloquear un hilo durante la operación. Si su "función" es una operación enlazada de E / S, no se recomienda bloquear un hilo usando una nueva Tarea . En cambio, utilizando TaskCompletionSource , puede crear una tarea esclava para indicar cuándo finaliza o falla su operación vinculada de E / S.

Hay un ejemplo del mundo real con una explicación decente en esta publicación del blog "Programación en paralelo con .NET" . Realmente deberías leerlo, pero de todos modos aquí hay un resumen.

La publicación del blog muestra dos implementaciones para:

"un método de fábrica para crear tareas" demoradas ", que no se programarán hasta que se produzca un tiempo de espera proporcionado por el usuario".

La primera implementación mostrada se basa Task<>y tiene dos fallas principales. La segunda publicación de implementación continúa para mitigar estos mediante el uso TaskCompletionSource<>.

Aquí está esa segunda implementación:

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();
    });
}

Esto puede simplificar demasiado las cosas, pero la fuente de TaskCompletion permite esperar en un evento. Como tcs.SetResult solo se establece una vez que se produce el evento, la persona que llama puede esperar la tarea.

Mire este video para obtener más información:

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

El escenario del mundo real en el que he utilizado TaskCompletionSourcees al implementar una cola de descarga. En mi caso, si el usuario inicia 100 descargas, no quiero dispararlas todas a la vez y, en lugar de devolver una tarea estratificada, devuelvo una tarea adjunta TaskCompletionSource. Una vez que se completa la descarga, el hilo que está funcionando la cola completa la tarea.

El concepto clave aquí es que me estoy desacoplando cuando un cliente solicita que se inicie una tarea desde que realmente se inicia. En este caso porque no quiero que el cliente tenga que lidiar con la gestión de recursos.

tenga en cuenta que puede usar async / await en .net 4 siempre que esté usando un compilador C # 5 (VS 2012+), consulte aquí para obtener más detalles.

Solía TaskCompletionSourceejecutar una tarea hasta que se cancela. En este caso, es un suscriptor de ServiceBus que normalmente quiero ejecutar mientras se ejecuta la aplicación.

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.
}

TaskCompletionSourcees para tareas como WaitHandlees para subprocesos. Y así podemos usar TaskCompletionSource para realizar una señalización precisa .

Un ejemplo es mi respuesta a esta pregunta: ContentDialog retraso después de hacer clic en Aceptar