編集履歴

質問編集履歴

誤字修正

2016/09/20 18:42

投稿

MagoCat

スコア86

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -184,7 +184,7 @@
 また、このCOMを利用するWindowsForms側のButton2クリック時の処理を以下のように変更しました。
-```ここに言語を入力
+```c#
 private void button2_Click(object sender, EventArgs e)
 {
     //ボタン２では、GetThreadIDをTask内(スレッドプール)で呼ぶ。

誤字修正

2016/09/20 18:42

投稿

MagoCat

スコア86

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -232,4 +232,4 @@
 つまりこの実験から何が分かるのかというと、```task.Wait();```による待ちでスレッドの処理が完全にブロックされるのではなくて、別スレッドからSTA-COMメソッドを呼び出したときに発生するメッセージは特別扱いで処理できるようだということです。
-追伸：他の方からコメントで頂いたURLはまだ読んでいないので、今日明日のうちに目を通してみます。
+追伸：皆さんからコメントで頂いたURLはまだ読んでいないので、今日明日のうちに目を通してみます。

誤字修正

2016/09/20 18:10

投稿

MagoCat

スコア86

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -159,7 +159,7 @@
 [追記２]の実験に幾つかの改良を加えました。
-- メインスレッドのWait()到達よりもタスク内でのmyAtl.GetThreadID()実行が確実に遅れるように、タスク内の最初で数秒スリープするようにした。
+- メインスレッドの```task.Wait();```到達よりもタスク内での```myAtl.GetThreadID();```実行が確実に遅れるように、タスク内の最初で数秒スリープするようにした。
 - デバッグ出力文字列にスレッドIDを添えるようにした。
@@ -167,7 +167,7 @@
-具体的には、まずCMyATLTestClassのGetThreadIDの中身を以下のように変更しました。
+具体的には、まずCMyATLTestClassのGetThreadID()の中身を以下のように変更しました。
 ```c++
 STDMETHODIMP CMyATLTestClass::GetThreadID(LONG* id)

コメントで頂いたアドバイスを反映した追加実験を行った事による追記

2016/09/20 18:07

投稿

MagoCat

スコア86

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -149,4 +149,87 @@
 かといって```task.Wait();```によるメインスレッドのブロッキング中に、COMのメッセージだけは選択的に処理されるという動作が自然かというと私は結構不自然だと思いました。
-この挙動を説明するMSDNの記述を見つけたいところですね。
+この挙動を説明するMSDNの記述を見つけたいところですね。
+---
+**【追記３】**
+[追記２]の実験に幾つかの改良を加えました。
+- メインスレッドのWait()到達よりもタスク内でのmyAtl.GetThreadID()実行が確実に遅れるように、タスク内の最初で数秒スリープするようにした。
+- デバッグ出力文字列にスレッドIDを添えるようにした。
+- COMメソッド内部でもデバッグ文字列を出力するようにした。
+具体的には、まずCMyATLTestClassのGetThreadIDの中身を以下のように変更しました。
+```c++
+STDMETHODIMP CMyATLTestClass::GetThreadID(LONG* id)
+{
+	*id = GetCurrentThreadId();
+	CString str;
+	str.Format(_T("InGetThreadID ThreadID=%d\n"), *id);
+	OutputDebugString(str);
+	return S_OK;
+}
+```
+また、このCOMを利用するWindowsForms側のButton2クリック時の処理を以下のように変更しました。
+```ここに言語を入力
+private void button2_Click(object sender, EventArgs e)
+{
+    //ボタン２では、GetThreadIDをTask内(スレッドプール)で呼ぶ。
+    int threadID = 0;
+    Task task = Task.Run(() =>
+    {
+        //3秒待機すれば、
+        //メインスレッドは間違いなくWait()に突入しているだろう。
+        Thread.Sleep(3000);
+        Trace.WriteLine("TaskStart ThreadID=" + AppDomain.GetCurrentThreadId());
+        myAtl.GetThreadID(out threadID);
+        Trace.WriteLine("TaskEnd ThreadID=" + AppDomain.GetCurrentThreadId());
+    });
+    //タスクの完了を待機してから、メッセージボックスを使って表示
+    Trace.WriteLine("BeforeWait ThreadID=" + AppDomain.GetCurrentThreadId());
+    task.Wait();
+    Trace.WriteLine("AfterWait ThreadID=" + AppDomain.GetCurrentThreadId());
+    MessageBox.Show("ボタン２ ThreadID=" + threadID);
+}
+```
+Button2をクリックすることに依るデバッグ出力の結果は以下のように成りました。
+(折角なので、紹介して頂いたDebugViewを使用しています)
+![イメージ説明](a65210e5e2e1e1bdb9ec83018d8ec401.png)
+順序はこうです。
+**1. "BeforeWait"がメインスレッド(ID=6128)で出力された。**
+**2. "TaskStart"が別スレッド(ID=7964)で出力された。**
+(タスクの最初に3秒スリープしたことで、1と2の出力には大きな時間差があります。この間にメインスレッドは確実に```task.Wait();```に突入しているでしょう。)
+**3. "InGetThreadID"がメインスレッド(ID=6128)で出力された。**
+(メインスレッドは```task.Wait();```でブロックされているはずなのにメインスレッドでCOMのメソッドが実行されています)
+**4. "TaskEnd"が別スレッド(ID=7964)で出力された。**
+**5. "AfterWait"がメインスレッド(ID=6128)で出力された。**
+(このタイミングでようやくメインスレッドのブロッキングは解除されています)
+つまりこの実験から何が分かるのかというと、```task.Wait();```による待ちでスレッドの処理が完全にブロックされるのではなくて、別スレッドからSTA-COMメソッドを呼び出したときに発生するメッセージは特別扱いで処理できるようだということです。
+追伸：他の方からコメントで頂いたURLはまだ読んでいないので、今日明日のうちに目を通してみます。

回答者からの指摘を受けて追加実験を行ったことに依る追記

2016/09/20 18:04

投稿

MagoCat

スコア86

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -105,4 +105,48 @@
 ・メインスレッドから呼び出されたCOMのGetThreadIDが返すスレッドID
 ・別スレッドから呼び出されたCOMのGetThreadIDが返すスレッドID
-つまりは、Taskを使用して別スレッドから呼び出されたCOMのGetThreadIDは確実にメインスレッドのメッセージループで実行されているようなので、Button2内のWait()でデッドロックしない理由については未だ納得できない状態です。
+つまりは、Taskを使用して別スレッドから呼び出されたCOMのGetThreadIDは確実にメインスレッドのメッセージループで実行されているようなので、Button2内のWait()でデッドロックしない理由については未だ納得できない状態です。
+---
+**【追記２】**
+「もしかするとTask.Waitでメインスレッドが完全にブロッキングされる訳ではなくCOMメッセージの処理に限っては継続されるのではないか」という旨の指摘をいただきましたので、Trace.WriteLineを用いて処理順序を追ってみました。
+具体的には、ボタン2クリック時の処理にTrace.WriteLineを何行か追加して、次のようにしました。
+```C#
+private void button2_Click(object sender, EventArgs e)
+{
+    //ボタン２では、GetThreadIDをTask内(スレッドプール)で呼ぶ。
+    int threadID = 0;
+    Task task = Task.Run(() =>
+    {
+        Trace.WriteLine("TaskStart");
+        myAtl.GetThreadID(out threadID);
+        Trace.WriteLine("TaskEnd");
+    });
+    //タスクの完了を待機してから、メッセージボックスを使って表示
+    Trace.WriteLine("BeforeWait");
+    task.Wait();
+    Trace.WriteLine("AfterWait");
+    MessageBox.Show("ボタン２ ThreadID=" + threadID);
+}
+```
+デバッグ実行してボタン２をクリックしたときの出力画面の様子は以下のとおりです。
+![イメージ説明](a71da1e055cc7fb8a59b51420c559649.png)
+TaskStart->BeforeWait->TaskEnd->AfterWait の順で処理が進行したようです。
+"BeforeWait"が出力された直後には```task.Wait();```が行われてメインスレッドがブロッキングされている。
+にも関わらず、メインスレッドのメッセージループで実行されるべき```myAtl.GetThreadID(out threadID);```を含むタスクが無事終了していることが "TaskEnd" の出力から分かります。
+ここで、```myAtl.GetThreadID(out threadID);```の行が```task.Wait();```よりも前に処理されたか```task.Wait();```の中で処理されたかですが、中で処理されたと考えるほうがありえそうに思います。なぜなら```task.Wait();```よりも前には他のメッセージの割り込みを許しそうなコードは一切ないからです。
+かといって```task.Wait();```によるメインスレッドのブロッキング中に、COMのメッセージだけは選択的に処理されるという動作が自然かというと私は結構不自然だと思いました。
+この挙動を説明するMSDNの記述を見つけたいところですね。

追加実験を行ったことに依る追記

2016/09/19 20:37

投稿

MagoCat

スコア86

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -70,4 +70,39 @@
 ###助けて欲しいこと
-考察の穴を解消してください。
+考察の穴を解消してください。
+---
+**【追記】**
+「もしかするとCOMオブジェクト生成時に別スレッドが起動されその中でメッセージループが回っているからデッドロックが回避されているのではないか」との指摘がありましたので、メインスレッドのスレッドIDを(COMを経由せず)表示するコードをForm1に追加してもう一度実験を行いました。
+追加したコードは下記のとおりです。
+```C#
+        private void button0_Click(object sender, EventArgs e)
+        {
+            //ボタン０では、
+            //AppDomain.GetCurrentThreadIDをメインスレッドから呼ぶ。
+            int threadID = AppDomain.GetCurrentThreadId();
+            //メッセージボックスを使って表示
+            MessageBox.Show("ボタン０ ThreadID=" + threadID);
+        }
+```
+結果は以下のようになりました。
+![イメージ説明](d8a11cc6123a66e3de482a1d8e7e022b.png) ![イメージ説明](23069d417027f94d11f6a603c03c8314.png) ![イメージ説明](116465f0b4928560d15a06338f47241f.png)
+ボタン0を押したときに使用しているAppDomain.GetCurrentThreadIDはObsoleteのようです。
+よって、ボタン０を処理しているときのスレッドIDを念のためデバッガ上の"スレッド"の表示においても確認しています。
+![イメージ説明](2ec0642fbb12c16aa20e82690bbe7e78.png)
+結果として、以下３つが全て同一のスレッドIDを示すことが確認できました。
+・メインスレッドのスレッドID
+・メインスレッドから呼び出されたCOMのGetThreadIDが返すスレッドID
+・別スレッドから呼び出されたCOMのGetThreadIDが返すスレッドID
+つまりは、Taskを使用して別スレッドから呼び出されたCOMのGetThreadIDは確実にメインスレッドのメッセージループで実行されているようなので、Button2内のWait()でデッドロックしない理由については未だ納得できない状態です。