TaskEx.Yield(TaskScheduler)

Question

上个月，我问了以下问题，这些问题导致我学习了TaskEx.Yield

Can async methods have expensive code before the first 'await'?

但是，我后来意识到这个方法实际上会将所有后续代码提交给环境TaskScheduler。在真正的依赖注入精神中，我们的团队同意尽可能避免使用环境实例，所以我想知道是否可以显式指定要使用的TaskScheduler？

下面这样的东西就很棒了：

public static YieldAwaitable Yield(TaskScheduler taskScheduler)
{
    return new YieldAwaitable(taskScheduler);
}

然而，异步CTP的当前实施仅提供：

public static YieldAwaitable Yield()
{
    return new YieldAwaitable(SynchronizationContext.Current ?? TaskScheduler.Current);
}

以下内容会提供一个可接受的有效替代方案吗？

await Task.Factory.StartNew(() => { }, CancellationToken.None, TaskCreationOptions.None, this.TaskScheduler);

Answer 1

本着真正的依赖注入精神，我们的团队已经同意尽可能避免使用环境实例...

异步语言支持基于隐式调度上下文。我不认为这里需要依赖注入。如果需要，任何调用async方法的方法都可以提供自己的上下文。

您的替代方案：

await Task.Factory.StartNew(() => { }, CancellationToken.None, TaskCreationOptions.None, this.TaskScheduler);

不会像预期的那样工作。这将把noopλ排队到特定的TaskScheduler，然后在隐式调度上下文上恢复该方法。

异步CTP的早期版本确实提供了一种名为SwitchTo的“让出到另一个上下文”的方法。它was removed是因为它太容易被误用。

就我个人而言，我认为使用其隐式调度上下文来保留async代码会更干净一些，这是由其调用方法提供的。

附注:创建和安装自己的上下文(例如，用于测试)并不(太)困难。我编写了AsyncContext作为单元测试和控制台程序的简单调度上下文。Async CTP附带GeneralThreadAffineContext、WindowsFormsContext和WpfContext用于测试。其中任何一个都可以使用SynchronizationContext.SetSynchronizationContext进行安装。国际海事组织，DI是过度杀伤力。

Answer 2

对async的语言支持允许等待者控制自己的调度。在等待任务时会启动默认调度，但有许多方法可以通过更多的代码来更改默认行为。

具体地说，await的目的是执行以下操作：

可等待结果测试要查看可等待对象是否已“完成”(GetAwaiter().IsCompleted).

• If (并且仅当)可等待对象未完成，请请求它来调度方法的其余部分(GetAwaiter().OnCompleted(...))

• "Realize“

1. 。这意味着要么返回返回值，要么确保遇到的异常重新出现。

所以请记住，如果等待的人声称它是“完成的”，那么任何事情都不会被安排。

Task.Yield()很新颖，因为它返回了一个never done的可等待性，明确的目的是给你一种显式地暂时停止执行的方法，并立即调度其余的执行。它使用环境上下文，但有许多其他方法可以在没有环境上下文的情况下执行类似的操作。

重写默认行为的一个示例是，当您等待未完成的任务时，但使用ConfigureAwait(false)方法。ConfigureAwait(false)将任务包装在 always 使用默认任务调度程序的特殊可等待项中，有效地始终在线程池上恢复。“‘false”用于显式忽略环境同步上下文。

没有Task.Yield().ConfigureAwait(false)，但请考虑以下假设：

// ... A ...
await Task.Yield().ConfigureAwait(false);
// ... B ...

上述工作可以通过以下方式实现：

// ... A ...
await Task.Run(() => {
    // ... B ...
});

这里有更多的显式和嵌套，但考虑到正在发生的事情，这并不一定是坏事。部件'A‘总是在调用线程上运行，而部件'B’总是在线程池上运行。你应该如何看待A节和B节中的代码肯定是有区别的，因此在这两个部分之间有更多的卷曲应该会让人们在假设这两个部分是相同的上下文之前停顿一下。