Почему TaskScheduler.Current является TaskScheduler по умолчанию?

Я думаю, что нынешнее поведение имеет смысл. Если я создам свой собственный планировщик задач и запущу какую-то задачу, которая запускает другие задачи, я, вероятно, захочу, чтобы все задачи использовали созданный мной планировщик.

Я согласен, что странно, что иногда при запуске задачи из потока пользовательского интерфейса используется планировщик по умолчанию, а иногда нет. Но я не знаю, как бы я сделал это лучше, если бы я его проектировал.

Что касается ваших конкретных проблем:

• Я думаю, что самый простой способ запустить новую задачу в указанном планировщике — это new Task(lambda).Start(scheduler). Недостатком этого является то, что вы должны указать аргумент типа, если задача что-то возвращает. TaskFactory.Create может определить тип для вас.
• Вы можете использовать Dispatcher.Invoke() вместо TaskScheduler.FromCurrentSynchronizationContext().

[EDIT] Следующее решает только проблему с планировщиком, используемым Task.Factory.StartNew.
Однако Task.ContinueWith имеет жестко запрограммированный TaskScheduler.Current. [/РЕДАКТИРОВАТЬ]

Во-первых, есть простое решение — смотрите внизу этого поста.

Причина этой проблемы проста: существует не только планировщик задач по умолчанию (TaskScheduler.Default), но и планировщик задач по умолчанию для TaskFactory (TaskFactory.Scheduler). Этот планировщик по умолчанию можно указать в конструкторе TaskFactory при его создании.

Однако TaskFactory позади Task.Factory создается следующим образом:

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 не имеет планировщика задач по умолчанию, будет использоваться текущий.

Так почему бы нам не столкнуться с 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.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 });

Я надеюсь, что смог помочь своим ответом, хотя уже довольно поздно :-)

Вместо Task.Factory.StartNew()

рассмотрите возможность использования: Task.Run()

Это всегда будет выполняться в потоке пула потоков. У меня была та же проблема, описанная в вопросе, и я думаю, что это хороший способ справиться с этим.

См. эту запись в блоге: http://blogs.msdn.com/b/pfxteam/archive/2011/10/24/10229468.aspx

Это вообще не очевидно, Дефолт не дефолт! И документации серьезно не хватает.

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, если они этого хотят.

Я только что потратил часы, пытаясь отладить странную проблему, когда моя задача была запланирована в потоке пользовательского интерфейса, хотя я этого не указывал. Оказалось, что проблема была именно в том, что продемонстрировал ваш пример кода: продолжение задачи было запланировано в потоке пользовательского интерфейса, и где-то в этом продолжении была запущена новая задача, которая затем была запланирована в потоке пользовательского интерфейса, потому что текущая выполняемая задача имела конкретный TaskScheduler набор.

К счастью, это весь код, которым я владею, поэтому я могу исправить это, убедившись, что мой код указывает TaskScheduler.Default при запуске новых задач, но если вам не так повезло, я бы предложил использовать Dispatcher.BeginInvoke вместо планировщика пользовательского интерфейса.

Итак, вместо:

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())));

Хотя это немного менее читабельно.