.NET Framework 4.5 以降で利用できる async / await を使って非同期で実行されるタスクをキャンセルする方法についていろいろ調べたので備忘録として書いておきます。

基本は Microsoft のドキュメント「マネージド スレッドのキャンセル」に書いてあります。が、それを読んだだけでは自分の頭では理解できなかったので、実際に自分の手を動かしてコードを書いて試してみました。

Microsoft のドキュメントに書いてありますが、キャンセル処理を実装するための一般的なパターンは以下の通りだそうです。

1. CancellationTokenSource クラスのインスタンスを作成する。
2. CancellationTokenSource.Token プロパティで CancellationToken を取得し、キャンセルをリッスンするタスクに渡す。 　
3. タスクにはキャンセル通知を適切に処置するコードを実装しておく。
4. CancellationTokenSource.Cancel メソッドを呼び出し、リッスンしているタスクにキャンセルを通知する。
5. キャンセル通知を受けたタスクは、あらかじめ実装されているコードに従ってキャンセル処置を行う。 　

タスクがキャンセルの通知を受けとるには、(1) ポーリング、(2) コールバックの登録、(3) 待機ハンドルの待機という方法があるそうです。

参考にした Microsoft のドキュメントには (1) ～ (3) のコード例の紹介がありますが、コンソールアプリのものでちょっとピンとこなかったので、Windows Forms アプリで実装してみました。

ベースは @IT の記事「WPF／Windowsフォーム：時間のかかる処理をバックグラウンドで実行するには？」のコードです。それに手を加えて［キャンセル］ボタンクリックでキャンセルできるようにしています。

コードは以下の通りです。この記事の上に貼った画像を表示したものです。

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsAsyncTest
{
    public partial class Form4 : Form
    {
        private CancellationTokenSource cts = null;
        
        public Form4()
        {
            InitializeComponent();
            EableButtons();
            toolStripStatusLabel1.Text = "";
            toolStripProgressBar1.Value = 0;
        }

        // (1) ポーリングによるリッスン。進捗表示なし
        private async void button1_Click(object sender, EventArgs e)
        {
            DisableButtons();
            toolStripStatusLabel1.Text = "処理中…";
            toolStripProgressBar1.Value = 0;
            string result = "";
            bool isCanceled = false;

            using (this.cts = new CancellationTokenSource())
            {
                CancellationToken token = this.cts.Token;
                try
                {
                    result = await DoWorkAsync(100, token);
                }
                catch (OperationCanceledException)
                {
                    isCanceled = true;
                }
            }

            // 処理結果の表示
            if (isCanceled)
            {
                toolStripStatusLabel1.Text = "キャンセル";
                toolStripProgressBar1.Value = 0;
            }
            else
            {
                toolStripStatusLabel1.Text = result;
                toolStripProgressBar1.Value = 100;
            }

            EableButtons();
        }

        // 時間のかかる処理を行うメソッド
        // ポーリングによるリッスン用。進捗表示なし
        private async Task<string> DoWorkAsync(
            int n, 
            CancellationToken token)
        {
            for (int i = 1; i <= n; i++)
            {
                token.ThrowIfCancellationRequested();
                await Task.Delay(100);
            }

            return "全て完了";
        }

        // (2) ポーリングによるリッスン。進捗表示あり
        private async void button2_Click(object sender, EventArgs e)
        {
            DisableButtons();

            var p = new Progress<int>(ShowProgress);

            using (this.cts = new CancellationTokenSource())
            {
                CancellationToken token = this.cts.Token;
                try
                {
                    await DoWorkAsync(p, 100, token);
                }
                catch (OperationCanceledException)
                {
                    // 必要なら何らかの処置
                }
            }

            EableButtons();
        }

        // 時間のかかる処理を行うメソッド
        // ポーリングによるリッスン用。進捗表示あり
        private async Task<string> DoWorkAsync(
            IProgress<int> progress,
            int n,
            CancellationToken token)
        {
            for (int i = 1; i <= n; i++)
            {
                token.ThrowIfCancellationRequested();
                await Task.Delay(100);

                int percentage = i * 100 / n; // 進捗率
                progress.Report(percentage);
            }

            return "全て完了";
        }

        // 進捗をプログレスバーとラベルに表示するコールバック
        // UIスレッドで呼び出される
        private void ShowProgress(int percent)
        {
            toolStripStatusLabel1.Text = percent + "％完了";
            toolStripProgressBar1.Value = percent;
        }

        // キャンセルボタン
        private void button3_Click(object sender, EventArgs e)
        {
            if (this.cts == null) return;

            cts.Cancel();
        }

        // (3) コールバックの登録によるリッスン
        // Microsoft のドキュメントをまねて Web アクセスをシミュ
        // レートする自作クラス MyWebClient を定義して使う。
        // MyWebClient の定義はこのサンプルコードの下の方にあり

        private MyWebClient client;
        
        private async void button4_Click(object sender, EventArgs e)
        {
            DisableButtons();

            // Timer（デザイン画面で Form にドラッグ＆ドロップした
            // もの）を利用して定期的に進捗状況を取得して表示。
            // 
            // System.Windows.Forms.Timer を利用するにはメッセージ
            // ループの実行が必要なので注意。メッセージループは UI
            // スレッドで実行される。await は UI スレッドをブロック
            // しない。従い、await で待機中でも Timer は動く

            this.timer1.Interval = 100;

            using (this.cts = new CancellationTokenSource())
            {
                CancellationToken token = this.cts.Token;
                this.client = new MyWebClient();
                token.Register(async () => { 
                    await this.client.CancelAsync(); 
                    this.timer1.Stop(); }) ;
                this.timer1.Start();
                string result = await this.client.GetStringAsync(100);

                // キャンセルせず完了する場合 Timer はここで止めること。
                // 止めると、プログレスバーの表示も 100 になる前に止ま
                // ってしまうので、ここで設定が必要。
                if (this.client.Progress >= 100)
                { 
                    this.timer1.Stop();
                    toolStripStatusLabel1.Text = this.client.Progress + "％完了";
                    toolStripProgressBar1.Value = this.client.Progress;
                }
            }

            EableButtons();
        }

        // 進捗を表示するためのイベントハンドラ
        private void timer1_Tick(object sender, EventArgs e)
        {
            // ここは UI スレッドで実行される
            toolStripStatusLabel1.Text = this.client.Progress + "％完了";
            toolStripProgressBar1.Value = this.client.Progress;
        }      

        // (4) 待機ハンドルを使用したリッスン
        private async void button5_Click(object sender, EventArgs e)
        {
            DisableButtons();

            var p = new Progress<int>(ShowProgress);

            using (this.cts = new CancellationTokenSource())
            {
                CancellationToken token = this.cts.Token;
                try
                {
                    await DoWorkAsync3(p, 100, token);
                }
                catch (OperationCanceledException)
                {
                    // 必要なら何らかの処置
                }
            }

            EableButtons();
        }

        // 待機ハンドルを使用したリッスン用
        static ManualResetEventSlim mres = new ManualResetEventSlim(false);

        // 時間のかかる処理を行うメソッド
        private async Task<string> DoWorkAsync3(
            IProgress<int> progress,
            int n,
            CancellationToken token)
        {
            // 時間のかかる処理
            for (int i = 1; i <= n; i++)
            {
                token.ThrowIfCancellationRequested();

                try
                {
                    // Microsoft のドキュメントをまねて mres.Wait(token); と
                    // するとここでフリーズしてしまう。「CancellationToken
                    // が信号を受信するまで、現在のスレッドをブロックします」
                    // ということだから当たり前か・・・
                    // mres.Wait(10, token); にすると 10 ミリ秒待って動くよう
                    // になるが、それでは意味がなさそう
                    mres.Wait(10, token);
                }
                catch (OperationCanceledException)
                {
                    // 必要なら何らかの処置
                    throw;
                }

                await Task.Delay(100);

                int percentage = i * 100 / n;
                progress.Report(percentage);
            }

            return "全て完了";
        }

        // ボタンの Enable / Disable を切り替えるヘルパメソッド
        private void DisableButtons()
        {
            button1.Enabled = false;
            button2.Enabled = false;
            button3.Enabled = true;
            button4.Enabled = false;
            button5.Enabled = false;
        }

        private void EableButtons()
        {
            button1.Enabled = true;
            button2.Enabled = true;
            button3.Enabled = false;
            button4.Enabled = true;
            button5.Enabled = true;
        }
    }

    // Microsoft のドキュメントをまねて Web にアクセスする
    // WebClient をシミュレートする自作クラス
    public class MyWebClient
    {
        private bool isCanceled = false;
        private int progress = 0;

        public async Task<string> GetStringAsync(int n)
        {
            for (int i = 1; i <= n; i++)
            {
                if (isCanceled) break;

                await Task.Delay(100);

                progress = i * 100 / n;
            }

            if (isCanceled)
            {
                return "キャンセル";
            }
            else
            {
                return "全て完了";
            }
        }

        public async Task CancelAsync()
        {
            // 通信・処理に要する時間
            await Task.Delay(100);
            isCanceled = true;
        }

        public int Progress
        {
            get { return progress; }
        }
    }
}

待機ハンドルを使用する方法については、そもそも使い方が間違っている（上のような Windows Forms アプリで使うものではない？）ような気がしますが、せっかくいろいろ考えたので、とりあえず書いておきました。

上のコードのコメントに書きましたが、Microsoft のドキュメントをまねて mres.Wait(token); を使うと、そこでブロックされてフリーズしてしまいます。mres.Wait(10, token); にすると 10 ミリ秒待って一応は動くようになるのですが、それは意味がなさそうです。今後の検討課題ということで・・・

先の記事「await と Task.Result によるデッドロック」の続きです。この記事には、先の記事で述べたデッドロックを回避する方法を書きます。

(5) ConfigureAwait

Task.ConfigureAwait(Boolean) メソッドを使って、先の記事で述べた Task.Result プロパティを使ったコードにおけるデッドロックを回避することができます。（UI がフリーズするのは避けられませんが）

Microsoft のドキュメント「非同期プログラミングのベストプラクティス」に以下の説明があります。

"既定では、未完了の Task を待機するときは、現在のコンテキストがキャプチャされ、Task が完了するときのメソッドの再開に使用されます。 ・・・中略・・・ GUI アプリケーションと ASP.NET アプリケーションには、一度に実行するコードを 1 つのチャンクに限定する SynchronizationContext があります。await が完了するときは、キャプチャしたコンテキスト内で async メソッドの残りを実行しようとします。"

初めは Task.Result で待機しているスレッドを await 終了後に使おうとするからデッドロックが起こるのだろうと思っていましたが、それでは ASP.NET のケースが説明できません。ASP.NET で非同期にする目的はスレッドプールのスレッドの有効利用で、await 前までに使っていたスレッドはスレッドプールに戻し、await が完了後の処理はスレッドプールから新たにスレッドを取得して行いますので（ASP.NET の場合 await 前後でスレッドが異なるということ）。

少なくとも ASP.NET の場合、使われるスレッドが await 前後で同じかどうかはデッドロックに関係なく、上に書いた「一度に実行するコードを 1 つのチャンクに限定する」が関係しているようです。

ということは、GUI アプリ / ASP.NET アプリどちらにせよ、await が完了した後の残りの処理を、await で待機する際にキャプチャした「現在のコンテキスト」ではなく、別のコンテキストで行えばデッドロックにはならないはずです。

Microsoft のドキュメント「非同期プログラミングのベストプラクティス」に以下のように書いてあります。

"ConfigureAwait(continueOnCapturedContext: false) を追加すると、デッドロックが回避されます。この場合、await が完了するとき、スレッドプールのコンテキスト内で async メソッドの残り処理の実行が試みられます。このメソッドは完了でき、返されたタスクを完了するため、デッドロックは発生しません。"

というわけで、ConfigureAwait メソッドを使って以下のコードで試してみました。上の画像を表示したものです。

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsAsyncTest
{
    public partial class Form3 : Form
    {
        public Form3()
        {
            InitializeComponent();
        }

        // Task.Result 使用
        private void button1_Click(object sender, EventArgs e)
        {
            label1.Text = "UI スレッド、ID=" + 
                Thread.CurrentThread.ManagedThreadId;

            label2.Text = TimeCosumingMethod().Result;

            label1.Text += " / ID=" +
                Thread.CurrentThread.ManagedThreadId;
        }

        // await 使用
        private async void button2_Click(object sender, EventArgs e)
        {
            label1.Text = "UI スレッド、ID=" +
                Thread.CurrentThread.ManagedThreadId;

            label2.Text = await TimeCosumingMethod();

            label1.Text += " / ID=" +
                Thread.CurrentThread.ManagedThreadId;
        }

        private async Task<string> TimeCosumingMethod()
        {
            await Task.Delay(3000).ConfigureAwait(
                continueOnCapturedContext: false);

            return "TimeCosumingMethod の戻り値、ID=" +
                Thread.CurrentThread.ManagedThreadId;
        }
    }
}

上のコードのように ConfigureAwait(continueOnCapturedContext: false) を追加すると、TimeCosumingMethod メソッドで await Task.Delay(3000) が完了した後の残りの処理は、await で待機する際にキャプチャした「現在のコンテキスト」ではなく、スレッドプールのコンテキスト内で実行されるためデッドロックは回避できるということのようです。

上の画像を見てください。UI スレッドの ManagedThreadId（上の画像では ID=1）と TimeCosumingMethod メソッドの残りを実行したスレッド（上の画像では ID=4）が異なっています。

ただし、Task.Result を使う方は UI がフリーズするのは避けられません。一方、await を使う方は UI はフリーズしません（メッセージループは常に動いていて、マウスのクリックなどのユーザーイベントを処理して UI に反映してくれます）。

理由は、Task.Result は UI スレッドをブロックして TimeCosumingMethod メソッドが完了するのを同期的に待機するのに対して、await は呼び出し元に処理を戻して非同期的に待機するからのようです。

@IT の記事「第2回　非同期メソッドの構文」に以下の説明があります。

"await という名前から、「渡した非同期タスクが完了するまで、呼び出し元スレッドをブロックして待機する」というように感じるかもしれないが、実際はそうではない。await 演算子の意味は、「待っているタスクがまだ完了していない場合、メソッドの残りをそのタスクの『継続』として登録して呼び出し元に処理を戻し、タスクが完了したら登録しておいた継続処理を実行すること」なので注意が必要だ。"

Windows Forms アプリでは「Application.Run メソッド」によって UI スレッドで標準のメッセージループの実行が開始されるそうです。

なので、Task.Result を使う方は、UI スレッドがブロックされている間（上のコード例では約 3 秒間）はメッセージループは動いておらず、マウスのクリックなどのユーザーイベントには無反応（UI がフリーズ状態）になるということのようです。

先の記事「非同期プログラミング」の続きで、非同期プログラミングに関して調べたことを備忘録的に書いたものです。

(4) デッドロック

先の記事の「(3) 訳が分からなかった話」に書いた Task.Result プロパティを使ったコードを Windows Forms のような GUI アプリに使うとデッドロックになります。（注: 先の記事のコンソールアプリではデッドロックになることはありません。理由後述）

Windows Forms アプリのコードでそのあたりを分かりやすく書くと以下のような感じです。コメントに「// デッドロック」と書いた方のメソッドを実行するとデッドロックが発生してアプリは固まってしまいます。

using System;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsAsyncTest
{
    public partial class Form3 : Form
    {
        public Form3()
        {
            InitializeComponent();
        }

        // デッドロック        
        private void button1_Click(object sender, EventArgs e)
        {
            label1.Text = "";
            string str = TimeCosumingMethod().Result;
            label1.Text = str;
        }

        // 正常動作
        private async void button2_Click(object sender, EventArgs e)
        {
            label1.Text = "";
            string str = await TimeCosumingMethod();
            label1.Text = str;
        }

        private async Task<string> TimeCosumingMethod()
        { 
            await Task.Delay(3000);
            return "TimeCosumingMethod の戻り値";
        }
    }
}

ちなみに ASP.NET Web アプリでも、Task.Result を使った同様なコードで、デッドロックが発生してアプリは固まってしまいます。

その理由は Microsoft のドキュメント「非同期プログラミングのベストプラクティス」の「すべて非同期にする」のセクションに書いてあります。

・・・が、自分はその説明を読んでもよく分かりませんでした。（汗）　自分の独断と偏見による個人的解釈まじりですが、以下のようなことになっているのであろうと想像しています。

Microsoft のドキュメント「Task<TResult>.Result プロパティ」と「Task.Wait メソッド」に以下の説明があります。

"Task.Result プロパティの get アクセサーにアクセスすると、非同期操作が完了するまで呼び出し元のスレッドがブロックされます。これは、Wait メソッドを呼び出すことと同じです。"

"Wait は、現在のタスクが完了するまで呼び出し元のスレッドを待機させる同期メソッドです。"

また、Microsoft のドキュメント「非同期プログラミングのベストプラクティス」に以下の説明があります。

"既定では、未完了の Task を待機するときは、現在のコンテキストがキャプチャされ、Task が完了するときのメソッドの再開に使用されます。 ・・・中略・・・ GUI アプリケーションと ASP.NET アプリケーションには、一度に実行するコードを 1 つのチャンクに限定する SynchronizationContext が使われます。await が完了するときは、キャプチャしたコンテキスト内で async メソッドの残りを実行しようとします。しかし、このコンテキストは既にその内部にスレッドを持っており、これは asyncメソッドが完了するのを (同期して) 待機します。それらは、それぞれもう一方を待機し、デッドロックを引き起こします。"

ということで、以下のようになっているのだろうと思いました。

1. まず、上のコードの「デッドロック」とコメントしてある button1_Click メソッドに注目。その中の Task.Result プロパティを使っているところで、呼び出し元のスレッド（UI スレッド）は TimeCosumingMethod メソッドが完了するのを同期的に待機する。
   
   注： 上に書いた公式ドキュメントには Task.Result で「非同期操作が完了するまで呼び出し元のスレッドがブロックされます」とありますが、実際にコードを書いて検証してみると、呼び出し先の TimeCosumingMethod メソッドの await の前まで呼び出し元のスレッド（上の例では UI スレッド）で実行され、await の行に制御が移るとそこでデッドロックになります。
2. 呼び出された TimeCosumingMethod メソッドに制御が移り、その中の await Task.Delay(3000); の await で待機するとき現在のコンテキストがキャプチャされ、await が完了した後はキャプチャしたコンテキストで残りを実行しようとする。 　
3. Windows Forms アプリでは、先の記事の「(2) Windows Forms アプリの ManagedThreadId」の例のとおり、スレッドの ManagedThreadId の値は変わらない。即ち、await で待機するときキャプチャする「現在のコンテキスト」および await 完了後に使われるキャプチャしたコンテキストでは同じ UI スレッドが使われ続けている。
4. ということは、TimeCosumingMethod メソッドで await 完了後に使われる「キャプチャした現在のコンテキスト」のスレッドは、ステップ 1 で待機しているスレッドと同じということになる。
5. ステップ 1 で待機しているスレッドは TimeCosumingMethod メソッドが完了しないと解放されないが、TimeCosumingMethod メソッド内の await が完了した時点では解放されていないので、その場所で開放されるのを永遠に待つことになってデッドロックに陥る。 　 　

Windows Forms のような GUI アプリの場合は、実際にコードを書いての検証結果から、上に書いた通り UI スレッドが使われるのを確認しており、上記 1 ～ 5 で説明になっていると思います。

が、ASP.NET のケースが上記 1 ～ 5 では説明できません。ASP.NET で非同期にする目的はスレッドプールのスレッドの有効利用で、await 前までに使っていたスレッドはスレッドプールに戻し、await 完了後の処理はスレッドプールから新たにスレッドを取得して行いますので。（ASP.NET の場合 await 前後でスレッドが異なるということです）

Windows Forms アプリと異なり、ASP.NET アプリでは使うスレッドがどうなっているかより「一度に実行するコードを 1 つのチャンクに限定する」の方が関係しているのかも。つまり、以下のようなことではないかと思っています。

まず、button1_Click メソッドの Task.Result で 1 つの同期ブロックが待機中。 呼び出された TimeCosumingMethod メソッドの await で待機する際にキャプチャされた「現在のコンテキスト」で await 完了後の同期処理を実行しようとする。しかし「現在のコンテキスト」では一度に実行するコードは 1 つのチャンクに限定されている。なので、Task.Result での待機が終わるまで await 完了後の同期処理は実行できない。結果デッドロックに陥る。

Windows Forms アプリでデッドロックする理由も上記のようなことなのかもしれません。が、今はこれ以上調べる気力がないです。もし何か分かったら追記します。

一方、コンソールアプリでは SynchronizationContext.Current は null になります。ということは await で待機する際にキャプチャできる「現在のコンテキスト」は存在せず、await 完了後の残りの処理は ASP.NET や Windows Forms アプリとは異なるようです。「非同期プログラミングのベストプラクティス」に以下のように書いてあります。

"コンソールアプリケーションでは、一度に 1 つのチャンクに制限する SynchronizationContext ではなく、スレッドプールを備えた SynchronizationContext を使用するため、await が完了するとき、スレッド プールのスレッドで async メソッドの残り処理のスケジュールが設定されます。"

上のステップ 2 のところで TimeCosumingMethod メソッドの残りを実行するのは「スレッドプールを備えた SynchronizationContext」になるようです。await で待機するときにキャプチャした「現在のコンテキスト」ではないのでデッドロックにならないということのようです。

最後に、上のサンプルコードで「// 正常動作」とコメントしたように Task.Result を使わないで 2 ヶ所で await した場合はデッドロックにはならないのは何故でしょう？

参考にさせていただ記事「ASP.NET の非同期でありがちな Deadlock を克服する」に以下のように書いてありました。

"AspNetSynchronizationContext に Post された 2 つの同期ブロックを、例の医者と患者の方式で順番に処理してくれるから"

・・・だそうですが、正直言ってその説明では分かりませんでした。（汗）　はっきりした理由が分かったら追記します。

ConfigureAwait によるデッドロックの回避に続く。