Microsoft のドキュメント「タスクの一覧を取り消す」のサンプルコードを試して気づいた話ですが、CancellationTokenSource.Cancel メソッドを実行した際、CancellationToken を受け取る非同期メソッドの Task.Status が Canceled に変わるタイミングが .NET Framework 4.8.1 と .NET 8.0 / 9.0 では異なるということがあったので、備忘録として書いておきます。

サンプルコードはこの記事の下の方に載せておきます。ターゲットフレームワークを .NET 8.0 または .NET 9.0 とした場合と、.NET Framework 4.8.1 とした場合のサンプルコードの動きの違いは、ダウンロードの途中で Enter キーを押してキャンセルをかけた時、後者では Main メソッドの中の try - catch ブロックが実行されないことです。

その原因は、タスク cancelTask の中の s_cts.Cancel(); が実行された時、CancellationToken を受け取る非同期メソッドの Task.Status が Canceled に変わるタイミングが異なるからです。

.NET Framework 4.8.1 の場合、Cancel メソッドの実行で即 Task.Status が WaitingForActivation から Canceled に変わります。

一方、.NET 8.0 / 9.0 の場合、Cancel メソッドの実行では Task.Status は WaitingForActivation のまま変わりません。Task を await して初めて Status が Canceled に変わります。

以下にサンプルコードを検証した際の詳細を書いておきます。

.NET Framework 4.8.1

下の画像は、ターゲットフレームワークを .NET Framework 4.8.1 としたプロジェクトを Visual Studio 2022 でデバッグ実行した時のものです。

ダウンロード途中で（すなわち、SumPageSizesAsync メソッド内の foreach ループが回っているとき）Enter キーを押した結果、タスク cancelTask の中の s_cts.Cancel(); が実行され、ProcessUrlAsync メソッド内の非同期メソッドの実行がキャンセルされ、Task.WhenAny メソッドでその引数に設定されたタスク cancelTask と sumPageSizesTask の内 sumPageSizesTask が先に完了と判断され、await による待機を抜け、次の行の if 文に制御が移ったところです。

その結果、if 文の条件 finishedTask == cancelTask は false となるので try - catch ブロックは実行されません。その際に気を付けなければならないのは、await sumPageSizesTask; は実行されないので OperationCanceledException はスローされないということです。

なので、下に載せたサンプルコードのように、OperationCanceledException を catch して何らかの処置を行いたい場合、そのためのコードを追加する必要があります。

ただし、ダウンロードが完了してから（すなわち SumPageSizesAsync メソッド内の foreach ループを抜けて CancellationToken を引数に取る非同期メソッドがすべて完了してから）タスク cancelTask の中の s_cts.Cancel(); が実行された場合は様子が違ってきます。タスク cancelTask の方が先に完了したと判断され、try - catch ブロックは実行されます。（実際にそれを試すには、foreach ループの後に 1 行 await Task.Delay(3000); を追加して、そこで止まっているときに Enter キーを押してみてください）

.NET 8.0 / 9.0

ターゲットフレームワークを .NET 8.0 または 9.0 としたプロジェクトで上と同様にデバッグを行うと以下の画像のようになります。

ダウンロード途中で Enter キーを押すとタスク cancelTask 内の s_cts.Cancel(); が実行されるのですが、その時点では ProcessUrlAsync メソッド内の非同期メソッドの実行がキャンセルされないのか、タスク sumPageSizesTask の Status は WaitingForActivation になっています。一方、タスク cancelTask の Status は RanToCompletion となり、Task.WhenAny メソッドでその引数に設定されたタスク cancelTask が先に完了したと判断され、await による待機を抜け、次の行の if 文に制御が移っています。

この場合、if 分の条件 finishedTask == cancelTask は true となるので try - catch ブロックが実行されます。try 句の中の await sumPageSizesTask; により OperationCanceledException がスローされ、catch 句の中のコードが実行されます。

タスク sumPageSizesTask の Status が WaitingForActivation から Canceled に変わるのは try 句の中の await sumPageSizesTask; で await による待機が終わった時点になります。

以下の画像を見てください。上の画像の if 文でブレークポイントで止まったところからステップ実行して、await sumPageSizesTask; でスローされた OperationCanceledException を catch したところです。sumPageSizesTask の Status が Canceled に変わっています。

try 句の中の await sumPageSizesTask; の行で例外がスローされるので、その下の Console.WriteLine("Download task completed before cancel request was processed."); はスキップされます。このメッセージは「Enter キーが押されたがキャンセルが間に合わずダウンロードが完了してしまった」という意味なのですが、手動で Enter キーを押してこのメッセージを表示するのは無理があるので注意してください。

このメッセージが表示されることを試すには、SumPageSizesAsync メソッド内の foreach ループの後に 1 行 await Task.Delay(3000); を追加して、そこで止まっているときに Enter キーを押してみてください。その時点では CancellationToken を渡された非同期メソッドの実行は終わっているので、タスク cancelTask の中の s_cts.Cancel(); の実行では OperationCanceledException 例外はスローされません。結果、await sumPageSizesTask; の下の行の Console.WriteLine("Download task completed before cancel request was processed."); が実行されます。

.NET Framework 4.8.1 の場合の s_cts.Cancel(); の実行で CancellationToken を渡された非同期メソッドの実行が即キャンセルされるという動きの方が自分としては納得できるのですが、何らかの理由で .NET 8.0（もっと前からかも）で変更したのでしょうか？

そのあたりの説明がある Microsoft のドキュメントは見つけられませんでしたが、とにかく違いがあるということは覚えておいた方が良さそうと思って、備忘録として残しておくことにした次第です。

以下に、上に述べた検証に用いた Microsoft ドキュメントのサンプルコードを載せておきます。

using System.Diagnostics;

class Program
{
    static readonly CancellationTokenSource s_cts = new CancellationTokenSource();

    static readonly HttpClient s_client = new HttpClient
    {
        MaxResponseContentBufferSize = 1_000_000
    };

    static readonly IEnumerable<string> s_urlList = new string[]
    {
            "https://learn.microsoft.com",
            "https://learn.microsoft.com/aspnet/core",
            "https://learn.microsoft.com/azure",
            "https://learn.microsoft.com/azure/devops",
            "https://learn.microsoft.com/dotnet",
            "https://learn.microsoft.com/dynamics365",
            "https://learn.microsoft.com/education",
            "https://learn.microsoft.com/enterprise-mobility-security",
            "https://learn.microsoft.com/gaming",
            "https://learn.microsoft.com/graph",
            "https://learn.microsoft.com/microsoft-365",
            "https://learn.microsoft.com/office",
            "https://learn.microsoft.com/powershell",
            "https://learn.microsoft.com/sql",
            "https://learn.microsoft.com/surface",
            "https://learn.microsoft.com/system-center",
            "https://learn.microsoft.com/visualstudio",
            "https://learn.microsoft.com/windows",
            // "https://learn.microsoft.com/maui" 404 エラーになるのでコメントアウト
    };

    static async Task Main()
    {
        Console.WriteLine("Application started.");
        Console.WriteLine("Press the ENTER key to cancel...\n");

        Task cancelTask = Task.Run(() =>
        {
            while (Console.ReadKey().Key != ConsoleKey.Enter)
            {
                Console.WriteLine("Press the ENTER key to cancel...");
            }

            Console.WriteLine("\nENTER key pressed: cancelling downloads.\n");
            s_cts.Cancel();
        });

        Task sumPageSizesTask = SumPageSizesAsync();

        Task finishedTask = await Task.WhenAny(new[] { cancelTask, sumPageSizesTask });
        if (finishedTask == cancelTask)
        {
            // wait for the cancellation to take place:
            try
            {
                await sumPageSizesTask;
                Console.WriteLine("Download task completed before cancel request was processed.");
            }
            catch (OperationCanceledException)
            {
                Console.WriteLine("Download task has been cancelled.");
            }
        }

        Console.WriteLine("Application ending.");
    }

    static async Task SumPageSizesAsync()
    {
        var stopwatch = Stopwatch.StartNew();

        int total = 0;
        foreach (string url in s_urlList)
        {
            int contentLength = await ProcessUrlAsync(url, s_client, s_cts.Token);
            total += contentLength;
        }

        stopwatch.Stop();

        Console.WriteLine($"\nTotal bytes returned:  {total:#,#}");
        Console.WriteLine($"Elapsed time:          {stopwatch.Elapsed}\n");
    }

    static async Task<int> ProcessUrlAsync(string url, 
                                                 HttpClient client, 
                                                 CancellationToken token)
    {
        HttpResponseMessage response = await client.GetAsync(url, token);

        // .NET Framework 4.8.1 の ReadAsByteArrayAsync には
        // CancellationToken を引数に取るオーバーロードはない
        // ので下の引数 token は削除すること
        byte[] content = await response.Content.ReadAsByteArrayAsync(token);

        Console.WriteLine($"{url,-60} {content.Length,10:#,#}");

        return content.Length;
    }
}

先の記事「Task.Delay メソッドの謎」の続きです。謎はまだ完全には解けていませんが、その後調べて分かったことをこの記事に書きます。(先の記事に続けて書くと長くなりすぎるので分けました)

まず、Microsoft のドキュメント Task.Delay メソッドの説明に書いてある "遅延後に完了するタスクを作成します" の「タスクを作成」とはどういうことかですが、それについては .NET Framework 4.8 ライブラリのソースコード Task.cs の Task.Delay メソッドを調べてみました。

ソースコードを簡略化して書くと以下のようになります。つまり、Task.Delay で System.Threading.Timer のインスタンスを生成し、それを Task クラスにラップして返しています。

public class Task
{
    public static Task Delay(int millisec)
    {
        var promise = new DelayPromise();

        promise.Timer = new System.Threading.Timer(
                            state => ((DelayPromise)state).Complete(),
                            promise,
                            millisec,
                            Timeout.Infinite);
        return promise;            
    }

    private sealed class DelayPromise : Task
    {
        internal System.Threading.Timer Timer;

        internal void Complete()
        {
            if (Timer != null) Timer.Dispose();
        }
    }
}

という訳で Task.Delay メソッドで作成されたタスクの実体は System.Threading.Timer ということは分かりました。

次なる謎は先の記事の Task.Delay を使ったサンプルコードの動きです。

先の記事のサンプルコードは、メインスレッドで 100 個の WorkAsync メソッドを同期的に順次開始し、await Task.WhenAll ですべての WorkAsync メソッドの完了を待機するという形になっています。WorkAsync メソッドには await Task.Delay(3000) が含まれています。サンプルコードを簡略化して書くと以下のようになります。

public async Task<string> WorkAsync(int number)
{
    // ・・・省略・・・
    string retunVlaue = $"n = {number}, ThreadID: {id}" +
                        $", start: {start:ss.fff}, ";
 
    await Task.Delay(3000);

    // ・・・省略・・・
    return retunVlaue;
}

public async Task ForLoopAsync()
{
    // ・・・省略・・・
 
    Task<string>[] taskResults = new Task<string>[100];

    taskResults[0] = WorkAsync(0);
    taskResults[1] = WorkAsync(1);
    taskResults[2] = WorkAsync(2);
    // ・・・省略・・・
    taskResults[99] = WorkAsync(99);
 
    await Task.WhenAll(taskResults);
 
    foreach (Task<string> result in taskResults)
    {
        Console.WriteLine(result.Result);
    }

    // ・・・省略・・・
}

ForLoopAsync メソッドを実行すると、まず最初に WorkAsync(0) が実行され、その中の await Task.Delay(3000) で 3 秒待機してから WorkAsync(0) が完了し、次の WorkAsync(1) メソッドの実行に進むというように、同期的に順次 WorkAsync(0) から WorkAsync(99) まで実行されていくと思っていました。

その場合、アプリ全体の実行時間は 3 秒 x 100 = 5 分かかるはずです。しかしながら、実際は先に記事に書いたように 3 秒少々で全体が完了します。そこが謎だったのですが、デバッガを使って追いかけてみて謎が分かりました。

最初に WorkAsync(0) が実行されその中の await Task.Delay(3000); の行が実行されると、そこで 3 秒待機するのではなく直ちに次の WorkAsync(1) が呼ばれます。WorkAsync(1) の中の await Task.Delay(3000); の行が実行されると直ちに次の WorkAsync(2) が呼ばれるというように、一気に最後の WorkAsync(99) まで呼ばれるところまで進んでから await Task.Delay(3000); で待機します。

そして 3 秒の待機が終わると、WorkAsync(0) から WorkAsync(99) の await Task.Delay(3000); の次の行から return retunVlaue; までが一気に実行され、戻り値が Task<string> 型の配列 taskResults に代入されるという動きになります。

それゆえアプリ全体の実行時間は 3 秒少々しかかからないという結果になったようです。

サンプルコードの実行時間が 3 秒少々しかかかからなかった理由は分かりましたが、なぜ WorkAsync(0) から WorkAsync(99) のそれぞれで同期的に 3 秒待機してから次に進むのではなく、WorkAsync メソッドが最初から最後まで一気に呼ばれてから待機するのかは分かりません。

ちなみに、Task.WhenAll は使わないで各 WorkAsync メソッドに await を付与すると各メソッドの実行時に 3 秒待機してから次のメソッドが実行されるようになります。

string[] stringResults = new string[100];
stringResults[0] = await WorkAsync(0);
stringResults[1] = await WorkAsync(1);
stringResults[2] = await WorkAsync(2);
// ・・・省略・・・
stringResults[99] = await WorkAsync(99);

Task.WhenAll が影響しているような気がしますが、どうも自分には Task とか Timer に関する理解が致命的に欠けているようで、そのあたりメカニズムが分かりません。勉強が足りないようです。

以下はオマケです。

上のような自作 Task.Delay メソッドのコードを実装しても期待通りには動きませんでした。原因不明ですが、いろいろ試した結果とそれに基づく想像を備忘録として以下に書いておきます。

当たり前ですが、.NET Framework ライブラリを使って await Task.Delay(3000) とした場合はそこで 3 秒待機した後次の行に進みます。ところが、上の自作コードを使って Task.Delay(3000) というように「タスクを作成」してそれを await するとそこで止まってしまいます。（）

DelayPromise コンストラクタを呼び出して作成した Task なので「タスクを作成」した時点では TaskStatus は Created になります。その後 TaskStatus は Created のまま変わらないので await するとそこで止まってしまうということのようです。 (TaskStatus が RanToCompletion にならないと await は抜け出せないようです)

Task を Start するコードを追加すると、TaskStatus は WaitingToRun ⇒ Running ⇒ RanToCompletion と変わっていきますが await で待機しません。設定した遅延時間の 3 秒後に Complete コールバックに制御は飛んでくるので Task は期待通り動いているようですが、.NET Framework の制御を外れて勝手に動いているという感じです。

ただし、普通に Task コンストラクタで Task を生成して Start する場合、例えば以下のようにすると .NET Framework の制御下で動くようです。（Start しないと TaskStatus は Created のまま変わらず、await で止まってしまうのは上と同じです）

Task t = new Task(() =>
    { 
        Console.WriteLine("new Task"); 
        Thread.Sleep(3000); 
    });

t.Start();
await t;

t.Start(); で TaskStatus は WaitingToRun となり、Thread.Sleep(3000); を抜けて Task が完了すると RanToCompletion に変わります。上のコードのように await t; とすると期待通りそこで待機します。await で待機中に Task が完了し TaskStatus が RanToCompletion に変わってから await を抜けるという感じです。

ちなみに、.NET Framework ライブラリの Task.Delay は Start せずとも TaskStatus は WaitingForActivation になって、設定した遅延時間の後 RanToCompletion になります。await で待機した場合は、待機中に Task が完了して TaskStatus が RanToCompletion になると await を抜けるようです。

ライブラリの場合は、await による .NET Framework の制御が働くよう、ライブラリに定義してある下記の Task のコンストラクタで設定される m_stateFlags が良しなに計らってくれているような気がします。（想像＆気がするだけです）

internal Task()
{
    m_stateFlags = TASK_STATE_WAITINGFORACTIVATION | 
                   (int)InternalTaskOptions.PromiseTask;
}

Microsoft のドキュメントの Task.Delay メソッドの説明には "遅延後に完了するタスクを作成します。 Creates a task that will complete after a time delay." と書いてあります。

その「タスクを作成」とはどういう意味でしょう？　作成されたタスクは何がどのように動かしているのでしょう？　色々調べたのですが分かりませんでした。謎が解けたら追記しますが、とりあえず今まで調べたことを整理して書いておきます。 ⇒ 謎はまだ完全には解けていませんが、その後調べて分かったことを別の記事「Task.Delay メソッドの謎 (続き)」に書きました 。

とにかく、Task.Delay メソッドが作成した「遅延後に完了するタスク」は作成後動いていることは間違いなさそうです。（そんなの当たり前？）

なぜなら、(1) Task.Delay メソッドの第 1 引数に与えられた時間通りに遅延＆完了しますが、そもそもタスクが動いてなければ開始も完了もないはず、(2) 第 2 引数で CancellationToken を渡すオーバーロードではキャンセルすると TaskCanceledException がスローされるのですが、それには常にキャンセル通知をチェックする必要があるはず・・・ですから。

では、一体何がその「遅延後に完了するタスク」を動かしているのでしょう？

以前は Task.Delay メソッドが「遅延後に完了するタスク」を作成して、スレッドプールからスレッドを取得し、作成したタスクを実行すると思っていたのですが、以下のコードで検証した結果を見る限りそうではなさそうな感じです。

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Collections.Generic;
using System.Linq;

namespace ConsoleAppWenAllParallelFor
{
    class Program
    {
        static async Task Main(string[] args)
        {
            int minWorker; // ワーカースレッドの最小数（PC のコア数と同じ）
            int minIOC;    // 非同期 I/O スレッドの最小数
            ThreadPool.GetMinThreads(out minWorker, out minIOC);
            Console.WriteLine($"minWorker: {minWorker}, minIOC: {minIOC}");

            int maxWorker; // ワーカー スレッドの最大数
            int maxIOC;    // 非同期 I/O スレッドの最大数
            ThreadPool.GetMaxThreads(out maxWorker, out maxIOC);
            Console.WriteLine($"maxWorker: {maxWorker}, maxIOC: {maxIOC}");

            var prog = new Program();
            await prog.ForLoopAsync();
        }

        // 非同期メソッド
        public async Task<string> WorkAsync(int number)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            DateTime start = DateTime.Now;
            string retunVlaue = $"n = {number}, ThreadID: {id}" +
                                $", start: {start:ss.fff}, ";

            // ここで 3 秒遅延
            await Task.Delay(3000);            

            // 検証用。詳細は後述
            //await Task.Run(() => Thread.Sleep(3000));
            //await Task.Run(() => Task.Delay(3000).Wait());

            DateTime end = DateTime.Now;
            TimeSpan diff = start - end;
            retunVlaue += $"end: {end:ss.fff}, timespan: {diff:s\\.fff}";
            return retunVlaue;
        }

        // 非同期メソッド WorkAsync を for ループで 100 実行
        public async Task ForLoopAsync()
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            DateTime start = DateTime.Now;
            Console.WriteLine($"Main Thread ID = {id}, " +
                $"ForLoopAsync 開始: {start:ss.fff}");

            Task<string>[] taskResults = new Task<string>[100];
            for (int i = 0; i < 100; i++)
            {
                int n = i;
                taskResults[n] = WorkAsync(n);
            }

            await Task.WhenAll(taskResults);

            foreach (Task<string> result in taskResults)
            {
                Console.WriteLine(result.Result);
            }

            DateTime end = DateTime.Now;
            TimeSpan diff = start - end;
            Console.WriteLine($"Main Thread ID = {id}, " +
                $"終了: {end:ss.fff}, 所要時間: {diff:s\\.fff}");
        }
    }
}

上のコードの実行結果は以下のようになります。画像には n = 20 までしか示していませんがその後 n = 99 まで続きます。

n = 0 ～ 99 の start が 00.065 ～ 00.082 の範囲 (17ms）に入っており、end はすべて同じ時刻 03.122 になり、アプリ全体の所要時間は Task.Delay(3000) による遅延とほぼ同じ 3.072 秒という結果でした。

ということは、17ms の間に for ループで 100 個の WorkAsync メソッドが同期的に開始され、それぞれの WorkAsync メソッドの中の Task.Dealy(3000) で 3000ms 遅延後に完了するタスクが作成・実行され、await でタスクの終了を待機し、待機が終わって WorkAsync メソッドが時刻 03.122 に 100 個同時に終わり（1ms 以下の差はあるかも）、全体のアプリが 3.072 秒で完了したということになります。ホントかなぁ・・・という気はしますが結果の画像はそう言っているようです。

結果から、Task.Dealy(3000) で作成された「遅延後に完了するタスク」100 個はスレッドプールからスレッドを取得して実行されたという訳ではなく、単に 3 秒止まっていただけというように見えます。

スレッドプールのスレッドを使う場合、先の記事「タスク並列ライブラリ (TPL) その 2」で書きましたように、スレッドプールから一度に取得できるスレッドの数は限られているので（検証に使った PC ではデフォルトで 8）、スレッドの取得にかかる時間を考えるとアプリ全体が 3.072 秒で完了ということはないからです。

（Task.Dealy が作成する「遅延後に完了するタスク」は特別で、スレッドプールから一度に 100 個スレッドを取得できるということなら話は別ですが）

Task.Dealy を実行したスレッドが、Task.Dealy が作成した「遅延後に完了するタスク」を実行することはもちろんなさそうです。そもそも、Thread.Sleep と違って、スレッドをブロックしないようにするのが Task.Delay のはずですから。

という訳で、一体何がどのようにTask.Dealy が作成した「遅延後に完了するタスク」を実行しているのかが謎です。今後の課題ということで、調べて何か分かったら追記します。

ちなみにですが、上のサンプルコードの、

await Task.Delay(3000);

を、

await Task.Run(() => Thread.Sleep(3000));

に代えると結果が違ってきます。Task.Run で Thread.Sleep(3000) をスレッドプールで実行するタスクとしてキューに並べるので、OS がスレッドプールからスレッドを取得して Thread.Sleep(3000) を実行し、その際スレッドは 3 秒ブロックされます。結果は以下のようになります。

n = 0 ～ 99 の start が 23.257 ～ 23.312 の範囲 (55ms）に入っていますが、end は 26.228 ～ 43.305 となっており、Thread.Sleep(3000) を実行するためのスレッドの取得に時間がかかっていることが分かります。アプリ全体の所要時間は 20.072 秒という結果でした。

もう一つオマケで書いておきます。 上の Thread.Sleep(3000) を Task.Delay(3000).Wait() に代えると少し様子が違ってきます。

n = 0 ～ 99 の start は 03.056 ～ 03.114 の範囲 (58ms）、end は 06.553 ～ 28.576 の範囲、全体の所要時間は 25.540 秒という結果でした。Thread.Sleep に比べて全体の所要時間が長くなることと、n = 5, 9 に必要以上の時間スレッドを解放できない特異点的なものがあるのが気になります。