WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

Windows Forms 用 Chart Samples

by WebSurfer 30. November 2021 14:28

Chart Samples は Microsoft のサイトから Windows Forms 用と ASP.NET Web Forms 用の両方を入手できたのですが、そのページは現在リンク切れとなっており復活しそうもありません。Windows Forms アプリ用だけは別の入手先を見つけましたので、それを以下に書いておきます。

Windows Forms 用 Chart Samples

Windows Forms 用 Chart Samples は 2021/11/30 現在以下の GitHub のページからダウンロードできます。

Microsoft Chart for Windows Forms Samples Environment

上のページの右の方にある Latest というリンクをクリックするとダウンロードページに遷移しますので、そこで[Source code (zip)]をクリックすれば Samples-Environments-for-Microsoft-Chart-Controls-1.0.1.zip という名前の .zip ファイルがダウンロードされます。

ダウンロードした .zip ファイル

その zip ファイルの中に src というフォルダがあってそれに完全な Windows Forms アプリのソリューションとしてサンプルが含まれています。

それを適当なフォルダに解凍し、Visual Studio で WinFormsChartSamples.sln を開いて実行すれば、基本の解説、いろいろなタイプのサンプルのデモ、それを作るための C# および VB.NET サンプルコード等が満載の Windows Forms アプリが動くはずです。それがこの記事の一番上の画像です。

GitHub のページには "This is a backup of the Microsoft Chart for Windows Forms Samples Environment (Microsoft Chart Controls for Microsoft .NET Framework 3.5) ..." という記述がありますが、Visual Studio 2022 でソリューションを開いて[対象のフレームワーク(G)]みると .NET Framework 4 となってました。(3.5 というのは間違い?)

なお、ビルドする際、プロジェクトルート直下の MainForm.resx と Utilities\SampleMain フォルダの MainForm.resx に対して以下のエラーが出るかもしれません。

"ファイル MainForm.resx を処理できませんでした。インターネットまたは制限付きゾーン内にあるか、ファイルに Web のマークがあるためです。これらのファイルを処理するには、Web のマークを削除してください"

その場合は、エクスプローラーで対象のファイルのプロパティを開き、下の画像の赤枠で示したセキュリティの部分の[許可する(K)]にチェックを入れて[OK]をクリックすれば解決するはずです。

MainForm.resx のプロパティ

Microsoft のサイトからサンプルを入手した場合の設定方法はなどは先の記事は「Chart Samples」に書きました。今となっては役に立たなかもしれませんが、復活するかもしれないので記事は残しておきます。

Tags: , ,

.NET Framework

Task.Delay メソッドの謎 (続き)

by WebSurfer 28. July 2021 18:56

先の記事「Task.Delay メソッドの謎」の続きです。謎はまだ完全には解けていませんが、その後調べて分かったことをこの記事に書きます。(先の記事に続けて書くと長くなりすぎるので分けました)

まず、Microsoft のドキュメント Task.Delay メソッドの説明に書いてある "遅延後に完了するタスクを作成します" の「タスクを作成」とはどういうことかですが、それについては .NET Framework 4.8 ライブラリのソースコード Task.cs の Task.Delay メソッドを調べてみました。

ソースコードを簡略化して書くと以下のようになります。つまり、Task.Delay で System.Threading.Timer のインスタンスを生成し、それを Task クラスにラップして返しています。

public class Task
{
    public static Task Delay(int millisec)
    {
        var promise = new DelayPromise();

        promise.Timer = new System.Threading.Timer(
                            state => ((DelayPromise)state).Complete(),
                            promise,
                            millisec,
                            Timeout.Infinite);
        return promise;            
    }

    private sealed class DelayPromise : Task
    {
        internal System.Threading.Timer Timer;

        internal void Complete()
        {
            if (Timer != null) Timer.Dispose();
        }
    }
}

という訳で Task.Delay メソッドで作成されたタスクの実体は System.Threading.Timer ということは分かりました。

次なる謎は先の記事の Task.Delay を使ったサンプルコードの動きです。

先の記事のサンプルコードは、メインスレッドで 100 個の WorkAsync メソッドを同期的に順次開始し、await Task.WhenAll ですべての WorkAsync メソッドの完了を待機するという形になっています。WorkAsync メソッドには await Task.Delay(3000) が含まれています。サンプルコードを簡略化して書くと以下のようになります。

public async Task<string> WorkAsync(int number)
{
    // ・・・省略・・・
    string retunVlaue = $"n = {number}, ThreadID: {id}" +
                        $", start: {start:ss.fff}, ";
 
    await Task.Delay(3000);

    // ・・・省略・・・
    return retunVlaue;
}

public async Task ForLoopAsync()
{
    // ・・・省略・・・
 
    Task<string>[] taskResults = new Task<string>[100];

    taskResults[0] = WorkAsync(0);
    taskResults[1] = WorkAsync(1);
    taskResults[2] = WorkAsync(2);
    // ・・・省略・・・
    taskResults[99] = WorkAsync(99);
 
    await Task.WhenAll(taskResults);
 
    foreach (Task<string> result in taskResults)
    {
        Console.WriteLine(result.Result);
    }

    // ・・・省略・・・
}

ForLoopAsync メソッドを実行すると、まず最初に WorkAsync(0) が実行され、その中の await Task.Delay(3000) で 3 秒待機してから WorkAsync(0) が完了し、次の WorkAsync(1) メソッドの実行に進むというように、同期的に順次 WorkAsync(0) から WorkAsync(99) まで実行されていくと思っていました。

その場合、アプリ全体の実行時間は 3 秒 x 100 = 5 分かかるはずです。しかしながら、実際は先に記事に書いたように 3 秒少々で全体が完了します。そこが謎だったのですが、デバッガを使って追いかけてみて謎が分かりました。

最初に WorkAsync(0) が実行されその中の await Task.Delay(3000); の行が実行されると、そこで 3 秒待機するのではなく直ちに次の WorkAsync(1) が呼ばれます。WorkAsync(1) の中の await Task.Delay(3000); の行が実行されると直ちに次の WorkAsync(2) が呼ばれるというように、一気に最後の WorkAsync(99) まで呼ばれるところまで進んでから await Task.Delay(3000); で待機します。

そして 3 秒の待機が終わると、WorkAsync(0) から WorkAsync(99) の await Task.Delay(3000); の次の行から return retunVlaue; までが一気に実行され、戻り値が Task<string> 型の配列 taskResults に代入されるという動きになります。

それゆえアプリ全体の実行時間は 3 秒少々しかかからないという結果になったようです。

サンプルコードの実行時間が 3 秒少々しかかかからなかった理由は分かりましたが、なぜ WorkAsync(0) から WorkAsync(99) のそれぞれで同期的に 3 秒待機してから次に進むのではなく、WorkAsync メソッドが最初から最後まで一気に呼ばれてから待機するのかは分かりません。

ちなみに、Task.WhenAll は使わないで各 WorkAsync メソッドに await を付与すると各メソッドの実行時に 3 秒待機してから次のメソッドが実行されるようになります。

string[] stringResults = new string[100];
stringResults[0] = await WorkAsync(0);
stringResults[1] = await WorkAsync(1);
stringResults[2] = await WorkAsync(2);
// ・・・省略・・・
stringResults[99] = await WorkAsync(99);

Task.WhenAll が影響しているような気がしますが、どうも自分には Task とか Timer に関する理解が致命的に欠けているようで、そのあたりメカニズムが分かりません。勉強が足りないようです。


以下はオマケです。

上のような自作 Task.Delay メソッドのコードを実装しても期待通りには動きませんでした。原因不明ですが、いろいろ試した結果とそれに基づく想像を備忘録として以下に書いておきます。

当たり前ですが、.NET Framework ライブラリを使って await Task.Delay(3000) とした場合はそこで 3 秒待機した後次の行に進みます。ところが、上の自作コードを使って Task.Delay(3000) というように「タスクを作成」してそれを await するとそこで止まってしまいます。()

DelayPromise コンストラクタを呼び出して作成した Task なので「タスクを作成」した時点では TaskStatus は Created になります。その後 TaskStatus は Created のまま変わらないので await するとそこで止まってしまうということのようです。 (TaskStatus が RanToCompletion にならないと await は抜け出せないようです)

Task を Start するコードを追加すると、TaskStatus は WaitingToRun ⇒ Running ⇒ RanToCompletion と変わっていきますが await で待機しません。設定した遅延時間の 3 秒後に Complete コールバックに制御は飛んでくるので Task は期待通り動いているようですが、.NET Framework の制御を外れて勝手に動いているという感じです。

ただし、普通に Task コンストラクタで Task を生成して Start する場合、例えば以下のようにすると .NET Framework の制御下で動くようです。(Start しないと TaskStatus は Created のまま変わらず、await で止まってしまうのは上と同じです)

Task t = new Task(() =>
    { 
        Console.WriteLine("new Task"); 
        Thread.Sleep(3000); 
    });

t.Start();
await t;

t.Start(); で TaskStatus は WaitingToRun となり、Thread.Sleep(3000); を抜けて Task が完了すると RanToCompletion に変わります。上のコードのように await t; とすると期待通りそこで待機します。await で待機中に Task が完了し TaskStatus が RanToCompletion に変わってから await を抜けるという感じです。

ちなみに、.NET Framework ライブラリの Task.Delay は Start せずとも TaskStatus は WaitingForActivation になって、設定した遅延時間の後 RanToCompletion になります。await で待機した場合は、待機中に Task が完了して TaskStatus が RanToCompletion になると await を抜けるようです。

ライブラリの場合は、await による .NET Framework の制御が働くよう、ライブラリに定義してある下記の Task のコンストラクタで設定される m_stateFlags が良しなに計らってくれているような気がします。(想像&気がするだけです)

internal Task()
{
    m_stateFlags = TASK_STATE_WAITINGFORACTIVATION | 
                   (int)InternalTaskOptions.PromiseTask;
}

Tags: , , , ,

.NET Framework

Task.Delay メソッドの謎

by WebSurfer 21. July 2021 18:27

Microsoft のドキュメントの Task.Delay メソッドの説明には "遅延後に完了するタスクを作成します。 Creates a task that will complete after a time delay." と書いてあります。

その「タスクを作成」とはどういう意味でしょう? 作成されたタスクは何がどのように動かしているのでしょう? 色々調べたのですが分かりませんでした。謎が解けたら追記しますが、とりあえず今まで調べたことを整理して書いておきます。 ⇒ 謎はまだ完全には解けていませんが、その後調べて分かったことを別の記事「Task.Delay メソッドの謎 (続き)」に書きました

とにかく、Task.Delay メソッドが作成した「遅延後に完了するタスク」は作成後動いていることは間違いなさそうです。(そんなの当たり前?)

なぜなら、(1) Task.Delay メソッドの第 1 引数に与えられた時間通りに遅延&完了しますが、そもそもタスクが動いてなければ開始も完了もないはず、(2) 第 2 引数で CancellationToken を渡すオーバーロードではキャンセルすると TaskCanceledException がスローされるのですが、それには常にキャンセル通知をチェックする必要があるはず・・・ですから。

では、一体何がその「遅延後に完了するタスク」を動かしているのでしょう?

以前は Task.Delay メソッドが「遅延後に完了するタスク」を作成して、スレッドプールからスレッドを取得し、作成したタスクを実行すると思っていたのですが、以下のコードで検証した結果を見る限りそうではなさそうな感じです。

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

namespace ConsoleAppWenAllParallelFor
{
    class Program
    {
        static async Task Main(string[] args)
        {
            int minWorker; // ワーカースレッドの最小数(PC のコア数と同じ)
            int minIOC;    // 非同期 I/O スレッドの最小数
            ThreadPool.GetMinThreads(out minWorker, out minIOC);
            Console.WriteLine($"minWorker: {minWorker}, minIOC: {minIOC}");

            int maxWorker; // ワーカー スレッドの最大数
            int maxIOC;    // 非同期 I/O スレッドの最大数
            ThreadPool.GetMaxThreads(out maxWorker, out maxIOC);
            Console.WriteLine($"maxWorker: {maxWorker}, maxIOC: {maxIOC}");

            var prog = new Program();
            await prog.ForLoopAsync();
        }

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

            // ここで 3 秒遅延
            await Task.Delay(3000);            

            // 検証用。詳細は後述
            //await Task.Run(() => Thread.Sleep(3000));
            //await Task.Run(() => Task.Delay(3000).Wait());

            DateTime end = DateTime.Now;
            TimeSpan diff = start - end;
            retunVlaue += $"end: {end:ss.fff}, timespan: {diff:s\\.fff}";
            return retunVlaue;
        }

        // 非同期メソッド WorkAsync を for ループで 100 実行
        public async Task ForLoopAsync()
        {
            int id = Thread.CurrentThread.ManagedThreadId;
            DateTime start = DateTime.Now;
            Console.WriteLine($"Main Thread ID = {id}, " +
                $"ForLoopAsync 開始: {start:ss.fff}");

            Task<string>[] taskResults = new Task<string>[100];
            for (int i = 0; i < 100; i++)
            {
                int n = i;
                taskResults[n] = WorkAsync(n);
            }

            await Task.WhenAll(taskResults);

            foreach (Task<string> result in taskResults)
            {
                Console.WriteLine(result.Result);
            }

            DateTime end = DateTime.Now;
            TimeSpan diff = start - end;
            Console.WriteLine($"Main Thread ID = {id}, " +
                $"終了: {end:ss.fff}, 所要時間: {diff:s\\.fff}");
        }
    }
}

上のコードの実行結果は以下のようになります。画像には n = 20 までしか示していませんがその後 n = 99 まで続きます。

ForLoopAsync メソッド実行結果

n = 0 ~ 99 の start が 00.065 ~ 00.082 の範囲 (17ms)に入っており、end はすべて同じ時刻 03.122 になり、アプリ全体の所要時間は Task.Delay(3000) による遅延とほぼ同じ 3.072 秒という結果でした

ということは、17ms の間に for ループで 100 個の WorkAsync メソッドが同期的に開始され、それぞれの WorkAsync メソッドの中の Task.Dealy(3000) で 3000ms 遅延後に完了するタスクが作成・実行され、await でタスクの終了を待機し、待機が終わって WorkAsync メソッドが時刻 03.122 に 100 個同時に終わり(1ms 以下の差はあるかも)、全体のアプリが 3.072 秒で完了したということになります。ホントかなぁ・・・という気はしますが結果の画像はそう言っているようです。

結果から、Task.Dealy(3000) で作成された「遅延後に完了するタスク」100 個はスレッドプールからスレッドを取得して実行されたという訳ではなく、単に 3 秒止まっていただけというように見えます。

スレッドプールのスレッドを使う場合、先の記事「タスク並列ライブラリ (TPL) その 2」で書きましたように、スレッドプールから一度に取得できるスレッドの数は限られているので(検証に使った PC ではデフォルトで 8)、スレッドの取得にかかる時間を考えるとアプリ全体が 3.072 秒で完了ということはないからです。

(Task.Dealy が作成する「遅延後に完了するタスク」は特別で、スレッドプールから一度に 100 個スレッドを取得できるということなら話は別ですが)

Task.Dealy を実行したスレッドが、Task.Dealy が作成した「遅延後に完了するタスク」を実行することはもちろんなさそうです。そもそも、Thread.Sleep と違って、スレッドをブロックしないようにするのが Task.Delay のはずですから。

という訳で、一体何がどのようにTask.Dealy が作成した「遅延後に完了するタスク」を実行しているのかが謎です。今後の課題ということで、調べて何か分かったら追記します。

ちなみにですが、上のサンプルコードの、

await Task.Delay(3000);

を、

await Task.Run(() => Thread.Sleep(3000));

に代えると結果が違ってきます。Task.Run で Thread.Sleep(3000) をスレッドプールで実行するタスクとしてキューに並べるので、OS がスレッドプールからスレッドを取得して Thread.Sleep(3000) を実行し、その際スレッドは 3 秒ブロックされます。結果は以下のようになります。

Thread.Sleep(3000) の場合

n = 0 ~ 99 の start が 23.257 ~ 23.312 の範囲 (55ms)に入っていますが、end は 26.228 ~ 43.305 となっており、Thread.Sleep(3000) を実行するためのスレッドの取得に時間がかかっていることが分かります。アプリ全体の所要時間は 20.072 秒という結果でした。

もう一つオマケで書いておきます。 上の Thread.Sleep(3000) を Task.Delay(3000).Wait() に代えると少し様子が違ってきます。

Task.Delay(3000).Wait() の場合

n = 0 ~ 99 の start は 03.056 ~ 03.114 の範囲 (58ms)、end は 06.553 ~ 28.576 の範囲、全体の所要時間は 25.540 秒という結果でした。Thread.Sleep に比べて全体の所要時間が長くなることと、n = 5, 9 に必要以上の時間スレッドを解放できない特異点的なものがあるのが気になります。

Tags: , , , ,

.NET Framework

About this blog

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

Calendar

<<  December 2021  >>
MoTuWeThFrSaSu
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

View posts in large calendar