4

如果这个问题是基于意见的，请提前道歉。此处已经讨论了缺少不能捕获执行上下文的Task.Yield版本。显然，此功能在 Async CTP 的早期版本中以某种形式存在，但由于它很容易被滥用而被删除。

IMO，这样的功能可能像Task.Run它本身一样容易被滥用。这就是我的意思。想象一下，有一个可等待的SwitchContext.YieldAPI 调度 ThreadPool 上的继续，因此执行将始终在与调用线程不同的线程上继续。我可以在下面的代码中使用它，它从 UI 线程开始一些 CPU 密集型工作。我认为这是一种在池线程上继续 CPU 密集型工作的便捷方式：

class Worker
{
    static void Log(string format, params object[] args)
    {
        Debug.WriteLine("{0}: {1}", Thread.CurrentThread.ManagedThreadId, String.Format(format, args));
    }

    public async Task UIAction()
    {
        // UI Thread
        Log("UIAction");

        // start the CPU-bound work
        var cts = new CancellationTokenSource(5000);
        var workTask = DoWorkAsync(cts.Token); 

        // possibly await for some IO-bound work 
        await Task.Delay(1000);
        Log("after Task.Delay");

        // finally, get the result of the CPU-bound work
        int c = await workTask;
        Log("Result: {0}", c);
    }

    async Task<int> DoWorkAsync(CancellationToken ct)
    {
        // start on the UI thread
        Log("DoWorkAsync");

        // switch to a pool thread and yield back to the UI thread
        await SwitchContext.Yield();
        Log("after SwitchContext.Yield");
        // continue on a pool thread

        int c = 0;
        while (!ct.IsCancellationRequested)
        {
            // do some CPU-bound work on a pool thread: counting cycles :)
            c++;
            // and use async/await too
            await Task.Delay(50);
        }

        return c;
    }

}

现在，没有SwitchContext.Yield,DoWorkAsync将如下所示。它以异步委托和任务嵌套的形式增加了一些额外的复杂性：

async Task<int> DoWorkAsync(CancellationToken ct)
{
    // start on the UI thread
    Log("DoWorkAsync");

    // Have to use async delegate
    // Task.Run uwraps the inner Task<int> task
    return await Task.Run(async () =>
    {
        // continue on a pool thread
        Log("after Task.Yield");

        int c = 0;
        while (!ct.IsCancellationRequested)
        {
            // do some CPU-bound work on a pool thread: counting cycles :)
            c++;
            // and use async/await too
            await Task.Delay(50);
        }

        return c;
    });
}

也就是说，实现SwitchContext.Yield实际上可能非常简单并且（我敢说）高效：

public static class SwitchContext
{
    public static Awaiter Yield() { return new Awaiter(); }

    public struct Awaiter : System.Runtime.CompilerServices.INotifyCompletion
    {
        public Awaiter GetAwaiter() { return this; }

        public bool IsCompleted { get { return false; } }

        public void OnCompleted(Action continuation)
        {
            ThreadPool.QueueUserWorkItem((state) => ((Action)state)(), continuation);
        }

        public void GetResult() { }
    }
}

所以，我的问题是，为什么我应该更喜欢第一个版本的第二个版本DoWorkAsync，为什么使用SwitchContext.Yield被认为是一种不好的做法？

4

1 回答 1

5

您不必放入. _ 考虑这个选项：Task.RunDoWorkAsync

public async Task UIAction()
{
    // UI Thread
    Log("UIAction");

    // start the CPU-bound work
    var cts = new CancellationTokenSource(5000);
    var workTask = Task.Run(() => DoWorkAsync(cts.Token)); 

    // possibly await for some IO-bound work 
    await Task.Delay(1000);
    Log("after Task.Delay");

    // finally, get the result of the CPU-bound work
    int c = await workTask;
    Log("Result: {0}", c);
}

这导致代码具有更清晰的意图。DoWorkAsync是一种自然同步的方法，所以它有一个同步签名。DoWorkAsync既不知道也不关心 UI。UIAction关心 UI 线程的Task.Run.

作为一般规则，尽量将任何Task.Run调用“推送”出库方法。

于 2013-09-13T11:25:58.753 回答