async/await と SynchronizationContext (2)

前回は SynchronizationContext の説明だけで async/await に絡んだ話が出来ませんでした。
今回はその続きになります。

まずは復習。
以前の記事で詳しくやりましたが、async/await は、以下のような特徴を持つ非同期処理の方式です。

コード上に明示的にコールバック関数が現れない
ほとんど同期処理と似た見た目を実現できる

コールバック関数が見当たらないのは、メソッドを分割して、自分自身をコールバック関数にしているからでしたね。

さて、同期処理とほとんど同じように書けるというからには、前回やった APM のように、現在のスレッドが UI スレッドなのかワーカースレッドなのかを気にするようではいけません。
というわけで、当然ながら SynchronizationContext が一枚噛んでいて、「いい感じ」に処理されるようになっています。

以前のコードを再掲します（コメントは変えています）。

async Task AsyncSample()
{
  var client = new WebClient();
  
  var task1 = client.DownloadStringTaskAsync(url1);
  // ここまでは元のスレッドで実行される
  // ここから先は SynchronizationContext に従って実行される
  string url2 = await task1;
  
  var task2 = client.DownloadStringTaskAsync(url2);
  string result = await task2;
}

Task に対して await するコードは、コンパイラーによって

GetAwaiter して
OnCompleted でコールバック関数を登録して
GetResult で結果を取得

という処理に変換されるのでした。
この時、GetAwaiter で元のスレッドの SynchronizationContext がキャプチャーされ、コールバック関数は SynchronizationContext.Post 経由で実行されます（TaskAwaiter がそういう実装をしています）。
つまり、WPF や Windows Forms であれば UI スレッドで実行されますし、ASP.NET であれば HttpContext.Current が正常に設定されたワーカースレッド上で実行されます。
これによって、後続の処理は、今どのスレッドで動いているかということを意識せずに済むようになっているのです。

ConfigureAwait

このように SynchronizationContext は大変便利なものですが、いいことばかりでもありません。
WPF や Windows Forms では実行するスレッドが切り替わりますので、UI スレッドがそのとき何か別の処理をしていれば待たされることになります。
ASP.NET ではそれほどではないにせよ、追加の処理が入りますので、多少なりともパフォーマンスに影響が出ます。

そこで、SynchronizationContext 上で実行されなくてもよい処理については、そのままワーカースレッドで継続することで、余計な処理を挟むことなく、トップスピードで後続の処理を行う方法が用意されています。
それが Task.ConfigureAwait です。

先ほどのコードをこのように書き換えると

async Task AsyncSample()
{
  var client = new WebClient();
  
  var task1 = client.DownloadStringTaskAsync(url1).ConfigureAwait(false);
  // ここまでは元のスレッドで実行される
  // ここから先はダウンロードに使用したワーカー スレッドでそのまま実行される
  string url2 = await task1;

  // ... 
}

WebClient.DownloadStringTaskAsync は非同期処理ですから、裏でワーカースレッドが作られて*1います。
ConfigureAwait(false) した Task に対して await すると、SynchronizationContext をキャプチャーせず、後続の処理をワーカースレッドでそのまま実行します。

当然ですが、そうした場合、後続の処理の中で UI コントロールを操作したり、HttpContext.Current を使ったりすることはできません。
そのため、ConfigureAwait(false) は、プラットフォームの機能を一切利用しない、純粋なロジックのみを含んだクラスライブラリで使うべきです。
使わなくても動くのですが、適切に使ったほうが若干速くなります。

さて、ここで問題です。
以下のようなコードを書くと、2 回目の await はどういう動きをするでしょうか？

async Task AsyncSample()
{
  var client = new WebClient();
  
  var task1 = client.DownloadStringTaskAsync(url1).ConfigureAwait(false);
  // ここまでは元のスレッドで実行される
  // ここから先はダウンロードに使用したワーカー スレッドでそのまま実行される
  string url2 = await task1;
  
  var task2 = client.DownloadStringTaskAsync(url2).ConfigureAwait(true);
  // ここは？
  string result = await task2;
}

ConfigureAwait(true) としているので、再び SynchronizationContext の影響下に戻るでしょうか？
いいえ、そうではありません。
既に一度 ConfigureAwait(false) をしているので、その部分はワーカースレッドで実行されています。
ワーカースレッドには SynchronizationContext がありませんから、ConfigureAwait(true) としても、SynchronizationContext をキャプチャーできないのです。
従って、そのままワーカースレッドで動作し続けます。

そのため、クラスライブラリでは、外部に公開しているメソッド中の、一番最初の非同期処理にだけ ConfigureAwait(false) をつければ十分です。

なお、この AsyncSample を呼び出した呼び出し元では、SynchronizationContext をキャプチャーしていますから、呼び出し元に書かれた後続処理は SynchronizationContext で動きます。
ConfigureAwait(false) の影響が及ぶのは、それを呼び出したメソッド以下のスコープに限られます。