回答編集履歴
1
追記
test
CHANGED
@@ -5,6 +5,10 @@
|
|
5
5
|
まずは結論から。
|
6
6
|
|
7
7
|
ConfigureAwaitを付けることで非同期メソッドの動作そのものは変わりません。そして、デッドロック問題を回避するため、**ほぼ全てのawait箇所でConfigureAwaitを書くのが基本である**と認識してください。
|
8
|
+
|
9
|
+
|
10
|
+
|
11
|
+
---
|
8
12
|
|
9
13
|
|
10
14
|
|
@@ -18,7 +22,7 @@
|
|
18
22
|
|
19
23
|
|
20
24
|
|
21
|
-
しかし、非同期メソッド中でawaitする前と
|
25
|
+
しかし、非同期メソッド中でawaitする前と後でコンテキストが異なると都合が悪い存在があります。それは、「UI処理等、特定のスレッドに依存する処理」です。
|
22
26
|
|
23
27
|
UI処理は、元々単一のスレッドでしか実行できないというフレームワークの設計による制約があります。
|
24
28
|
|
@@ -36,17 +40,21 @@
|
|
36
40
|
|
37
41
|
という設計を採用しました。
|
38
42
|
|
43
|
+
つまり、非同期メソッド上に実際に記述した処理は「全て単一のスレッド上で実行される」設計になったということです。
|
44
|
+
|
39
45
|
この設計によって、UI処理を非同期メソッドで記述出来るようになった代わりに、コンテキストの衝突によるデッドロックの問題を生み出してしまいました。
|
40
46
|
|
41
47
|
デッドロックは致命的な存在なので、さらにこれを回避するために「コンテキストの保存を無効化する」手段が必要になりました。それが、ConfigureAwaitメソッドなのです。
|
42
48
|
|
43
49
|
|
44
50
|
|
51
|
+
---
|
52
|
+
|
53
|
+
|
54
|
+
|
45
|
-
つまり、本来awaitはConfigureAwait(false)が書かれた状態がデフォルトであると考えることが
|
55
|
+
つまり、本来awaitはConfigureAwait(false)が書かれた状態がデフォルトであると考えることができます。
|
46
56
|
|
47
57
|
そして、UI処理等の、非同期メソッドの処理を一つのコンテキスト上で走らせたい時だけ、ConfigureAwaitを外せばいいのです。
|
48
|
-
|
49
|
-
|
50
58
|
|
51
59
|
質問のコードを例にすると、
|
52
60
|
|
@@ -66,8 +74,16 @@
|
|
66
74
|
|
67
75
|
|
68
76
|
|
77
|
+
---
|
78
|
+
|
79
|
+
|
80
|
+
|
69
81
|
Taskクラスを説明するのは難しく、理解できない文章になっていたらすみません。
|
70
82
|
|
71
83
|
また、以前の回答でも参考に記載しましたが、[async/awaitについての解説記事](http://qiita.com/acple@github/items/8f63aacb13de9954c5da)の内容も参考にしてみてください。
|
72
84
|
|
85
|
+
|
86
|
+
|
87
|
+
質問の内容が過去の質問からの地続きになっていて、文脈が読み取りにくい質問になってきています。
|
88
|
+
|
73
|
-
わからないところがあったら、コメント
|
89
|
+
質問単体からその背景が読み取れない質問はあまり良くないので、もしここでわからないところや疑問点があったら、コメント欄に質問してください。
|