WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

タスク並列ライブラリ (TPL)

by WebSurfer 2020年12月27日 14:53

タスク並列ライブラリ (TPL) は Windows Forms のような GUI アプリでは使い難い点があるということを今更ながらですが学びましたので、備忘録として書いておきます。

タスク並列ライブラリの検証

最近の PC の CPU はマルチコアが当たり前になっているようですが、PC のマルチコアを有効に使うプログラミングをサポートするため、.NET Framework 4.0 で導入されたタスク並列ライブラリ (TPL・・・Parallel.For とか Parallel.Invoke とか) を利用するという話を巷でよく耳にします。

マルチスレッドの基本的な話ですが、@IT の記事「第1回 マルチスレッドはこんなときに使う (1/2)」の「マルチスレッドの動作原理」セクションを見てください。リンク切れになると困るので画像だけ借用して以下に表示しておきます。

マルチスレッドの比較

② のようになると OS がスレッドを切り替えて処理を行うのでそのオーバーヘッドの分逆に遅くなるということになります。なので、マルチスレッドアプリで処置時間の短縮を図るなら ③ のようにマルチコアを利用できる環境が必要で、さらにマルチコアを有効に利用するプログラミングを行うという話になると思います。

その際に自分がよく聞くのがタスク並列ライブラリ (TPL) や Parallel LINQ (PLINQ) を使うという話です。Microsoft のドキュメント「.NET での並列プログラミング」や、ググるとヒットする記事例えば @IT の記事「ループをParallelクラスで並列処理にするには?」を読むと TPL, PLINQ は並列処理には万能のような気がしてました。

Microsoft のドキュメント「タスク並列ライブラリ (TPL)」には、

"TPL は、使用可能なすべてのプロセッサを最も効率的に使用するように、コンカレンシーの程度を動的に拡大します。The TPL scales the degree of concurrency dynamically to most efficiently use all the processors that are available."

・・・と言う記述がありますし、PC のマルチコアを有効に使うという局面に限れば最強のように思えます。

しかし、Windows Forms のような GUI アプリではそうでもなさそうな感じです。自分が気が付いた限りですが、以下の 2 点が問題だと思いました。(自分が回避策を知らないだけという可能性は否定できませんが )

  1. 並列に実行される複数のメソッドがすべて完了するまで UI がブロックされる。 ⇒ PLINQ 以外は async / await を使って回避できる方法がありました。下の【2021/6/13 追記】を見てください
  2. 並列実行するメソッドには非同期版は使えない。

以下のサンプルコードの ParallelInvoke_Click メソッドは Parallel.Invoke を使って 5 つの同期版メソッド Work を並列に実行するものですが、5 つのメソッドがすべて完了するまで UI がブロックされるので、アプリはフリーズしたようになります。その他の TPL, PLINQ を使った xxxxx_Click メソッドも同様で、完了するまで UI がブロックされます。それを回避する手段は、自分が探した限りですが、なさそうです。

さらに、非同期版メソッド WorkAsync は使えません。詳しくはサンプルコードのコメントに書きましたので見てください。なので、ライブラリなどで非同期版メソッドしか提供されてない場合は何ともならないと思われます。

というわけで、下のサンプルコードの WhenAll1_Click, WhenAll2_Click メソッドのように、Parallel.Invoke など使わないで、await Task.WhenAll(...) で待機するようにし、並列化については OS に任せるのが良さそうと思いました。(実際にサンプルを動かしてみると並列化してくれているような感じはしました。② のようになっている可能性は否定しきれませんが)

非同期版メソッド WorkAsync も使えます。下のサンプルコードの WhenAll2_Click メソッドを見てください。上の画像がその実行結果です。(ThreadID が 1 で UI スレッドと同じなのは、WorkAsync メソッドの中で ManagedThreadId を取得するのが UI スレッドだからです)

using System;
using System.Windows.Forms;
using System.Threading;
using System.Threading.Tasks;
using System.Collections.Generic;
using System.Linq;

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

        // 同期版メソッド
        private string Work(int n)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            string retunVlaue =
                $"n = {n}, ThreadID = {id}, start:{DateTime.Now:ss.fff}, ";

            Thread.Sleep(3000);

            retunVlaue += $"end:{DateTime.Now:ss.fff}";

            return retunVlaue;
        }

        // 非同期版メソッド
        private async Task<string> WorkAsync(int n)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            string retunVlaue =
                $"n = {n}, ThreadID = {id}, start: {DateTime.Now:ss.fff}, ";

            await Task.Delay(3000);

            retunVlaue += $"end: {DateTime.Now:ss.fff}";

            return retunVlaue;
        }

        // 非同期版メソッド 5 つを for ループで逐次実行
        private async void InOrder_Click(object sender, EventArgs e)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            this.label1.Text = $"UI Thread ID = {id}\r\n";

            for (int n = 0; n < 5; n++)
            {
                this.label1.Text += await WorkAsync(n) + "\r\n";
            }

            this.label1.Text += "完了";
        }

        // 同期版メソッド 5 つを Parallel.Invoke で実行
        // Executes each of the provided actions, possibly in parallel.
        // 終了まで UI はブロックされる
        private void ParallelInvoke_Click(object sender, EventArgs e)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            this.label1.Text = $"UI Thread ID = {id}\r\n";

            string[] results = new string[5];

            Parallel.Invoke(
                () => results[0] = Work(0),
                () => results[1] = Work(1),
                () => results[2] = Work(2),
                () => results[3] = Work(3),
                () => results[4] = Work(4));

            foreach (string result in results)
            {
                this.label1.Text += result + "\r\n";
            }

            this.label1.Text += "完了";

            // 非同期版メソッド WorkAsync は使えない

            // Task.Result でデッドロックになる
            //Task<string> result1 = null, result2 = null;
            //Parallel.Invoke(
            //    () => result1 = WorkAsync(0),
            //    () => result2 = WorkAsync(1));
            //this.label1.Text += result1.Result + "\r\n";
            //this.label1.Text += result2.Result + "\r\n";

            // await で待つことなく終わってしまう
            //string result1 = "", result2 = "";
            //Parallel.Invoke(
            //    async () => result1 = await WorkAsync(0),
            //    async () => result2 = await WorkAsync(1));
            //this.label1.Text += result1 + "\r\n";
            //this.label1.Text += result2 + "\r\n";

        }

        // 同期版メソッド 5 つを Parallel.For で実行
        // Executes a for loop in which iterations may run in parallel.
        // 終了まで UI はブロックされる
        private void ParallelFor_Click(object sender, EventArgs e)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            this.label1.Text = $"UI Thread ID = {id}\r\n";

            string[] results = new string[5];

            Parallel.For(0, 5, n => results[n] = Work(n));

            foreach (string result in results)
            {
                this.label1.Text += result + "\r\n";
            }

            this.label1.Text += "完了";
        }

        // 同期版メソッド 5 つを Parallel.ForEach で実行
        // Executes a foreach operation in which iterations may run in parallel.
        // 終了まで UI はブロックされる
        private void ParallelForEach_Click(object sender, EventArgs e)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            this.label1.Text = $"UI Thread ID = {id}\r\n";

            string[] results = new string[5];

            Parallel.ForEach(Enumerable.Range(0, 5), 
                             n => results[n] = Work(n));

            foreach (string result in results)
            {
                this.label1.Text += result + "\r\n";
            }

            this.label1.Text += "完了";
        }

        // 同期版メソッド 5 つを PLINQ で実行
        // PLINQ は、シ��テムのすべてのプロセッサを十分に活用しようとする。
        // そのために、データ ソースをセグメントにパーティション分割し、
        // 複数のプロセッサで個々のワーカー スレッドの各セグメントに対して
        // クエリを並行実行します。
        // 終了まで UI はブロックされる
        private void PLINQ_Click(object sender, EventArgs e)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            this.label1.Text = $"UI Thread ID = {id}\r\n";

            var results = Enumerable.Range(0, 5).AsParallel().
                          Select(n => Work(n));

            foreach (string result in results)
            {
                this.label1.Text += result + "\r\n";
            }

            this.label1.Text += "完了";
        }

        // ***** 以下 TPL, PLINQ に代えて Task.WhenAll を使用 *****

        // 同期版メソッド 5 つを Task.Run で実行、
        // await Task.WhenAll で待機        
        private async void WhenAll1_Click(object sender, EventArgs e)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            this.label1.Text = $"UI Thread ID = {id}\r\n";

            string[] results = new string[5];
            var taskList = new List<Task>();
            for (int n = 0; n < 5; n++)
            {
                int i = n;
                taskList.Add(Task.Run(() => results[i] = Work(i)));
            }

            // WaitAll ではブロックされてしまう。
            // WhenAll でないと await で待機できないので注意
            await Task.WhenAll(taskList.ToArray());

            foreach (string result in results)
            {
                this.label1.Text += result + "\r\n";
            }

            this.label1.Text += "完了";
        }

        // 非同期版メソッド 5 つを実行、
        // await Task.WhenAll で待機
        private async void WhenAll2_Click(object sender, EventArgs e)
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            this.label1.Text = $"UI Thread ID = {id}\r\n";

            Task<string>[] results = new Task<string>[5];

            for (int n = 0; n < 5; n++)
            {
                int i = n;
                results[i] = WorkAsync(i);
            }

            // WaitAll ではデッドロックになる
            await Task.WhenAll(results);

            foreach (Task<string> result in results)
            {
                this.label1.Text += result.Result + "\r\n";
            }

            this.label1.Text += "完了";
        }
    }
}

-----【2021/6/13 追記】-----

UI スレッドがブロックされるのを回避する方法ですが、Parallel LINQ (PLINQ) 以外は、.NET Framework 4.5 から導入された async / await を使って TPL の部分を await Task.Run で動かすと UI スレッドはブロックされず、メッセージループでマウスのクリックやキーボードのストロークなどのユーザーイベントが処理されることが分かりました。

具体的には、Parallel.For を使った場合を例に取ると、以下のようにします。

private async void ParallelFor_Click(object sender, EventArgs e)
{
    int id = Thread.CurrentThread.ManagedThreadId;
    this.label1.Text = $"UI Thread ID = {id}\r\n";

    string[] results = new string[5];

    await Task.Run(() => Parallel.For(0, 5, n => results[n] = Work(n)));

    foreach (string result in results)
    {
        this.label1.Text += result + "\r\n";
    }

    this.label1.Text += "完了";
}

ただ、async / await が使えるなら、上のコード例の await Task.WhenAll で待機することもできますので、TPL は使わなくても良いのではないかという気はします。上に書いた "TPL は、使用可能なすべてのプロセッサを最も効率的に使用するように、コンカレンシーの程度を動的に拡大します" という点に意味があるのかもしれませんが。

なお、Parallel LINQ (PLINQ) の方は以下のようにしてみたのですが UI スレッドがブロックされるのは回避できないようで、マウスのクリックなどのユーザーイベントには無反応(フリーズ状態)のままになります。

var results = await Task.Run(() => Enumerable.Range(0, 5)
                                   .AsParallel()
                                   .Select(n => Work(n)));

PLINQ では回避できない理由や対応策は分かりません。今後の検討課題ということで。

Tags: , , , , ,

.NET Framework

ASP.NET MVC の非同期プログラミング

by WebSurfer 2020年10月4日 15:50

ASP.NET MVC アプリで async / await を利用した非同期プログラミングで (1) 使用されるスレッドがどのようになるか、(2) Task.Result などを使った同期コードと非同期コードを混在させるとデッドロックは起きるのか、(3) ConfigureAwait メソッドでデッドロックは回避できるのかについて書きます。(.NET Framework アプリの話です。ASP.NET Core 3.1 MVC アプリの検証結果は別の記事に書きました)

ASP.NET MVC の非同期プログラミング

ちなみに ASP.NET Web Forms アプリ用の HTTP ハンドラで async / await を使って非同期呼び出しをする話は先の記事「非同期 HTTP ハンドラ (2)」に書きましたので興味があればそちらを見てください。

(1) 使用されるスレッド

ASP.NET で非同期プログラミングを行う目的はスレッドプールにある限られた数のスレッドを有効利用しスループットを向上するためです。そこが UI の応答性の向上を目的としている Windows Forms のような GUI アプリと違うところです。

ASP.NET アプリでは Web サーバーがクライアントから要求を受けるとスレッドプールからスレッドを確保して要求を処置します。非同期操作をしなければ、要求を受けてから応答を返すまで最初に確保したスレッドを保持し続けます。

Web アプリでは、外部のデータベースや Web API などにアクセスしてデータを取得するということが多いと思いますが、それに時間がかかる場合は一旦使っていたスレッドはスレッドプールに戻し、データ取得後の処理はスレッドプールから新たにスレッドを取得して行うようにすればスレッドプールのスレッドの有効利用が可能です。

そのあたりの詳細は Microsoft のドキュメント「ASP.NET の非同期/待機の概要」に図解入りで説明されているので見てください。

非同期プログラミングを行うと await 前後で実際にスレッドは違うのかを ASP.NET MVC アプリで試した結果が上の画像です。そのコードは以下の通りです。

public async Task<ActionResult> AsyncTest()
{
    ViewBag.Id1 = "開始時, ID=" + 
                  Thread.CurrentThread.ManagedThreadId;

    ViewBag.Id2 = await TimeCosumingMethod();

    ViewBag.Id3 = "終了時, ID=" + 
                  Thread.CurrentThread.ManagedThreadId;

    return View();
}

private async Task<string> TimeCosumingMethod()
{
    int id = Thread.CurrentThread.ManagedThreadId;

    await Task.Delay(3000);

    return "TimeCosumingMethod の戻り値, ID(IN)=" + id + 
           " / ID(OUT)=" + Thread.CurrentThread.ManagedThreadId;
}

上の画像の ID の数字 (ManagedThreadId) を見てください。TimeCosumingMethod メソッドの await 前後で ManagedThreadId が 6 から 7 に変わっています。ちなみに、Windows Forms のような GUI アプリでは await 前後いずれも UI スレッドになり ManagedThreadId は変わりません。

ASP.NET でも await で待機するときに現在のコンテキストがキャプチャされ、await 完了後はキャプチャしたコンテキストで続きの処理が行われるのは GUI アプリと同様だそうですが、await 前後で同じになるようにしているのはスレッドではなく HttpContext だそうです。それは仕組み上当たり前&そうせざるを得ないと思います。

(2) Task.Result でデッドロック

先の記事「await と Task.Result によるデッドロック」で書いたような Task.Result を使った同期コードと非同期コードを混在させるとデッドロックは起きるでしょうか?

その記事にも少し書きましたが、上のコードの await TimeCosumingMethod() を TimeCosumingMethod().Result に代えるとデッドロックは起きます。そのメカニズムは以下のようなことであろうと思います。

まず、TimeCosumingMethod().Result で 1 つの同期ブロックが待機中となる。呼び出された TimeCosumingMethod メソッドの await で待機する際にキャプチャされた「現在のコンテキスト」で await 完了後の同期処理を実行しようとする。しかし「現在のコンテキスト」では一度に実行するコードは 1 つのチャンクに限定されている。なので、Result プロパティでの待機が終わるまで await 完了後の同期処理は実行できない。結果デッドロックになる。

(3) ConfigureAwait でデッドロック回避

先の記事「ConfigureAwait によるデッドロックの回避」で書いたように、await 完了後の同期処理を実行するのに、await で待機する際にキャプチャした「現在のコンテキスト」ではなく、別のコンテキストで行えばデッドロックにはなりません。

ConfigureAwait メソッドの使用

以下のコードのように ConfigureAwait(false) を追加することにより、await 完了後の残り処理は、キャプチャしたコンテキストではなく、スレッドプールのコンテキストで処理されるのでデッドロックは回避でき、上の画像のとおり実行が完了します。

public async Task<ActionResult> AsyncTest()
{
    ViewBag.Id1 = "開始時, ID=" + 
                  Thread.CurrentThread.ManagedThreadId;

    ViewBag.Id2 = TimeCosumingMethod().Result;

    ViewBag.Id3 = "終了時, ID=" + 
                  Thread.CurrentThread.ManagedThreadId;

    return View();
}

private async Task<string> TimeCosumingMethod()
{
    int id = Thread.CurrentThread.ManagedThreadId;

    // ConfigureAwait(false) を追加するとデッドロックは回避できる
    await Task.Delay(3000).
        ConfigureAwait(continueOnCapturedContext: false);

    return "TimeCosumingMethod の戻り値, ID(IN)=" + id + 
           " / ID(OUT)=" + Thread.CurrentThread.ManagedThreadId;
}

ただし、スレッドは await 前後で同じになります。ということは、要求を受けた時に確保したスレッドを応答を返すまでずっと使い続けていたということで、スレッドの有効利用という ASP.NET の非同期の目的は果たせてないようです。

await 前後でスレッドが異なる場合は、await 前にキャプチャしたコンテキストを await 後でも使わないと HttpContext が渡せないが、continueOnCapturedContext: false ではそれができないので同じスレッドを使い続けざるを得ないということではないかと思います。

Tags: , , ,

MVC

SynchronizationContext とは?

by WebSurfer 2020年9月30日 15:53

SynchronizationContext とは何かを調べましたので、十分とは言えないまでも取りあえず分かった(分かった気になっただけかもしれませんが)ことを備忘録として書いておきます。

SynchronizationContext

非同期プログラミングの勉強の際に、Microsoft のドキュメント「非同期プログラミングのベストプラクティス」を読んだのですが、詳しい説明なしでいきなり、

"・・・async void メソッドが開始されたときにアクティブだった SynchronizationContext で直接発生します・・・・・・未完了の Task を待機するときは、現在の "コンテキスト" がキャプチャされ、Task が完了するときのメソッドの再開に使用されます。この "コンテキスト" は現在の SynchronizationContext で・・・"

というように SynchronizationContext という言葉が出てきます。上記の他にも何か所かで出てくるのですが、非同期プログラミングを理解するのに重要なキーワードのようで、それが何かを理解してない自分には、そのドキュメントの内容が半分も理解できませんでした。

Microsoft のドキュメント「SynchronizationContext クラス」によると .NET Framework 2.0 の時代から存在していたようで、以下のように説明されています。

"同期コンテキストをさまざまな同期モデルに反映させるための基本機能を提供します。SynchronizationContext クラスは、同期なしのフリー スレッド コンテキストを提供する基本クラスです。このクラスで実装する同期モデルの目的は、共通言語ランタイムの非同期または同期の内部操作をさまざまな同期モデルで正しく動作させることです。"

残念ながらその説明では自分の頭では全く理解できません。なので、そのドキュメントからリンクが貼ってある MSDN マガジンの記事「並列コンピューティング - SynchronizationContext こそすべて」を読んでみました。

他に「async/await と SynchronizationContext」、「async/awaitと同時実行制御」、「ASP.NET の非同期でありがちな Deadlock を克服する」という記事を参考にさせていただきました。これらは Microsoft のドキュメントに比べれば少し分かりやすかったです。

上の記事を読んで、SynchronizationContext とは何かを理解する上で重要と思った点を以下にまとめておきます。無知ゆえの独断と偏見による個人的解釈も含まれているので注意してください。

  1. マルチスレッドプログラムでは、あるスレッドから別のスレッドに作業単位を受け渡す必要が生じることがよくある。SynchronizationContext クラスはそれを支援するツール。
  2. Windows Forms, WPF, ASP.NET, Silverlight, コンソールアプリなど、すべての .NET プログラムには SynchronizationContext の概念が含まれる。(公式ドキュメントを見ると .NET だけでなく Core なども適用対象に含まれているようです)  
  3. 古くはメッセージキューを使用して作業単位を受け渡していたが、.NET Framework が登場した時に汎用ソリューションとして ISynchronizeInvoke が考案され、その後 .NET Framework 2.0 で ASP.NET の非同期プログラミングをサポートするため SynchronizationContext に置き換えられた。
  4. SynchronizationContext の特徴は (1) 作業単位をコンテキストのキューにする (unit of work is queued to a context rather than a specific thread)、(2) 全てのスレッドは "現在の" コンテキストを持つ (every thread has a “current” contex)、(3) 未完了の非同期操作の数を管理する (it keeps a count of outstanding asynchronous operations)。
  5. Windows Forms, WPF, ASP.NET に使用されている SynchronizationContext はそれぞれ実装が異なっており、順に以下の通りとなる。(Current プロパティで確認できる)

    WindowsFormsSynchronizationContext
    DispatcherSynchronizationContext
    AspNetSynchronizationContext (.NET 4.5 以降)
  6. Windows Forms, WPF などの GUI アプリでは、await で待機するとき現在の SynchronizationContext がキャプチャされ、await が完了するとキャプチャした SynchronizationContext で続きを実行する。その際に使われるスレッドは await 前後で同じ、即ち UI スレッドになる。
  7. ASP.NET でも await 前後での SynchronizationContext のキャプチャと続きの実行は GUI アプリと同様だが、await 前後で HttpContext が同じになるようにしている。await 前までに使っていたスレッドはスレッドプールに戻し、await が完了後の処理はスレッドプールから新たにスレッドを取得して行う。(GUI アプリとは非同期にする目的が違うため。詳しくは「ASP.NET の非同期/待機の概要」を参照)
  8. コンソールアプリでは SynchronizationContext.Current プロパティは null になる(ということは、await で待機する際に「現在の SynchronizationContext をキャプチャ」ということはないはず)。await が完了するとき、スレッドプールを備えた既定の SynchronizationContext を使って、スレッドプールのスレッドで async メソッドの残り処理のスケジュールが設定される。(なので、「await と Task.Result によるデッドロック」に書いたようなデッドロックには陥らない)

async / await を使った非同期プログラミングではプログラマが SynchronizationContext を意識することはほとんどなさそうで、知らなくても済むような気がします。

実際、以下の画像の赤枠部分のコードのように Control.Invoke の代わりに SynchronizationContext.Post メソッドが使えるということぐらいしか使い道は思い当たりません。(自分が知らないだけという可能性は否定できませんが)

SynchronizationContext.Post

MSDN マガジンの記事「並列コンピューティング - SynchronizationContext こそすべて」にも "開発者を支援するために SynchronizationContext クラスが用意されています。残念なことに、多くの開発者はこの便利なツールに気が付いてすらいません" と書いてありましたが、そうだろうなと思いました。

ただ、async / await を使った非同期プログラミングでも内部的には SynchronizationContext が大きく関与しているのは間違いなく、上記の程度は知っておいて損はないかもしれませんね。

Tags: , ,

.NET Framework

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar