SynchronizationContextについて
- .NET2.0からSynchronizationContextクラスが登場した。それが同期コンテキストと呼ばれる場合がある。
  - 「コンテキスト」とは非同期操作の実行状況や環境に関する情報を含むもの。(by chatGPT)
- SynchronizationContext は、スレッド毎にインスタンスを持っている。
  - WPFの場合、UIスレッドは持ってる。ワーカースレッドはもってない。
- SynchronizationContextを使うと、立ち上げたワーカースレッドが実行されるスレッドを、立ち上げた側のスレッドと同じにできたりする。
  - WPFの場合、ワーカースレッドが実行されるスレッドを、UIスレッドと同じにしたりできる。
- WPFのUIスレッドが自分のSynchronizationContextを取得しようと思うと、SynchronizationContext.Currentから取得できる。
  - ワーカースレッドでは、SynchronizationContext.Currentにはなにも入っていない。
- WPFではそういう感じだが、別のプラットフォーム、フレームワーク上では、全く別だったりする。(例えばASP.NET)
- ただ、.NET6時点のTaskやasync/awaitを利用した非同期処理では、直接的にSynchronizationContextを見る機会がない。(使わなくても十分非同期処理できる)
Taskについて
- Taskは、Awaitebleオブジェクトである。
- Taskは、awaitすると、
  - Taskの処理をしている間は別スレッド(ワーカースレッド)で処理を行って、→①
  - 呼び出し元スレッドに一旦戻り、→②
  - 別スレの処理が終わったら、呼び出し元の処理の続きを呼び出し元スレッドで実行する。→③
- その動きは、コンパイラが下記のように、処理を分解してくれて実現されてる。
  - タスクに登録された処理を別スレッドで実行する。→①に該当
  - TaskAwaiterを取得 → ★？？？
  - 自分自身(呼び出し元)の処理のawait以降をコールバックに登録して、いったん処理を終わる →②に該当
    - 自分自身を、await前と後に分解して、後の方をコールバックに登録する
  - タスクの処理が終わったら、登録したコールバック(自分自身の続き)を実行する →③に該当
TaskAwaiterについて
- TaskAwaiterは、Taskの呼び出し元のコンテキストをキャプチャーして、
  - コンテキスト(SynchronizationContext)をキャプチャーする≒そのコンテキストがどのスレッドで行われているか、を覚えておくようなもの
- Task処理が終わったら、SynchronizationContext.Post経由でコールバック(=呼び出し元処理の続き)を実行する
  - キャプチャーしたコンテキストのSynchronizationContext.Post経由で呼び出し元の処理を呼ぶということは、つまり呼び出し元のスレッドに戻るということ
- という感じで、awaitの動きを実現している。
  - つまり上の★？？？でTaskAwaiterを取得したときに、呼び出し元のコンテキストを覚えてるから、Taskの処理が終わった後に、呼び出し元に戻ることができる。
SynchronizationContext の使いどころはどこか？
- 現在のWPFでは、自分でSynchronizationContextをコードに書くことは、今まで私が出会ったことがないような何かが出てこない限り、しなくてよいと理解。
  - ただそれはコンパイラが裏でSynchronizationContextを使って、ええようにしてくれているおかげである。
  - 昔は、処理を別スレッドに投げたときに、UIを更新するためにSynchronizationContextを使って、UIスレッドに戻す、みたいなことをしてたっぽい。
.configureAwait(false)は何をしてるか？
- awaitしたあと、元のスレッドに戻る動きをやめて、ワーカースレッドのほうで、await後の処理を進めるようにするということ。
- なので、TaskをWaitしてUIスレッドを止めたあとに、Taskの処理終了時に、止まってるUIスレッドに帰ろうとすることが原因のデッドロックは起きなくなる。(UIスレッドに帰らずに、ワーカースレッドでそのまま動くから。)