CancellationToken.ThrowIfCancellationRequested 之后的故障与取消任务状态

Question

通常我不会发布带有答案的问题，但这次我想引起人们对我认为可能是一个晦涩但普遍的问题的关注。它是由this question 触发的，从那以后我查看了自己的旧代码，发现其中一些也受此影响。

下面的代码启动并等待两个任务，task1 和 task2，它们几乎相同。 task1 与 task2 的不同之处仅在于它运行一个永无止境的循环。 IMO，这两种情况对于一些执行 CPU 密集型工作的现实场景来说都是非常典型的。

using System;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication
{
    public class Program
    {
        static async Task TestAsync()
        {
            var ct = new CancellationTokenSource(millisecondsDelay: 1000);
            var token = ct.Token;

            // start task1
            var task1 = Task.Run(() =>
            {
                for (var i = 0; ; i++)
                {
                    Thread.Sleep(i); // simulate work item #i
                    token.ThrowIfCancellationRequested();
                }
            });

            // start task2
            var task2 = Task.Run(() =>
            {
                for (var i = 0; i < 1000; i++)
                {
                    Thread.Sleep(i); // simulate work item #i
                    token.ThrowIfCancellationRequested();
                }
            });  

            // await task1
            try
            {
                await task1;
            }
            catch (Exception ex)
            {
                Console.WriteLine(new { task = "task1", ex.Message, task1.Status });
            }

            // await task2
            try
            {
                await task2;
            }
            catch (Exception ex)
            {
                Console.WriteLine(new { task = "task2", ex.Message, task2.Status });
            }
        }

        public static void Main(string[] args)
        {
            TestAsync().Wait();
            Console.WriteLine("Enter to exit...");
            Console.ReadLine();
        }
    }
}

小提琴is here。输出：

{ 任务 = 任务 1，消息 = 操作已取消。状态 = 已取消 } {任务=任务2，消息=操作被取消。状态=故障}

为什么task1 的状态是Cancelled，而task2 的状态是Faulted？ 注意，在这两种情况下我都没有通过token 作为Task.Run 的第二个参数。

Answer 1

这里有两个问题。首先，将CancellationToken 传递给Task.Run API 总是一个好主意，除了让它对任务的lambda 可用。这样做会将令牌与任务相关联，并且对于正确传播由 token.ThrowIfCancellationRequested 触发的取消至关重要。

但这并不能解释为什么 task1 的取消状态仍然可以正确传播 (task1.Status == TaskStatus.Canceled)，而 task2 (task2.Status == TaskStatus.Faulted) 的取消状态却没有。

现在，这可能是聪明的 C# 类型推理逻辑可以违背开发人员意愿的极少数情况之一。 here 和 here 对此进行了详细讨论。综上所述，在task1的情况下，编译器会推断出以下Task.Run的覆盖：

public static Task Run(Func<Task> function)

而不是：

public static Task Run(Action action)

那是因为task1 lambda 没有自然的代码路径超出for 循环，所以它也可能是一个Func<Task> lambda，尽管它不是async 并且它没有返回任何东西。这是编译器比Action 更喜欢的选项。那么，Task.Run 的这种覆盖的使用就相当于：

var task1 = Task.Factory.StartNew(new Func<Task>(() =>
{
    for (var i = 0; ; i++)
    {
        Thread.Sleep(i); // simulate work item #i
        token.ThrowIfCancellationRequested();
    }
})).Unwrap();

Task.Factory.StartNew 返回一个Task<Task> 类型的嵌套任务，它通过Unwrap() 将unwrapped 转换为Task。 Task.Runis smart enough 在接受 Func<Task> 时自动进行这种解包。 未包装的 promise 样式任务正确地从其内部任务传播取消状态，Func<Task> lambda 将其作为 OperationCanceledException 异常抛出。 task2 不会发生这种情况，它接受 Action lambda 并且不创建任何内部任务。取消不会为 task2 传播，因为 token 尚未通过 Task.Run 与 task2 关联。

最后，这可能是task1 所期望的行为（当然不是task2），但我们不希望在这两种情况下都在后台创建嵌套任务。此外，task1 的这种行为很容易通过在 for 循环之外引入条件 break 来破坏。

task1 的正确代码应该是这样的：

var task1 = Task.Run(new Action(() =>
{
    for (var i = 0; ; i++)
    {
        Thread.Sleep(i); // simulate work item #i
        token.ThrowIfCancellationRequested();
    }
}), token);