WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

ConfigureAwait によるデッドロックの回避

by WebSurfer 21. September 2020 13:22

先の記事「await と Task.Result によるデッドロック」の続きです。この記事には、先の記事で述べたデッドロックを回避する方法を書きます。

(5) ConfigureAwait

Task.ConfigureAwait(Boolean) メソッドを使って、先の記事で述べた Task.Result プロパティを使ったコードにおけるデッドロックを回避することができます。(UI がフリーズするのは避けられませんが)

ConfigureAwait メソッドの使用

先の記事のコードでデッドロックが起こるのは、button1_Click メソッド内の TimeCosumingMethod().Result によって UI スレッドはブロックされているが、TimeCosumingMethod メソッド内で await Task.Delay(3000) の後の残りの処理を UI スレッドを使って行おうとする(結果、相手の完了を待機しあう)からです。

コンソールアプリのように、TimeCosumingMethod メソッドの残りを実行するのを、ブロックされている UI スレッドではなく、新たにスレッドプールから取得したスレッドで実行すればデッドロックにはならないはずです。

Microsoft のドキュメント「非同期プログラミングのベストプラクティス」に以下のように書いてあります。

"ConfigureAwait(false) を追加すると、デッドロックが回避されます。この場合、await が完了するとき、スレッドプールのコンテキスト内で async メソッドの残り処理の実行が試みられます。このメソッドは完了でき、返されたタスクを完了するため、デッドロックは発生しません。"

というわけで、ConfigureAwait メソッドを使って以下のコードで試してみました。上の画像を表示したものです。

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsAsyncTest
{
    public partial class Form3 : Form
    {
        public Form3()
        {
            InitializeComponent();
        }

        // Task.Result 使用
        private void button1_Click(object sender, EventArgs e)
        {
            label1.Text = "UI スレッド、ID=" + 
                Thread.CurrentThread.ManagedThreadId;

            label2.Text = TimeCosumingMethod().Result;

            label1.Text += " / ID=" +
                Thread.CurrentThread.ManagedThreadId;
        }

        // await 使用
        private async void button2_Click(object sender, EventArgs e)
        {
            label1.Text = "UI スレッド、ID=" +
                Thread.CurrentThread.ManagedThreadId;

            label2.Text = await TimeCosumingMethod();

            label1.Text += " / ID=" +
                Thread.CurrentThread.ManagedThreadId;
        }

        private async Task<string> TimeCosumingMethod()
        {
            await Task.Delay(3000).ConfigureAwait(
                continueOnCapturedContext: false);

            return "TimeCosumingMethod の戻り値、ID=" +
                Thread.CurrentThread.ManagedThreadId;
        }
    }
}

確かに、ConfigureAwait(false) を追加すると、TimeCosumingMethod メソッドで await Task.Delay(3000) が完了した後の残りの処理は UI スレッドとは別のスレッドで実行されるようになり、デッドロックは回避できます。

上の画像を見てください。UI スレッドの ManagedThreadId(上の画像では ID=1)と TimeCosumingMethod メソッドの残りを実行したスレッド(上の画像では ID=4)が異なっています。

ただし、Task.Result を使う方は UI がフリーズするのは避けられません。一方、await を使う方は UI はフリーズしません(メッセージループは常に動いていて、マウスのクリックなどのユーザーイベントを処理して UI に反映してくれます)。

理由は、Task.Result は UI スレッドをブロックして TimeCosumingMethod メソッドが完了するのを同期的に待機するのに対して、await は呼び出し元に処理を戻して非同期的に待機するからのようです。

@IT の記事「第2回 非同期メソッドの構文」に以下の説明があります。

"await という名前から、「渡した非同期タスクが完了するまで、呼び出し元スレッドをブロックして待機する」というように感じるかもしれないが、実際はそうではない。await 演算子の意味は、「待っているタスクがまだ完了していない場合、メソッドの残りをそのタスクの『継続』として登録して呼び出し元に処理を戻し、タスクが完了したら登録しておいた継続処理を実行すること」なので注意が必要だ。"

Windows Forms アプリでは「Application.Run メソッド」によって UI スレッドで標準のメッセージループの実行が開始されるそうです。

なので、Task.Result を使う方は、UI スレッドがブロックされている間(上のコード例では約 3 秒間)はメッセージループは動いておらず、マウスのクリックなどのユーザーイベントには無反応(UI がフリーズ状態)になるということのようです。

Tags: , , , ,

.NET Framework

await と Task.Result によるデッドロック

by WebSurfer 20. September 2020 12:50

先の記事「非同期プログラミング」の続きで、非同期プログラミングに関して調べたことを備忘録的に書いたものです。

(4) デッドロック

先の記事の「(3) 訳が分からなかった話」に書いた Task.Result プロパティを使ったコードを Windows Forms のような GUI アプリに使うとデッドロックになります。(注: 先の記事のコンソールアプリではデッドロックになることはありません。理由後述)

Windows Forms アプリのコードでそのあたりを分かりやすく書くと以下のような感じです。コメントに「// デッドロック」と書いた方のメソッドを実行するとデッドロックが発生してアプリは固まってしまいます。

using System;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsAsyncTest
{
    public partial class Form3 : Form
    {
        public Form3()
        {
            InitializeComponent();
        }

        // デッドロック        
        private void button1_Click(object sender, EventArgs e)
        {
            label1.Text = "";
            string str = TimeCosumingMethod().Result;
            label1.Text = str;
        }

        // 正常動作
        private async void button2_Click(object sender, EventArgs e)
        {
            label1.Text = "";
            string str = await TimeCosumingMethod();
            label1.Text = str;
        }

        private async Task<string> TimeCosumingMethod()
        { 
            await Task.Delay(3000);
            return "TimeCosumingMethod の戻り値";
        }
    }
}

その理由は Microsoft のドキュメント「非同期プログラミングのベストプラクティス」の「すべて非同期にする」のセクションに書いてあります。

・・・が、自分はその説明を読んでもよく分かりませんでした。(汗) 自分の独断と偏見���よる個人的解釈まじりですが、以下のようなことになっているのであろうと想像しています。

Microsoft のドキュメント「Task<TResult>.Result プロパティ」と「Task.Wait メソッド」に以下の説明があります。

"Task.Result プロパティの get アクセサーにアクセスすると、非同期操作が完了するまで呼び出し元のスレッドがブロックされます。これは、Wait メソッドを呼び出すことと同じです。"

"Wait は、現在のタスクが完了するまで呼び出し元のスレッドを待機させる同期メソッドです。"

また、Microsoft のドキュメント「非同期プログラミングのベストプラクティス」に以下の説明があります。

"既定では、未完了の Task を待機するときは、現在のコンテキストがキャプチャされ、Task が完了するときのメソッドの再開に使用されます。 ・・・中略・・・ GUI アプリケーションと ASP.NET アプリケーションには、一度に実行するコードを 1 つのチャンクに限定する SynchronizationContext があります。await が完了するときは、キャプチャしたコンテキスト内で async メソッドの残りを実行しようとします。"

ということで・・・

  1. 上のコードの TimeCosumingMethod().Result のところで、呼び出し元のスレッド(UI スレッド)は TimeCosumingMethod メソッドが完了するのを同期的に待機する。
  2. 一方、TimeCosumingMethod メソッド内の await Task.Delay(3000); が完了するときは、キャプチャしたコンテキスト内で TimeCosumingMethod メソッドの残りを実行しようとする。  
  3. GUI アプリでは、先の記事の「(2) Windows Forms アプリの ManagedThreadId」の例のとおり、UI スレッドの ManagedThreadId の値は変わらない、即ち同じスレッドが使われ続けている。
  4. ということは、「キャプチャしたコンテキスト」のスレッドは、ステップ 1 で待機しているスレッドと同じということになる。
  5. ステップ 1 で待機しているスレッドは TimeCosumingMethod メソッドが完了しないと解放されないが、TimeCosumingMethod メソッド内の await Task.Delay(3000); が完了した時点では解放されていないので、その場所で開放されるのを永遠に待つことになってデッドロックに陥る。  

一方、コンソールアプリの方はキャプチャされるコンテキストが GUI アプリとは異なるそうです。「非同期プログラミングのベストプラクティス」に以下のように書いてあります。

"コンソールアプリケーションでは、一度に 1 つのチャンクに制限する SynchronizationContext ではなく、スレッドプールを備えた SynchronizationContext を使用するため、await が完了するとき、スレッド プールのスレッドで async メソッドの残り処理のスケジュールが設定されます。"

上のステップ 2 のところで TimeCosumingMethod メソッドの残りを実行するのは OS がスレッドプールから取得してきたスレッドになるようです。GUI アプリのように TimeCosumingMethod().Result で待機しているスレッドを使うわけではないのでデッドロックにはならないということだと思います。


ConfigureAwait によるデッドロックの回避に続く。

Tags: , , , , ,

.NET Framework

非同期プログラミング

by WebSurfer 13. September 2020 20:01

表題の「非同期プログラミング」と言うと高度な話のように思えるかもしれませんが、実は大したことは書いてなくて、ある機会にいろいろ調べたことを備忘録的に書いただけです。(汗)

Windows Forms アプリの ManagedThreadId

上の画像はそのいろいろ調べたことの一つで、Windows Forms アプリで非同期にメソッドを実行して ManagedThreadId プロパティの値がどうなるかを調べた結果です。説明は下の (2) に書きました。

(1) コンソールアプリの ManagedThreadId

以下のコードを実行すると結果はどうなるでしょう? ManagedThreadId は 1 ⇒ 3 ⇒ 3 とか、時々、1 ⇒ 3 ⇒ 4 と言うようにすべて違うスレッドになります。

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 メソッドの引数にある Console.WriteLine をメインスレッドとは別のスレッドで実行するものです。

何故 1 ⇒ 3 ⇒ 4 と言うようにすべて違うスレッドになるかというと、3 つの Console.WriteLine を実行するスレッドは、OS がその時の状況に応じてスレッドプールから良しなに選んでくるからということらしいです。

Microsoft のドキュメント「非同期プログラミングのベストプラクティス」の「すべて非同期にする」のセクションに以下のように書いてあります。

"コンソールアプリケーションでは、一度に 1 つのチャンクに制限する SynchronizationContext ではなく、スレッドプールを備えた SynchronizationContext を使用するため、await が完了するとき、スレッド プールのスレッドで async メソッドの残り処理のスケジュールが設定されます。"

"They have a thread pool SynchronizationContext instead of a one-chunk-at-a-time SynchronizationContext, so when the await completes, it schedules the remainder of the async method on a thread pool thread."

(注: 上の「一度に 1 つのチャンクに制限する SynchronizationContext」というのは GUI アプリと ASP.NET アプリに使われるものだそうです)

それが実行結果が 1 ⇒ 3 ⇒ 4 と言うようにすべて違うスレッドになることがあるという理由のようです。

(2) Windows Forms アプリの ManagedThreadId

この記事の一番上の画像が Windows Forms アプリで非同期にメソッドを実行して ManagedThreadId の値がどうなるか調べた結果です。

コンソールアプリとの一番大きな違いは。メインスレッド(UI スレッド)の ManagedThreadId の値は同じになる(上の画像の例では 1 で固定)、即ち同じスレッドが使われ続けるということです。

Microsoft のドキュメント「非同期プログラミングのベストプラクティス」の「すべて非同期にする」のセクションに以下のように書いてあり、これがメインスレッドには同じスレッドが使われ続ける理由のようです。

"既定では、未完了の Task を待機するときは、現在のコンテキストがキャプチャされ、Task が完了するときのメソッドの再開に使用されます。このコンテキストは現在の SynchronizationContext で、Null の場合は現在の TaskScheduler になります。GUI アプリケーションと ASP.NET アプリケーションには、一度に実行するコードを 1 つのチャンクに限定する SynchronizationContext があります。await が完了するときは、キャプチャしたコンテキスト内で async メソッドの残りを実行しようとします。"

"By default, when an incomplete Task is awaited, the current context is captured and used to resume the method when the Task completes. This context is the current SynchronizationContext unless it’s null, in which case it’s the current TaskScheduler. GUI and ASP.NET applications have a SynchronizationContext that permits only one chunk of code to run at a time. When the await completes, it attempts to execute the remainder of the async method within the captured context."

メッセージループでマウスのクリックやキーボードのストロークなどのユーザーイベントを処理して UI に反映する必要があることも、Windows アプリの UI スレッドは常に同じ&固定になる理由なのかもしれません(想像です)。

メッセージループに関しては、@IT の記事「第3回 Windowsアプリケーションの正体 (3/4)」や Microsoft のドキュメント「Application.Run メソッド」が自分的には参考になりました。

上の画像の Windows Forms アプリのコードを以下に書いておきます。

using System;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Threading;

// メインスレッドの ManagedThreadId は最後まで同じ ID が保たれる

namespace WinFormsApp1
{
    public partial class Form7 : Form
    {
        public Form7()
        {
            InitializeComponent();

            textBox1.Text = "呼び出されたメソッド内の";
        }

        private async void button2_Click(object sender, EventArgs e)
        {
            label1.Text = 
                $"メイン ID: {Thread.CurrentThread.ManagedThreadId} / ";
            label2.Text = "";

            // await キーワードは TimeCosumingMethod の中で別スレッド
            // で実行される部分が終了するのを待つという意味。
            // その間メッセージループは処理されるのでフリーズはしない
            label2.Text = await TimeCosumingMethod(textBox1.Text);

            label1.Text += Thread.CurrentThread.ManagedThreadId;
        }

        private void button1_Click(object sender, EventArgs e)
        {
            label3.Text = "[処理中にクリック]ボタンがクリックされた " + 
                Thread.CurrentThread.ManagedThreadId;
        }


        private async Task<string> TimeCosumingMethod(string s)
        {
            if (string.IsNullOrEmpty(s))
            {
                throw new ArgumentException("引数が無い");
            }
            s += $" ID: {Thread.CurrentThread.ManagedThreadId} / ";

            s += await MyMethod();

            s += Thread.CurrentThread.ManagedThreadId;

            return s;
        }


        private async Task<string> MyMethod()
        {
            string s1 = $"MyMethod {Thread.CurrentThread.ManagedThreadId} (IN), ";

            string s2 = await MyMethod2();

            s1 += $"{Thread.CurrentThread.ManagedThreadId} (OUT) / " + s2;
            return s1;
        }

        private async Task<string> MyMethod2()
        {
            string s = $"MyMethod2 {Thread.CurrentThread.ManagedThreadId} (IN), ";

            // Task.Delay(3000) で 3000 ms 後に完了するタスクを作成。
            // そのタスクは別スレッドで実行される。await があるので
            // タスクの完了を待つ
            await Task.Delay(3000);

            s += $"{Thread.CurrentThread.ManagedThreadId} (OUT) / ";
            return s;
        }
    }
}

上記のコードでは UI スレッドと別のスレッドで実行されるのは MyMethod2 メソッドの中の Task.Delay(3000) だけになるようです。上の画像で ManagedThreadId がすべて 1 になっているのがそれを裏付けていると思います。

ちなみに、TimeCosumingMethod メソッドの中で s += await MyMethod(); を s += await Task.Run(() => MyMethod()); に変更すると、MyMethod メソッドは UI スレッドとは別のスレッドで実行されます。結果は以下の画像のとおりで、赤枠の部分が上のケースとは異なってきます。

Windows Forms アプリの ManagedThreadId (その2)

(3) 訳が分からなかった話

下の画像はそのいろいろ調べた過程でコンソールアプリで間違った(?)やり方をして訳が分からなくなった結果です。また分からなくなると何なので(今でもホントに分かっているかは疑問ですが)、どういう話だったのかを書いておくことにしました。

コンソールアプリの ManagedThreadId

下のコードの実行結果が上の画像です。コードの中の (1) の方を実行しています。想像混じりですが、次のように動いていると思われます。

  1. TimeCosumingMethod の中に Task.Delay(5000) が無ければ 100% 単一のスレッドを使用する同期プログラミング。
  2. メインスレッド (ID = 1) で TimeCosumingMethod が呼び出され Task.Delay(5000) まで来る。  
  3. Task.Delay(5000) は 5000 ミリ秒後に完了する別スレッドのタスク。await が付与されているのでその場所でそのタスクの完了を待つ。別スレッドのタスクなのでその時点で ID = 1 のスレッドはフリーになる。(スレッドプールに戻す? それともそのまま同期実行を続ける?・・・そこが不明)
  4. TimeCosumingMethod には await は付与されてないので、すぐ次の行の HeavyMethod を実行しようとする。フリーになった ID = 1 のスレッドで HeavyMethod が実行される。
  5. TimeCosumingMethod 内の Task.Delay(5000) のタスクが完了すると、OS は ID = 4 のスレッドをスレッドプールから取得して、次の行 Console.WriteLine("Task.Delay(5000) の後 ...); から処理を再開する。  
  6. 結果、HeavyMethod は ID = 1 のスレッド、TimeCosumingMethod は ID = 4 のスレッドで並行して実行される形となり、それぞれコードに書かれたとおりのタイミングで文字列をコンソールに書き込んでいく。
  7. HeavyMethod の次の行の Console.WriteLine(task.Result); の引数 task.Result はそこで Wait メソッドを呼び出すことと同じ。それゆえ、そこで TimeCosumingMethod による「4秒経過」~「TimeCosumingMethod おわり」のコンソールへの書き込みを待つ。  
  8. TimeCosumingMethod 完了後、Console.WriteLine(task.Result) により「TimeCosumingMethod の戻り値」、次の Console.WriteLine("Main のおわり ...) により「Main のおわり」がコンソールに書き込まれてアプリは終了。
using System;
using System.Threading.Tasks;
using System.Threading;

namespace ConsoleAppAsync2
{
    class Program
    {
        static async Task Main(string[] args)
        {
            Console.WriteLine("Main のはじまり " + 
                Thread.CurrentThread.ManagedThreadId);

            // (1)
            Task<string> task = TimeCosumingMethod();
            HeavyMethod();

            // Task.Result プロパティの get アクセサーに
            // アクセスすると、非同期操作が完了するまで
            // 呼び出し元のスレッドがブロックされる。こ
            // れは、Wait メソッドを呼び出すことと同じ
            Console.WriteLine(task.Result);

            // (2)
            // 時間のかかる処理は別スレッドで非同期に実行
            // ということであれば以下のようにすると思う         
            //string result = await TimeCosumingMethod();
            //await Task.Run(() => HeavyMethod());
            //Console.WriteLine(result);

            Console.WriteLine("Main のおわり " + 
                Thread.CurrentThread.ManagedThreadId);

            Console.ReadLine();
        }

        static async Task<string> TimeCosumingMethod()
        {
            Console.WriteLine("TimeCosumingMethod はじまり " + 
                Thread.CurrentThread.ManagedThreadId);

            // Task.Delay(5000) で 5 秒後に完了するタスク
            // を作成。そのタスクは別スレッドで実行される
            // await でそのタスクの完了を待つ。await 無し
            // では完了を待たず下の行に進む
            await Task.Delay(5000);

            Console.WriteLine("Task.Delay(5000) の後 " + 
                Thread.CurrentThread.ManagedThreadId);

            for (int i = 0; i < 10; i++)
            {
                Thread.Sleep(1000);
                Console.WriteLine(i + 1 + "秒経過 " + 
                    Thread.CurrentThread.ManagedThreadId);
            }

            Console.WriteLine("TimeCosumingMethod おわり " + 
                Thread.CurrentThread.ManagedThreadId);

            return "TimeCosumingMethod の戻り値 " + 
                Thread.CurrentThread.ManagedThreadId;
        }

        static void HeavyMethod()
        {
            Console.WriteLine("HeavyMethod はじまり " + 
                Thread.CurrentThread.ManagedThreadId);

            Thread.Sleep(9000);

            Console.WriteLine("HeavyMethod おわり " +
                Thread.CurrentThread.ManagedThreadId);
        }
    }
}

時間のかかる処理を別スレッドで非同期に実行ということであれば、上のコードのコメントアウトした (2) のようにするのが普通と思います。その場合の実行結果は以下の画像のようになります。

コンソールアプリの ManagedThreadId (その2)

これなら少なくとも訳が分からないということはないと思うのですが、どうでしょう? まぁ、訳が分からないのは自分が無知だからということは否めませんが。(汗)


await と Task.Result によるデッドロックに続く。

Tags: , , ,

.NET Framework

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  September 2020  >>
MoTuWeThFrSaSu
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar