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

Question

任务并行库非常棒，在过去的几个月里我经常使用它。然而，有件事确实困扰着我： TaskScheduler.Current 是默认任务调度程序，而不是 TaskScheduler.Default。乍一看，这在文档或示例中绝对不明显。

Current 可能会导致微妙的错误，因为它的行为会根据您是否在另一个任务中而变化。这是不容易确定的。

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

public class MyLibrary
{
    public event EventHandler SomeOperationCompleted;

    private void OnSomeOperationCompleted()
    {
        SomeOperationCompleted?.Invoke(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(); // trigger the event
        }, TaskScheduler.FromCurrentSynchronizationContext());
    }
}

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

private void Button_OnClick(object sender, EventArgs args)
{
    var myLibrary = new MyLibrary();
    myLibrary.SomeOperationCompleted += (s, e) => DoSomethingElse();
    myLibrary.DoSomeOperationAsync(); // call that triggers the event asynchronously
}

private void DoSomethingElse() // the event handler
{
    //...
    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 指定任务调度程序很麻烦，因为您必须首先指定任务创建选项和取消标记，从而导致行长且可读性较差。这可以通过编写扩展方法或创建使用 Default 的 TaskFactory 来缓解。
• 捕获调用堆栈会产生额外的性能成本。
• 当我确实希望一个任务依赖于另一个正在运行的父任务时，我更喜欢显式指定它以方便代码阅读，而不是依赖调用堆栈魔法。

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

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.Default）。调度程序）。
这个默认调度程序可以在创建时在 TaskFactory 的构造函数中指定。

然而，Task.Factory后面的TaskFactory是按如下方式创建的：

s_factory = new TaskFactory();

正如你所看到的，没有指定TaskScheduler； null 用于默认构造函数 - 更好的是 TaskScheduler.Default （文档指出使用“Current”具有相同的结果）。
这再次导致 TaskFactory.DefaultScheduler （私有成员）的实现：

private TaskScheduler DefaultScheduler 
{ 
   get
   { 
      if (m_defaultScheduler == null) return TaskScheduler.Current;
      else return m_defaultScheduler;
   }
}

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

那么，当当前没有任务正在执行时（即我们没有当前的 TaskScheduler），为什么我们不会遇到 NullReferenceExceptions 呢？
原因很简单：

public static TaskScheduler Current
{
    get
    {
        Task internalCurrent = Task.InternalCurrent;
        if (internalCurrent != null)
        {
            return internalCurrent.ExecutingTaskScheduler;
        }
        return Default;
    }
}

TaskScheduler.Current 默认为 TaskScheduler.Default。

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

不过，有一个简单的修复方法：我们可以简单地将 Task.Factory 的默认 TaskScheduler 设置为 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 });

我希望我能提供帮助我的回应虽然已经很晚了:-)

Answer 3

) 而不是 Task.Factory.StartNew()

考虑使用： Task.Run(

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

请参阅此博客条目：
Task.Run 与 Task.Factory.StartNew

Answer 4

一点也不明显，Default 不是默认！而且文档严重缺乏。

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

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

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

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 来修复它，但如果您没那么幸运，我的建议是使用 < code>Dispatcher.BeginInvoke 而不是使用 UI 调度程序。

所以，而不是：

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

尝试：

var uiDispatcher = Dispatcher.CurrentDispatcher;
var task = Task.Factory.StartNew(() => Thread.Sleep(5000));
task.ContinueWith((t) => uiDispatcher.BeginInvoke(new Action(() => UpdateUI())));

虽然它的可读性有点差。