AFAIK,它所知道的只是在某些时候,它的SetResult或SetException方法被调用来完成通过Task属性暴露的Task<T>。

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

我在这里看到了一个例子:

如果我需要一种方法来异步执行Func<T>,并有一个任务<T> 来表示这个操作。

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 ?


当前回答

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

使用缓存就是一个很好的例子。你可以有一个GetResourceAsync方法,它在缓存中查找所请求的资源,并在找到资源时立即返回(不使用新线程,通过使用TaskCompletionSource)。只有在没有找到资源的情况下,我们才会使用一个新的线程,并使用Task.Run()检索它。

这里可以看到一个代码示例:如何有条件地使用任务异步运行代码

其他回答

在这篇来自“。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();
    });
}

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

使用缓存就是一个很好的例子。你可以有一个GetResourceAsync方法,它在缓存中查找所请求的资源,并在找到资源时立即返回(不使用新线程,通过使用TaskCompletionSource)。只有在没有找到资源的情况下,我们才会使用一个新的线程,并使用Task.Run()检索它。

这里可以看到一个代码示例:如何有条件地使用任务异步运行代码

这可能是过于简化的事情,但TaskCompletion源代码允许等待一个事件。从tc开始。SetResult只在事件发生时设置,调用者可以等待任务。

观看这段视频了解更多:

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

我主要在只有基于事件的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的真实场景是在实现下载队列时。在我的情况下,如果用户开始100次下载,我不想一次性将它们全部关闭,所以不是返回一个分层任务,而是返回一个附加到TaskCompletionSource的任务。一旦下载完成,处理队列的线程就完成了任务。

这里的关键概念是,当客户端请求启动任务时,我正在将其与实际启动任务时分离。在这种情况下,因为我不希望客户端必须处理资源管理。

注意,只要你使用的是c# 5编译器(VS 2012+),你就可以在。net 4中使用async/await来了解更多细节。