什么时候应该使用TaskCompletionSource <T>？

AFAIK，它所知道的只是在某个时候，它的SetResult或SetException方法被调用以Task<T>通过其Task属性完成公开。

换句话说，它充当a Task<TResult>及其完成的生产者。

我在这里看到了示例：

如果我需要一种异步执行Func并有一个Task来表示该操作的方法。

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

*如果我没有，可以使用Task.Factory.StartNew-但我确实有Task.Factory.StartNew。

题：

可有人请举例相关的情景解释直接到TaskCompletionSource 而不是一个假想中，我没有的情况 Task.Factory.StartNew？

当仅基于事件的API可用时（例如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;
}

因此，与C＃5 async关键字一起使用时，它特别有用。

以我的经验，TaskCompletionSource非常适合将旧的异步模式包装到现代async/await模式。

我能想到的最有益的例子是使用Socket。它具有旧的APM和EAP模式，但没有和具有的awaitable Task方法。TcpListenerTcpClient

我个人在NetworkStream班上有几个问题，更喜欢原始课程Socket。由于我也喜欢该async/await模式，因此我SocketExtender创建了一个扩展类，它为创建了几个扩展方法Socket。

所有这些方法都利用TaskCompletionSource<T>来包装异步调用，如下所示：

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

我传递socket到BeginAccept方法，使我获得稍许的性能提升出来的没有扯起本地参数的编译器。

那么这一切的美丽：

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

对我来说，一个典型的使用场景TaskCompletionSource是，当我的方法不一定必须执行耗时的操作时。它允许我们做的是选择要使用新线程的特定情况。

一个很好的例子是使用缓存。您可以有一个GetResourceAsync方法，该方法在高速缓存中查找所请求的资源，并在找到资源后立即返回（不使用，使用新线程TaskCompletionSource）。仅在找不到资源的情况下，我们才想使用一个新线程并使用进行检索Task.Run()。

在此处可以看到一个代码示例：如何使用任务有条件地异步运行代码

在本博客中，Levi Botelho描述了如何使用TaskCompletionSource来为Process编写异步包装，以便您可以启动它并等待其终止。

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

及其用法

await RunProcessAsync("myexecutable.exe");

似乎没有人提及，但是我想单元测试也可以被认为是现实生活。

我发现TaskCompletionSource在使用异步方法模拟依赖项时很有用。

在实际的测试程序中：

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

在单元测试中：

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

毕竟，TaskCompletionSource的这种用法似乎是“不执行代码的Task对象”的另一种情况。

TaskCompletionSource用于创建不执行代码的Task对象。在现实世界中，TaskCompletionSource是I / O绑定操作的理想选择。这样，您将获得任务的所有好处（例如，返回值，连续性等），而不会在操作期间阻塞线程。如果您的“函数”是受I / O约束的操作，则不建议使用新Task阻塞线程。而是使用TaskCompletionSource，您可以创建一个从属任务，以仅指示您的I / O绑定操作何时完成或出现故障。

这篇来自“ .NET的并行编程”博客的文章中有一个真实的例子，并给出了不错的解释。您确实应该阅读它，但是无论如何这是一个摘要。

博客文章显示了两种实现：

“一种用于创建“延迟”任务的工厂方法，这些任务实际上不会在用户提供的某些超时发生之前进行调度。”

所示的第一个实现基于，Task<>并且有两个主要缺陷。第二个实现文章继续通过使用减轻这些影响TaskCompletionSource<>。

这是第二个实现：

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

这可能简化了事情，但TaskCompletion源允许一个人等待事件。由于仅在事件发生后才设置tcs.SetResult，因此调用方可以等待任务。

观看此视频以获取更多见解：

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

我使用的现实世界场景TaskCompletionSource是实现下载队列时。在我的情况下，如果用户开始进行100次下载，则我不想立即将其全部解雇，因此，我不返回分散的任务，而是返回附加到的任务TaskCompletionSource。下载完成后，正在使用队列的线程将完成任务。

这里的关键概念是，当客户要求从实际启动任务开始时，我就将其解耦了。在这种情况下，因为我不希望客户端不得不处理资源管理。

请注意，只要您使用的是C＃5编译器（VS 2012+），就可以在.net 4中使用async / await 。有关更多详细信息，请参见此处。

我曾经TaskCompletionSource运行过一个任务，直到它被取消。在这种情况下，我通常要在应用程序运行期间一直运行ServiceBus订户。

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

TaskCompletionSource任务和WaitHandle线程一样。因此，我们可以TaskCompletionSource 用来执行精确的信号发送。

一个示例是我对此问题的答案：单击确定后，ContentDialog延迟