ConfigureAwait

あえとす @aetos382

ASP.NET の非同期でありがちな Deadlock を克服する - 松崎 剛 Blog - Site Home - MSDN Blogs blogs.msdn.com/b/tsmatsuz/arc…

あえとす @aetos382

@xin9le @chocolamint サーバー側というのは？

Takekazu Omi @takekazuomi

@aetos382 @xin9le @chocolamint それって、デフォルトが逆じゃ無いって話ですかね

じんぐる (Takaaki Suzuki) @xin9le

@takekazuomi @aetos382 @chocolamint あ、サーバー側というのはWebアプリのつもりで書きました。デフォルトを逆にして欲しいと思うことは多々ありますね...。というか、いつもそう思っていますw

あえとす @aetos382

@xin9le @takekazuomi @chocolamint なんか ASPNET でも true にしとかないと HttpContext がどうにかなっちゃう（よくわからない）ので、やっぱり基本的にはアプリ／ライブラリで切り分けるのがいいのかなーと思ってます…。

じんぐる (Takaaki Suzuki) @xin9le

@aetos382 @takekazuomi @chocolamint 確かにHttpContext云々はあるのですが、HttpContextを滅多に使わないのでそういう考えなのかもです。アプリ/ライブラリでの切り分けがダメとは全然思っていません。

あえとす @aetos382

@xin9le @takekazuomi @chocolamint ただ、HttpContext どこで使ってるかわからないので…。完全に自分で書いたコードだけ呼んでる場合はいいですけど、他人のコードを呼ぶ時は true かなーと。

Takekazu Omi @takekazuomi

@aetos382 @xin9le @chocolamint レスポンスに合わせたい場合と、関係無くF&Fでいい場合と考えるとASP.NETで同期コンテキストが提供されてるのは妥当な気がします。デフォルトで同期コンテキストを見るのも分かるような

しゃるしぃ @chocolamint

ConfigureAwait(false)されてないTaskの完了を待たずにHttpContextが完了しちゃうと死ぬのか。全然別の話だった。失礼。

しゃるしぃ @chocolamint

HttpContext触らなければConfigureAwait(false)してもいいってのは、クライアントアプリでビューとバインドされたビューモデルのプロパティやフォーム/ウィンドウのコントロールを触らなきゃConfigureAwait(false)していいって話とほぼ同義？

Takekazu Omi @takekazuomi

同期コンテキスト自体がかなり高レベルな概念なので、デフォルトは無視で良かったのではないか

あえとす @aetos382

非同期が難しいんじゃなくて、ConfigureAwait(true) でないといけない処理の存在が非同期を難しくしてるんやんなぁ。

あえとす @aetos382

で、１では HttpContext.Current は not null だけど、２では null になる。３は ConfigureAwait(false) だと null になり得る。ConfigureAwait(true) なら not null。

あえとす @aetos382

ConfigureAwait(false) の場合、３（後続処理）は２（ワーカースレッド）と同じスレッドで動くので、HttpContext.Current は null。

あえとす @aetos382

ConfigureAwait(true) でも、await する前にワーカースレッドが終わってしまえば、３（後続処理）は１（呼び出し元）と同じスレッドで動く。また、スレッドプールはスレッドを再利用するので、ワーカースレッドが終わっていなくても１と３が同じスレッドになることはある。

あえとす @aetos382

HttpContext.Current == null なワーカースレッド内で別の非同期メソッドを ConfigureAwait(true) で呼んだら HttpContext.Current は復旧するのかってのは調べなかったな。復旧しない気がするが。

あえとす @aetos382

復旧しないとすれば、中で何をしているかわからない（HttpContext.Current を参照しているかもしれない）ライブラリコードを、ワーカースレッドから呼ぶべきではない、その場合は ConfigureAwait(true) にしておくべき、ということになるか。

たいへー @a_taihei

ConfigureAwaitはコレ読んで今理解した ufcpp.wordpress.com/2012/11/12/asy…

あえとす @aetos382

確認した。一度 ConfigureAwait(false) にすると、その後続の中では HttpContext.Current はずっと null のまま。途中で ConfigureAwait を書かなかったり true にしても null のまま。

あえとす @aetos382

WPFはわからんからWinForms（ひさしぶり！）で確認したけど、こっちでも、一度falseにしたら、その後でtrueにしてもUIスレッドには回ってこなかった。どうも、一度falseにすると、同期コンテキストからデタッチされて、その後は再アタッチされないみたいな感じ？

あえとす @aetos382

だったらライブラリコードの中でも、非同期メソッドの最初に一度だけ ConfigureAwait(false) しておけば、後はしなくていいんじゃない？ まぁ、Awaiter だか SynchronizationContext だかの実装次第ってのはあるのかもしれんけど。

あえとす @aetos382

あと、一度 false にしてから後で true にすると、同期コンテキストは拾わないけどスレッドは切り替わる可能性がある。そういう意味ではパフォーマンス的な影響はあるのかもしれない。ずっと false なら、ずっと同じワーカースレッドで処理が走る。

あえとす @aetos382

なるほど、ConfigureAwait(false) にするってことは、SynchronizationContext.Current も null になるってことか。一度 null になると、後で true にしても戻らないのは、HttpContext と同じ。

あえとす @aetos382

まず前提として、ワーカースレッドは同期コンテキストを持たない。WPF や WinForms なら UI スレッド、ASPNET ならリクエストスレッドのみが同期コンテキストを持つ。

あえとす @aetos382

非同期メソッドの中で走る非同期処理（ややこしい）はワーカースレッドで実行される。ので、同期コンテキストを持たない。ConfigureAwait(false) は、スレッドスイッチを抑制する。ので、同期コンテキストを拾わない。