await Task.Run(...)で待っている時、呼び出し元スレッドは何をしているのか？

Question

私はC++が専門でC#はそれほど詳しくないのですが、委託先が作成したC#のコードを動かしたところ問題が発生しているので、原因の調査をしています。そこで、ぶち当たった疑問について質問させて下さい。

await Task.Run(...)すると、呼び出し側スレッドはそのTaskが終わるの待つを思いますが、待っている間呼び出し側スレッドは何をしているのでしょうか？

1. 何もせず、ただTaskの完了を待っている（Taskからのイベントやメッセージなどを待っているだけ）
2. 呼び出し元でTimerが定義されている場合、時間が来るとawait中でもタイマー関数が呼ばれる
3. 呼び出し元スレッドが何らかの非同期処理（ネットワーク処理やディスクI/Oなど）を実行していた場合、それらの完了イベントが実行される
4. 呼び出し元がUIを持つスレッドの場合（メインスレッドなど）、メッセージループが回っていてWindowsへのメッセージが処理される
5. その他・・・

どうぞよろしくお願いします。

Comments

[Zuishin]

await Task.Run の呼び出し前、呼び出し中、呼び出し後に Thread.CurrentThread.ManagedThreadId を表示すればわかります。

[退会済みユーザー]

ThreadIdを見ると何が分かるというのでしょうか？

await Task.Run呼び出し中に、呼び出されたTaskの中で何が行われているか？という質問ではなく、呼び出し中に呼び出したスレッド自体が何をしているのかという質問なので、「呼び出し中」で待っている時にManagedThreadIdを表示させることは不可能です。
呼び出し前と呼び出し後であればManagedThreadIdを見ることはできますが、それを見ることで「何が」分かるのかをご教示くださいませんか？

[Zuishin]

意味が分かりませんか？
using System;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApp1
{
class Program
{
static async Task Main(string[] args)
{
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
await Task.Run(() =>
{
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
});
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
}
}
}

これを実行すればわかります。

[退会済みユーザー]

提示いただいたコードから分かることは、呼び出し前と呼び出し後のスレッドは同じであること、Task.Runの中で実行されているスレッドはそれとは異なるスレッドあること、この２点だと思います。

少し言い換えます、Task.Runが別スレッドで実行されている間、呼び出し元スレッドは単にそのスレッドの終了を待っているだけなのか、他に何かやっていることはあるのではないか？という質問です。
なので私の質問では、提示していただいたコードのawait Task.Runの中にあるConsole.WriteLine処理（および同じ関数内でのすべての処理）も、await Task.Runの外にある２つのConsole.WriteLine部分の処理についても関心がなく、尋ねてもいません。

[Zuishin]

違います。あなたの思っているような実行結果にはなりません。実行してから言ってください。

[Zuishin]

実行したらわかると言いましたが、実行せず頭の中で想像してわかるとは誰も言っていません。

[退会済みユーザー]

違わないと思います。あなたにコードを提示してもらう以前にそういうことは確認しています。
何が「違う」のか教えて下さい。

[Zuishin]

実行結果を書いてください。そのうえでわからないとしたら、一度寝て目を覚ましてから行ったほうがいいと思います。そうとう寝ぼけています。

[Zuishin]

と言っても絶対実行しないと決めているようなので、結果を書きましょうか。
await 実行前のスレッドはそこで終了し、実行中のスレッドと実行後のスレッドは同じものになります。
これでもまだ終了を待つとかどうとかいう発想になるのであれば、本気で寝たほうがいいと思います。

[Zuishin]

Windows Forms で、イベントハンドラの中で呼んだ場合、呼び出し元のスレッドはイベントハンドラから戻ってメッセージループに戻ります。ユーザーコードから離れることを tamoto さんは「フリーになる」と表現しています。

[退会済みユーザー]

コンソールアプリとUIでは、何かのモデルが違ってて、awaitの内部的な動きも違ってたような気がしますけど...具体的な話でなくて申し訳ありませんが...
これ結構難しい話なので、コードベースでないと話が噛み合わないような気がしますよ

[退会済みユーザー]

Zuishin さんが上のコメントに書かれたコードを試してみました。

> 実行中のスレッドと実行後のスレッドは同じものになります。

時々 1 ⇒ 3 ⇒ 4 と言うようにすべて違うスレッドになることもあるようです。

Answer 1

こんにちは。

「問題が発生している」の問題を質問して頂けた方が実のある回答が得られる気がしますが。

await Task.Run(..) の書き方であれば、その行に到達した時点で呼び出し元スレッドは終了し、フリーになります。
そして、Task が完了した後は続きの処理を同じスレッドにスケジュールします。

質問にある番号だと 1 は間違いで、4 は正しいですね。
それ以外は単にフリーのスレッドをどう使うかという話なので、質問自体が成り立ってないものと思います。

Comments

[退会済みユーザー]

ありがとうございます。

大事なことを言い忘れていました。呼び出し元はUIを処理しているメインスレッドという前提でお願いします。
もし私が書いた「４」が正しいのであれば、await Task.Run中はUI操作ができるということになると思いますが、そういう理解でよろしいでしょうか？

> 「問題が発生している」の問題を質問して頂けた方が実のある回答が得られる気がしますが。

すみません、私がいま問題としているのはawait Task.Runで待っている間にも、呼び出し元スレッドで設定したTimer処理が呼び出されているのではないか？ということです。この点についてはいかがですか？

この疑問が現在の課題ですが、後学のため、await Task.Runで待っている間に裏で行われていることはどんなことがあるのかを知りたくてこういう質問となりました。Win32 APIでゴリゴリ書いていると、await Task.Runみたいな便利な機能はありませんので、自分でスレッド起動＆待ちのループやイベント待ちのコードを書くので、待ち時間に何をするかは自分の実装次第なのですが、こういう便利な機能の裏側がブラックボックスのような気がして、勉強したいと思った次第です。

> await Task.Run(..) の書き方であれば、その行に到達した時点で呼び出し元スレッドは終了し、フリーになります。

「元スレッドは終了」というのは、ちょっと語弊を招くのではありませんか？スレッド自体が終了するのではなく、呼び出し元スレッドの処理を一時中断してCPUのタイムスライスを別のスレッドに明け渡すという理解でよいですか？

そして、「フリーになります」とはどういう意味ですか？

> そして、Task が完了した後は続きの処理を同じスレッドにスケジュールします。

これはそう思います。

よろしくお願いします。

[tamoto]

呼び出し元スレッド == UI スレッドということですね。
はい。await Task.Run 中は UI 操作ができます。
await Task.Run(..) の「(..) の処理」を実行している間、UI スレッドは完全に空き状態になるため、イベントループは回り、UI スレッドにスケジュールされているタイマーは働き、全ての処理が行われます。
「(..) の処理」が完了すると、呼び出し元で await 以降に書かれている「続きの処理」が UI スレッドにスケジューリングされ、UI スレッドが空き次第、UI スレッド上で動作します。

「元スレッドが終了」と書いたのは良くなかったですね。
正しくは、「UI スレッド上で実行される処理は最初の await まで」です。
await の行に到達した時点で、UI スレッドを利用した計算は終わり、他の UI 処理が可能になります。
「処理を一時中断」しているわけでは無く、非同期メソッドは「メソッドの処理が予めぶつ切りにされていて、最初の await までだけが UI スレッドにスケジュールされる」が正しいです。

Answer 2

C++でstd::futureの利用経験はありますでしょうか？
C#のTaskはstd::futureと同じくFutureパターンを実現する機構です。
async/awaitを用いると、『await以降がFutureパターンにラップされる』と考えると理解しやすいかと思います。

ひとつ例を見てみます。
以下のようにHoge→FugaAsync→PiyoAsyncという形で非同期メソッドを呼び出します。
ここで、HogeはFugaAsyncの結果をスレッドブロックして待機、FugaAsyncはPiyoAsyncをawaitで待機しています。

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static void Main(string[] args)
    {
        Hoge();
    }


    static void Hoge()
    {
        Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Hoge 1");
        FugaAsync().Wait();
        Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Hoge 2");
    }

    static async Task FugaAsync()
    {
        Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Fuga 1");
        var piyoTask = PiyoAsync();
        Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Fuga 2");

        await piyoTask;

        Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Fuga 3");
    }

    static async Task PiyoAsync()
    {
        Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Piyo 1");
        await Task.Delay(1000);
        Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Piyo 2");
    }
}

このプログラムの実行結果は例えば以下のようになります。

[1] Hoge 1
[1] Fuga 1
[1] Piyo 1
[1] Fuga 2
[4] Piyo 2
[4] Fuga 3
[1] Hoge 2

実行結果を見ると、Hoge1 → Fuga1 → Piyo1 → Fuga2となっており、await以降のコードを削除して同期処理させた場合と同じふるまいをしています。
一方でFuga2はPiyo2よりも先に処理が完了していることから、PiyoAsyncのawait以降のコードはFutureオブジェクトにラップされ別スレッドで処理が進行していることがわかります。

この一連の流れをシーケンス図で描くと以下のようになります。

ここではメインスレッドを.Wait()してブロックしましたが、通常のUI処理ではブロック処理をせず現在のメソッドを終了するでしょう。

---

さて、await以降の処理がFuture化され別スレッドで実行されると言いましたが、ここで使われるスレッドは実は条件次第で異なります。

• 多くの場合はフレームワークがスレッドプールの中からよしなに実行スレッドを選択します。
  上記の例でも、await以降の処理がスレッド4に移されていることがわかります。
• 呼び出し元のスレッドが同期コンテキスト(≒メッセージループ)を持っており、かつawait時にConfigureAwait(false)を設定していない場合、呼び出し元スレッドで実行します。例えばWin32であればメッセージキューにawait以降の処理を積み直すということをします。
  この場合、例のように.Wait()すると、メッセージループをブロックしたまま後続メッセージを待機するという処理になってしまい、結果デッドロックを生じます。

GUIアプリケーションではawait以降の処理がUIスレッドで実行されるかワーカースレッドで実行されるかを常に意識するようにするとコードを理解しやすくなるのではと思います。