回答編集履歴

1

内容の補足

2019/02/13 04:44

投稿

wwbQzhMkhhgEmhU
wwbQzhMkhhgEmhU

スコア343

test CHANGED
@@ -254,6 +254,30 @@
254
254
 
255
255
  }
256
256
 
257
-
258
-
259
257
  ```
258
+
259
+ 追記)
260
+
261
+ SynchronizationContextによっては、実行スレッドによりawait後のスレッドに制約がかかるため、Task.Waitと競合してデッドロックすることがあります。
262
+
263
+ コンソールアプリ以外で使用するケースでは、そのようなケースが起こりうるので、ご注意ください。
264
+
265
+ 例えば、これ100msくらいで終わるからUIスレッドで実行しよう、とかすると、100ms経過しても返ってこず、固まるということです。確実にUIスレッド以外から実施してください。ASP.NETでの回避方法は未確認です。
266
+
267
+ ConfigureAwaitによる回避は↓の記事にもある通りやめるべきだと思います。
268
+
269
+
270
+
271
+ デッドロックについては、↓が詳しいです。
272
+
273
+ http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
274
+
275
+
276
+
277
+ SynchronizationContextについては、↓参照です。
278
+
279
+ https://msdn.microsoft.com/magazine/gg598924.aspx
280
+
281
+
282
+
283
+ 最後に、納得の行かない人もいるかもしれないので、書いておきますが、待ち合わせという性格上、このI/Fをawaitで実装する限り、Task.Waitは仕方のない選択です。有効なケースであれば問題はないので、個人的に分かって使う分には益がある、と考えています。