69

Task Parallel Library 很棒，在过去的几个月里我经常使用它。但是，有一些事情真的让我很困扰：这TaskScheduler.Current是默认任务调度程序，而不是TaskScheduler.Default. 乍一看，这在文档或示例中绝对不明显。

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

假设我正在编写一个异步方法库，使用基于事件的标准异步模式在原始同步上下文上发出信号完成信号，就像 XxxAsync 方法在 .NET Framework 中所做的一样（例如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因为您必须首先指定任务创建选项和取消令牌，导致行长、可读性差。这可以通过编写扩展方法或创建TaskFactory使用Default.
  • 捕获调用堆栈会带来额外的性能成本。
  • 当我真的希望一个任务依赖于另一个正在运行的父任务时，我更愿意明确指定它以简化代码阅读，而不是依赖调用堆栈魔术。

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

4

5 回答 5

20

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

我同意有时从 UI 线程启动任务使用默认调度程序而有时不使用这很奇怪。但我不知道如果我在设计它，我会如何让它变得更好。

关于您的具体问题：

  • 我认为在指定调度程序上启动新任务的最简单方法是new Task(lambda).Start(scheduler). 这样做的缺点是，如果任务返回某些内容，您必须指定类型参数。TaskFactory.Create可以为您推断类型。
  • 您可以使用Dispatcher.Invoke()而不是使用TaskScheduler.FromCurrentSynchronizationContext().
于 2011-07-23T14:22:22.630 回答
8

[编辑] 以下仅解决Task.Factory.StartNew.
但是，Task.ContinueWith有一个硬编码的TaskScheduler.Current. [/编辑]

首先，有一个简单的解决方案可用 - 请参阅这篇文章的底部。

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

但是，TaskFactory后面Task.Factory是这样创建的：

s_factory = new TaskFactory();

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

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

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

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

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

TaskScheduler.Current默认为TaskScheduler.Default.

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

但是，有一个简单的解决方法：我们可以简单地将默认设置TaskScheduler为Task.FactoryTaskScheduler.Default

TaskFactory factory = Task.Factory;
factory.GetType().InvokeMember("m_defaultScheduler", BindingFlags.SetField | BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.DeclaredOnly, null, factory, new object[] { TaskScheduler.Default });

我希望我能帮助我的回复，虽然已经很晚了:-)

于 2011-11-20T13:39:40.083 回答
5

代替Task.Factory.StartNew()

考虑使用：Task.Run()

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

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

于 2013-08-28T07:40:08.010 回答
3

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

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

于 2013-02-27T17:56:46.680 回答
0

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

幸运的是，这是我拥有的所有代码，所以我可以通过确保我的代码TaskScheduler.Default在开始新任务时指定来修复它，但如果你不那么幸运，我的建议是使用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())));

虽然它的可读性有点差。

于 2013-05-31T09:30:11.553 回答