Question

任务并行库很棒，在过去的几个月里我经常使用它。但是，有些事情让我很烦恼：TaskScheduler.Current是默认的任务调度程序，而不是TaskScheduler.Default。在文档和样本中，这一点绝对不是很明显。

Current可能导致细微的错误，因为它的行为正在改变，这取决于你是否在另一个任务中。这是不容易确定的。

假设我正在编写异步方法库，使用基于事件的标准异步模式来表示原始同步上下文的完成情况，这与XxxAsync方法在.NET Framework中完全相同（例如DownloadFileAsync ）。我决定使用任务并行库来实现，因为使用以下代码实现此行为非常容易：

public class MyLibrary {
    public event EventHandler SomeOperationCompleted;

    private void OnSomeOperationCompleted() {
        var handler = SomeOperationCompleted;
        if (handler != null)
            handler(this, EventArgs.Empty);
    }

    public void DoSomeOperationAsync() {
                    Task.Factory
                        .StartNew
                         (
                            () => Thread.Sleep(1000) // simulate a long operation
                            , CancellationToken.None
                            , TaskCreationOptions.None
                            , TaskScheduler.Default
                          )
                        .ContinueWith
                           (t => OnSomeOperationCompleted()
                            , TaskScheduler.FromCurrentSynchronizationContext()
                            );
    }
}

到目前为止，一切运作良好。现在，让我们在WPF或WinForms应用程序中单击按钮调用此库：

private void Button_OnClick(object sender, EventArgs args) {
    var myLibrary = new MyLibrary();
    myLibrary.SomeOperationCompleted += (s, e) => DoSomethingElse();
    myLibrary.DoSomeOperationAsync();
}

private void DoSomethingElse() {
    ...
    Task.Factory.StartNew(() => Thread.Sleep(5000)/*simulate a long operation*/);
    ...
}

此处，编写库调用的人选择在操作完成时启动新的Task。没什么不寻常的。他或她遵循网络上随处可见的示例，只需使用Task.Factory.StartNew而不指定TaskScheduler（并且在第二个参数中没有轻松的重载来指定它）。 DoSomethingElse方法在单独调用时工作正常，但是一旦事件调用它，UI就会冻结，因为TaskFactory.Current将重用我的库继续中的同步上下文任务调度程序。

找出这个可能需要一些时间，特别是如果第二个任务调用被隐藏在一些复杂的调用堆栈中。当然，一旦你知道一切是如何工作的，这里的修复很简单：总是为你期望在线程池上运行的任何操作指定TaskScheduler.Default。但是，第二个任务可能是由另一个外部库启动的，不了解这种行为，并且在没有特定调度程序的情况下天真地使用StartNew。我期待这种情况很常见。

在我的脑袋缠绕之后，我无法理解编写TPL的团队选择使用TaskScheduler.Current而不是TaskScheduler.Default作为默认值：

根本不明显，Default不是默认值！文档严重缺乏。
Current使用的真实任务调度程序取决于调用堆栈！使用此行为很难维护不变量。
使用StartNew指定任务调度程序很麻烦，因为您必须首先指定任务创建选项和取消令牌，从而导致长且不易读的行。这可以通过编写扩展方法或创建使用TaskFactory的{{1}}来缓解。
捕获调用堆栈会产生额外的性能成本。
当我真的希望某个任务依赖于另一个父运行任务时，我更喜欢明确指定它以简化代码阅读而不是依赖于调用堆栈魔术。

我知道这个问题可能听起来很主观，但我找不到一个好的客观论证，为什么这种行为就像它一样。我确定我在这里遗漏了一些东西：这就是我转向你的原因。

Answer 1

我认为目前的行为是有道理的。如果我创建自己的任务调度程序，并启动一些启动其他任务的任务，我可能希望所有任务都使用我创建的调度程序。

我同意奇怪的是，有时从UI线程启动任务会使用默认调度程序，有时则不会。但我不知道如果我正在设计它，我将如何做得更好。

关于您的具体问题：

我认为在指定的调度程序上启动新任务的最简单方法是new Task(lambda).Start(scheduler)。这样做的缺点是，如果任务返回某些内容，则必须指定类型参数。 TaskFactory.Create可以为您推断出类型。
您可以使用Dispatcher.Invoke()代替TaskScheduler.FromCurrentSynchronizationContext()。

Answer 2

[编辑] 以下仅解决了Task.Factory.StartNew使用的调度程序的问题但是，Task.ContinueWith有一个硬编码TaskScheduler.Current。 [/编辑]

首先，有一个简单的解决方案 - 请参阅本文的底部。

这个问题背后的原因很简单：不仅有默认任务调度程序（TaskScheduler.Default），还有TaskFactory（TaskFactory.Scheduler）的默认任务调度程序。可以在创建TaskFactory时在TaskFactory的构造函数中指定此默认调度程序。

但是，Task.Factory后面的s_factory = new TaskFactory();创建如下：

TaskFactory

如您所见，未指定null; TaskScheduler.Default用于默认构造函数 - 最好是TaskFactory.DefaultScheduler（文档说明使用“当前”具有相同的后果）。
这再次导致private TaskScheduler DefaultScheduler { get { if (m_defaultScheduler == null) return TaskScheduler.Current; else return m_defaultScheduler; } }（私人成员）的实施：

NullReferenceExceptions

在这里你应该看到能够识别出这种行为的原因：由于Task.Factory没有默认的任务调度程序，所以将使用当前的任务调度程序。

那么为什么当没有任务正在执行时（即我们当前没有TaskScheduler），我们不会遇到public static TaskScheduler Current { get { Task internalCurrent = Task.InternalCurrent; if (internalCurrent != null) { return internalCurrent.ExecutingTaskScheduler; } return Default; } }？原因很简单：

TaskScheduler.Current

TaskScheduler.Default默认为TaskScheduler。

我认为这是一个非常不幸的实施。

但是，有一个简单的解决方法：我们只需将Task.Factory的默认TaskScheduler.Default设置为TaskFactory factory = Task.Factory; factory.GetType().InvokeMember("m_defaultScheduler", BindingFlags.SetField | BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.DeclaredOnly, null, factory, new object[] { TaskScheduler.Default });

{{1}}

我希望我可以帮助我的回应虽然已经很晚了： - ）

Answer 3

而不是Task.Factory.StartNew()

考虑使用：Task.Run()

这将始终在线程池线程上执行。我刚才遇到了问题中描述的相同问题，我认为这是处理这个问题的好方法。

请参阅此博客条目： http://blogs.msdn.com/b/pfxteam/archive/2011/10/24/10229468.aspx

Answer 4

根本不明显，默认不是默认值！文档严重缺乏。

Default是默认值，但并不总是Current。

正如其他人已经回答的那样，如果您希望在线程池上运行任务，则需要通过将Current调度程序传递到Default来显式设置TaskFactory调度程序或StartNew方法。

由于您的问题涉及到一个库，我认为答案是您不应该做任何会改变库外代码所见的Current调度程序的事情。这意味着您在举起TaskScheduler.FromCurrentSynchronizationContext()事件时不应使用SomeOperationCompleted。相反，做这样的事情：

public void DoSomeOperationAsync() {
    var context = SynchronizationContext.Current;
    Task.Factory
        .StartNew(() => Thread.Sleep(1000) /* simulate a long operation */)
        .ContinueWith(t => {
            context.Post(_ => OnSomeOperationCompleted(), null);
        });
}

我甚至认为您不需要在Default调度程序上明确启动任务 - 让调用者确定Current调度程序是否需要。

Answer 5

我花了好几个小时试图调试一个奇怪的问题，即我的任务是在UI线程上安排的，即使我没有指定它。事实证明问题正是你的示例代码所展示的：在UI线程上安排了任务延续，并且在该延续的某个地方，启动了一个新任务，然后在UI线程上安排了该任务，因为当前正在执行的任务有一个具体TaskScheduler设置。

幸运的是，这是我拥有的所有代码，所以我可以通过确保我的代码在开始新任务时指定TaskScheduler.Default来修复它，但如果你不是那么幸运，我的建议是使用{{1而不是使用UI调度程序。

所以，而不是：

Dispatcher.BeginInvoke

尝试：

var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();
var task = Task.Factory.StartNew(() => Thread.Sleep(5000));
task.ContinueWith((t) => UpdateUI(), uiScheduler);

虽然可读性稍差。

为什么TaskScheduler.Current是默认的TaskScheduler？

5 个答案: