SynchronizationContext とは何かを調べましたので、十分とは言えないまでも取りあえず分かった（分かった気になっただけかもしれませんが）ことを備忘録として書いておきます。

非同期プログラミングの勉強の際に、Microsoft のドキュメント「非同期プログラミングのベストプラクティス」を読んだのですが、詳しい説明なしでいきなり、

"・・・async void メソッドが開始されたときにアクティブだった SynchronizationContext で直接発生します・・・・・・未完了の Task を待機するときは、現在の "コンテキスト" がキャプチャされ、Task が完了するときのメソッドの再開に使用されます。この "コンテキスト" は現在の SynchronizationContext で・・・"

というように SynchronizationContext という言葉が出てきます。上記の他にも何か所かで出てくるのですが、非同期プログラミングを理解するのに重要なキーワードのようで、それが何かを理解してない自分には、そのドキュメントの内容が半分も理解できませんでした。

Microsoft のドキュメント「SynchronizationContext クラス」によると .NET Framework 2.0 の時代から存在していたようで、以下のように説明されています。

"同期コンテキストをさまざまな同期モデルに反映させるための基本機能を提供します。SynchronizationContext クラスは、同期なしのフリー スレッド コンテキストを提供する基本クラスです。このクラスで実装する同期モデルの目的は、共通言語ランタイムの非同期または同期の内部操作をさまざまな同期モデルで正しく動作させることです。"

残念ながらその説明では自分の頭では全く理解できません。なので、そのドキュメントからリンクが貼ってある MSDN マガジンの記事「並列コンピューティング - SynchronizationContext こそすべて」を読んでみました。

他に「async/await と SynchronizationContext」、「async/awaitと同時実行制御」、「ASP.NET の非同期でありがちな Deadlock を克服する」という記事を参考にさせていただきました。これらは Microsoft のドキュメントに比べれば少し分かりやすかったです。

上の記事を読んで、SynchronizationContext とは何かを理解する上で重要と思った点を以下にまとめておきます。無知ゆえの独断と偏見による個人的解釈も含まれているので注意してください。

1. マルチスレッドプログラムでは、あるスレッドから別のスレッドに作業単位を受け渡す必要が生じることがよくある。SynchronizationContext クラスはそれを支援するツール。
2. Windows Forms, WPF, ASP.NET, Silverlight, コンソールアプリなど、すべての .NET プログラムには SynchronizationContext の概念が含まれる。（公式ドキュメントを見ると .NET だけでなく Core なども適用対象に含まれているようです） 　
3. 古くはメッセージキューを使用して作業単位を受け渡していたが、.NET Framework が登場した時に汎用ソリューションとして ISynchronizeInvoke が考案され、その後 .NET Framework 2.0 で ASP.NET の非同期プログラミングをサポートするため SynchronizationContext に置き換えられた。
4. SynchronizationContext の特徴は (1) 作業単位をコンテキストのキューにする (unit of work is queued to a context rather than a specific thread)、(2) 全てのスレッドは "現在の" コンテキストを持つ (every thread has a “current” contex)、(3) 未完了の非同期操作の数を管理する (it keeps a count of outstanding asynchronous operations)。
5. Windows Forms, WPF, ASP.NET に使用されている SynchronizationContext はそれぞれ実装が異なっており、順に以下の通りとなる。（Current プロパティで確認できる）
   
   WindowsFormsSynchronizationContext
   DispatcherSynchronizationContext
   AspNetSynchronizationContext (.NET 4.5 以降）
6. Windows Forms, WPF などの GUI アプリでは、await で待機するとき現在の SynchronizationContext がキャプチャされ、await が完了するとキャプチャした SynchronizationContext で続きを実行する。その際に使われるスレッドは await 前後で同じ、即ち UI スレッドになる。
7. ASP.NET でも await 前後での SynchronizationContext のキャプチャと続きの実行は GUI アプリと同様だが、await 前後で HttpContext が同じになるようにしている。await 前までに使っていたスレッドはスレッドプールに戻し、await が完了後の処理はスレッドプールから新たにスレッドを取得して行う。（GUI アプリとは非同期にする目的が違うため。詳しくは「ASP.NET の非同期/待機の概要」を参照）
8. コンソールアプリでは SynchronizationContext.Current プロパティは null になる（ということは、await で待機する際に「現在の SynchronizationContext をキャプチャ」ということはないはず）。await が完了するとき、スレッドプールを備えた既定の SynchronizationContext を使って、スレッドプールのスレッドで async メソッドの残り処理のスケジュールが設定される。（なので、「await と Task.Result によるデッドロック」に書いたようなデッドロックには陥らない）

async / await を使った非同期プログラミングではプログラマが SynchronizationContext を意識することはほとんどなさそうで、知らなくても済むような気がします。

実際、以下の画像の赤枠部分のコードのように Control.Invoke の代わりに SynchronizationContext.Post メソッドが使えるということぐらいしか使い道は思い当たりません。（自分が知らないだけという可能性は否定できませんが）

MSDN マガジンの記事「並列コンピューティング - SynchronizationContext こそすべて」にも "開発者を支援するために SynchronizationContext クラスが用意されています。残念なことに、多くの開発者はこの便利なツールに気が付いてすらいません" と書いてありましたが、そうだろうなと思いました。

ただ、async / await を使った非同期プログラミングでも内部的には SynchronizationContext が大きく関与しているのは間違いなく、上記の程度は知っておいて損はないかもしれませんね。

.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 ミリ秒待って一応は動くようになるのですが、それは意味がなさそうです。今後の検討課題ということで・・・

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

(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 によるデッドロックの回避に続く。