Почему RunContinuationsAsynchronous является недопустимым параметром продолжения для TaskFactory

Это было не так очевидно, как я ожидал.

Первое, что важно знать, это то, что перечисление TaskCreationOptions неофициально (не задокументировано, кроме как в коде, трудно себе представить изменение) подмножеством TaskContinuationOptions согласно этому комментарию в источнике:

/// <summary>
/// Specifies flags that control optional behavior for the creation and execution of tasks.
/// </summary>
// NOTE: These options are a subset of TaskContinuationsOptions, thus before adding a flag check it is
// not already in use.

Моя сильная гипотеза состоит в том, что для поддержания этой битовой совместимости RunContinuationsAsynchronously делается частью TaskContinuationsOptions, хотя на самом деле он используется только как TaskCreationOptions.

Например, когда мы используем Task.ContinueWith, мы передаем TaskContinuationsOptions, которые используются одновременно для двух целей:

1. Подмножество TaskCreationOptions будет извлечено и использовано при построении ContinuationTaskFromTask
2. Остальные параметры передаются в конструкцию ContinueWithTaskContinuation, которая инкапсулирует их вместе с ContinuationTaskFromTask.

Это сжатая версия исходного кода без проверки исключений:

private Task ContinueWith(Action<Task> continuationAction, TaskScheduler scheduler,
    CancellationToken cancellationToken, TaskContinuationOptions continuationOptions) {

    // OP Comment: 1 converison to TaskCreationOptions    
    CreationOptionsFromContinuationOptions(continuationOptions, out TaskCreationOptions creationOptions, out InternalTaskOptions internalOptions);

    Task continuationTask = new ContinuationTaskFromTask(
        this, continuationAction, null,
        creationOptions, internalOptions
    );

    // OP Comment: 2. creating the continuation which makes use of the ContinuationOptions that are just relevant for continuation
    ContinueWithCore(continuationTask, scheduler, cancellationToken, continuationOptions);
    // OP COMMENT: this calls inside new ContinueWithTaskContinuation(continuationTask, options, scheduler);

    return continuationTask;
}

Исключение, с которым я столкнулся, было в конструкторе TaskFactory, который допускает ОБА TaskCreationOptions и TaskContinuationOptions во всех своих перегрузках, поэтому последний аргумент рассматривается как «чистый» TaskContinuationOptions, поскольку пользователь может передать TaskCreationOptions отдельно.

Чтобы понять, почему это «не имеет смысла» (согласно комментариям в коде, который выдает исключение из вопроса), нам нужно посмотреть, как обычно вызываются продолжения.

Task имеет RunContinuationsметод, в котором исходный объект задачи определяет, запретить ли синхронное выполнение ее продолжений. (m_stateflags включает биты TaskCreationOptions, использованные для создания задачи)

bool canInlineContinuations =
           (m_stateFlags & (int)TaskCreationOptions.RunContinuationsAsynchronously) == 0 &&
           RuntimeHelpers.TryEnsureSufficientExecutionStack();

Потом звонит TaskContinuation.Run

void Run(Task completedTask, bool canInlineContinuationTask)

Здесь становится актуальным TaskContinuationOptions объекта продолжения задачи, но роль RunContinuationsAsynchronously уже выполнена (как TaskCreationOptions, а не TaskContinuationOptions), помогая определить значение аргумента canInlineContinuationTask.

Кроме того, согласно многочисленным комментариям Панайотиса Канавоса, значение TaskContinuationOptions.None уже официально определило асинхронный случай для TaskContinuationOptions:

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

Так зачем же добавлять лишнюю опцию, если не утверждать, что TaskContinuationOptions неофициально является расширенным набором TaskCreationOptions и может служить и тем, и другим в сигнатурах методов, как показано выше для ContinueWith?!

И наконец, асинхронный/синхронный не означает сопоставление 1 с 1 с «в другом потоке», «том же потоке». Как прокомментировал Панайотис Канавос, мы зависим от конкретного TaskScheduler (с которым связана задача) в том, будет ли продолжение в том же потоке или нет (например, в случае однопоточной реализации TaskScheduler)

Таким образом, асинхронный означает — поставленный в очередь, синхронный — выполняемый в режиме онлайн. Это ясно видно по названиям, использованным в последнем описанном методе ContinueWithTaskContinuation.Run.

// Either run directly or just queue it up for execution, depending
// on whether synchronous or asynchronous execution is wanted.
if (canInlineContinuationTask && // inlining is allowed by the caller
    (options & TaskContinuationOptions.ExecuteSynchronously) != 0) // synchronous execution was requested by the continuation's creator
{
    InlineIfPossibleOrElseQueue(continuationTask, needsProtection: true);
} else {
    try { continuationTask.ScheduleAndStart(needsProtection: true); } catch (TaskSchedulerException) {
        // No further action is necessary -- ScheduleAndStart() already transitioned the
        // task to faulted.  But we want to make sure that no exception is thrown from here.
    }
}