.NET: マルチスレッドと非同期を操作するためのツール。 パート1

私はHabrに関するオリジナルの記事を公開しており、その翻訳はコーポレートサイトに掲載されています ブログ記事.

今すぐ結果を待たずに何かを非同期で実行する必要性や、大規模な作業を複数のユニットに分割して実行する必要性は、コンピューターの出現以前から存在していました。 彼らの出現により、この必要性が非常に具体的になりました。 2019 年の今、私は 8 コア Intel Core プロセッサーを搭載したラップトップでこの記事を入力しています。このプロセッサーでは 8 を超えるプロセスが並列実行され、さらに多くのスレッドが実行されています。 近くには、数年前に購入した、16 コアのプロセッサを搭載した少しみすぼらしい携帯電話があります。 テーマ別リソースには、著者が 20 コア プロセッサを搭載した今年の主力スマートフォンを賞賛する記事やビデオが満載です。 MS Azure は、128 コア プロセッサと 2 TB RAM を搭載した仮想マシンを XNUMX 時間あたり XNUMX ドル未満で提供します。 残念ながら、スレッドの相互作用を管理できなければ、この能力を最大限に引き出して活用することは不可能です。

用語

プロセス - OS オブジェクト、分離されたアドレス空間にはスレッドが含まれます。
糸 - OS オブジェクト、実行の最小単位、プロセスの一部、スレッドはプロセス内でメモリやその他のリソースを共有します。
マルチタスク - OS プロパティ、複数のプロセスを同時に実行する機能
マルチコア - プロセッサの特性、データ処理に複数のコアを使用する機能
マルチプロセッシング - コンピュータの特性、物理的に複数のプロセッサを同時に動作させる能力
マルチスレッド化 — プロセスのプロパティ、データ処理を複数のスレッドに分散する機能。
平行度 - 単位時間当たり複数のアクションを物理的に同時に実行する
非同期性 — この処理の完了を待たずに操作を実行します。実行結果は後で処理できます。

比喩

すべての定義が適切であるわけではなく、追加の説明が必要な定義もあるので、正式に導入された用語に朝食の調理に関する比喩を追加します。 この比喩では、朝食を作ることはプロセスです。

朝、朝食の準備をしながら（CPU) キッチンに来ます(コンピュータ）。 手が2本あります(コア）。 キッチンには色々な機器があります(IO）：オーブン、ケトル、トースター、冷蔵庫。 ガスをつけてフライパンを置き、温まるのを待たずに油を注ぎます（非同期、ノンブロッキング IO 待機）、冷蔵庫から卵を取り出し、皿に割り、片手で溶きます（スレッド#1)、および XNUMX 番目 (スレッド#2) プレート (共有リソース) を保持します。 さて、ケトルのスイッチを入れたいのですが、手が足りません(スレッドの飢餓） この間にフライパンが加熱されます（結果の処理）、そこに泡立てたものを注ぎます。 私はやかんに手を伸ばしてスイッチを入れ、愚かにもその中で水が沸騰するのを眺めました（ブロッキング IO 待機）、ただし、この間にオムレツを泡立てた皿を洗うこともできました。

オムレツを両手だけで作りましたが、それ以上はありませんが、同時に、オムレツを泡立てる瞬間に、オムレツを泡立てる、皿を持つ、フライパンを加熱するという2つの操作が同時に行われます。 CPU はコンピュータの中で最も速い部分であり、IO はほとんどの場合すべてが遅くなる部分であるため、多くの場合効果的な解決策は、IO からデータを受信して​​いる間 CPU を何かで占有することです。

比喩の続き:

• オムレツを作る途中で着替えもしようとすると、これはマルチタスクの一例になります。 重要なニュアンス: コンピュータはこの点では人間よりもはるかに優れています。
• レストランなど、複数のシェフがいるキッチン - マルチコア コンピューター。
• ショッピング センター - データ センターのフード コートにある多くのレストラン

.NETツール

.NET は、他の多くのものと同様、スレッドの操作に優れています。 新しいバージョンが登場するたびに、それらを操作するための新しいツール、OS スレッド上の新しい抽象化レイヤーがどんどん導入されています。 抽象化の構築に取り組むとき、フレームワーク開発者は、高レベルの抽象化を使用するときに XNUMX つ以上下のレベルに進む機会を残すアプローチを使用します。 ほとんどの場合、これは必要ありません。実際、ショットガンで自分の足を撃つ可能性がありますが、まれに、現在の抽象化レベルでは解決できない問題を解決する唯一の方法である場合があります。 。

ツールとは、フレームワークとサードパーティのパッケージによって提供されるアプリケーション プログラミング インターフェイス (API) の両方と、マルチスレッド コードに関連する問題の検索を簡素化するソフトウェア ソリューション全体を意味します。

スレッドを開始する

Thread クラスは、スレッドを操作するための .NET の最も基本的なクラスです。 コンストラクターは、次の XNUMX つのデリゲートのいずれかを受け入れます。

• ThreadStart — パラメータなし
• ParametrizedThreadStart - オブジェクト型のパラメータが XNUMX つあります。

デリゲートは、Start メソッドを呼び出した後、新しく作成されたスレッドで実行されます。ParametrizedThreadStart 型のデリゲートがコンストラクターに渡された場合は、オブジェクトを Start メソッドに渡す必要があります。 このメカニズムは、ローカル情報をストリームに転送するために必要です。 スレッドの作成は高価な操作であり、少なくともスタック上に 1MB のメモリを割り当て、OS API との対話を必要とするため、スレッド自体が重いオブジェクトであることに注意してください。

new Thread(...).Start(...);

ThreadPool クラスは、プールの概念を表します。 .NET では、スレッド プールはエンジニアリングの一部であり、Microsoft の開発者は、スレッド プールがさまざまなシナリオで最適に動作するように多大な努力を払ってきました。

一般的な概念:

アプリケーションが起動した瞬間から、バックグラウンドでいくつかのスレッドが予約され、それらを使用できるようになります。 スレッドが頻繁かつ大量に使用される場合、呼び出し元のニーズを満たすためにプールが拡張されます。 適切なタイミングでプールに空きスレッドがない場合、スレッドの XNUMX つが戻るのを待つか、新しいスレッドを作成します。 したがって、スレッド プールは一部の短期的なアクションには適していますが、アプリケーションの操作全体を通じてサービスとして実行される操作にはあまり適していません。

プールのスレッドを使用するには、ParametrizedThreadStart と同じシグネチャを持つ WaitCallback 型のデリゲートを受け入れる QueueUserWorkItem メソッドがあり、それに渡されるパラメーターは同じ機能を実行します。

ThreadPool.QueueUserWorkItem(...);

あまり知られていないスレッド プール メソッド RegisterWaitForSingleObject は、ノンブロッキング IO 操作を編成するために使用されます。 このメソッドに渡されたデリゲートは、メソッドに渡された WaitHandle が「リリース」されたときに呼び出されます。

ThreadPool.RegisterWaitForSingleObject(...)

.NET にはスレッド タイマーがあり、そのハンドラーがプールから取得されたスレッドで呼び出されるという点で WinForms/WPF タイマーとは異なります。

System.Threading.Timer

プールからスレッドに実行用のデリゲートを送信するかなり変わった方法、BeginInvoke メソッドもあります。

DelegateInstance.BeginInvoke

上記のメソッドの多くを呼び出すことができる関数、つまり Kernel32.dll Win32 API からの CreateThread について簡単に説明したいと思います。 extern メソッドのメカニズムのおかげで、この関数を呼び出す方法があります。 私はこのような呼び出しをレガシー コードのひどい例で一度だけ見たことがありますが、まさにこれを実行した作者の動機はいまだに謎のままです。

Kernel32.dll CreateThread

スレッドの表示とデバッグ

ユーザーが作成したスレッド、すべてのサードパーティ コンポーネント、および .NET プールは、Visual Studio の [スレッド] ウィンドウで表示できます。 このウィンドウには、アプリケーションがデバッグ中でブレーク モードにある場合にのみスレッド情報が表示されます。 ここでは、各スレッドのスタック名と優先順位を簡単に表示し、デバッグを特定のスレッドに切り替えることができます。 Thread クラスの Priority プロパティを使用すると、スレッドの優先順位を設定できます。この優先順位は、スレッド間でプロセッサ時間を分割するときに OC および CLR が推奨事項として認識します。

タスク並列ライブラリ

タスク並列ライブラリ (TPL) は .NET 4.0 で導入されました。 現在、これは非同期を操作するための標準かつ主要なツールです。 古いアプローチを使用するコードはすべてレガシーとみなされます。 TPL の基本単位は、System.Threading.Tasks 名前空間の Task クラスです。 タスクはスレッドを抽象化したものです。 C# 言語の新しいバージョンでは、タスク (async/await 演算子) を洗練された方法で操作できるようになりました。 これらの概念により、あたかも単純な同期であるかのように非同期コードを作成できるようになり、スレッドの内部動作をほとんど理解していない人でも、非同期コードを使用するアプリケーション、つまり長時間の操作を実行してもフリーズしないアプリケーションを作成できるようになりました。 async/await の使用は XNUMX つまたは複数の記事のトピックですが、いくつかの文で要点を理解しようとします。

• async は、Task または void を返すメソッドの修飾子です。
• await はノンブロッキングのタスク待機演算子です。

もう一度言います: await オペレーターは、一般的な場合 (例外があります)、現在の実行スレッドをさらに解放し、タスクが実行を終了すると、スレッド (実際にはコンテキストと言ったほうが正しいでしょう) 、ただし詳細は後ほど) メソッドの実行をさらに続けます。 .NET 内部では、このメカニズムは、書かれたメソッドがステート マシンであるクラス全体になり、これらの状態に応じて個別に実行できる、yield return と同じ方法で実装されます。 興味のある人は誰でも、asynс/await を使用して簡単なコードを作成し、コンパイラー生成コードを有効にして JetBrains dotPeek を使用してアセンブリをコンパイルし、表示することができます。

タスクを起動して使用するためのオプションを見てみましょう。 以下のコード例では、何も役に立たない新しいタスクを作成します (スレッド.スリープ(10000)) ですが、実際には、これは CPU を大量に使用する複雑な作業になるはずです。

using TCO = System.Threading.Tasks.TaskCreationOptions;

public static async void VoidAsyncMethod() {
    var cancellationSource = new CancellationTokenSource();

    await Task.Factory.StartNew(
        // Code of action will be executed on other context
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    //  Code after await will be executed on captured context
}

タスクはいくつかのオプションを使用して作成されます。

• LongRunning は、タスクがすぐには完了しないことを示しています。つまり、プールからスレッドを取得せず、他のタスクに害を及ぼさないように、このタスク用に別のスレッドを作成することを検討する価値がある可能性があります。
• AttachedToParent - タスクを階層的に配置できます。 このオプションが使用された場合、タスクはそれ自体が完了し、子の実行を待っている状態になる可能性があります。
• PreferFairness - 実行のために送信されたタスクを、後で送信されるタスクよりも先に実行する方がよいことを意味します。 ただし、これは単なる推奨であり、結果が保証されるものではありません。

メソッドに渡される XNUMX 番目のパラメーターは CancelToken です。 開始後の操作のキャンセルを正しく処理するには、実行中のコードに cancelsToken 状態のチェックを埋め込む必要があります。 チェックがない場合、CancelTokenSource オブジェクトで呼び出される Cancel メソッドは、タスクの実行を開始前にのみ停止できます。

最後のパラメータは、TaskScheduler タイプのスケジューラ オブジェクトです。 このクラスとその子孫は、スレッド間でタスクを分散するための戦略を制御するように設計されており、デフォルトでは、タスクはプールからのランダムなスレッドで実行されます。

await 演算子は、作成されたタスクに適用されます。つまり、その後に記述されたコード (存在する場合) は、await 前のコードと同じコンテキスト (多くの場合、同じスレッド上を意味します) で実行されます。

このメソッドは async void としてマークされています。これは、await 演算子を使用できますが、呼び出し元のコードは実行を待機できないことを意味します。 このような機能が必要な場合、メソッドは Task を返す必要があります。 async void とマークされたメソッドは非常に一般的です。通常、これらはイベント ハンドラーまたはファイア アンド フォーゲットの原則に基づいて動作するその他のメソッドです。 実行が終了するまで待機する機会を与えるだけでなく、結果を返す必要がある場合は、Task を使用する必要があります。

StartNew メソッドが返したタスクやその他のタスクでは、false パラメーターを指定して ConfigureAwait メソッドを呼び出すことができます。そうすれば、await 後の実行はキャプチャされたコンテキストではなく、任意のコンテキストで続行されます。 これは、await 後のコードにとって実行コンテキストが重要ではない場合に常に実行する必要があります。 これは、ライブラリにパッケージ化されて提供されるコードを作成する場合の MS の推奨事項でもあります。

タスクの完了を待つ方法についてもう少し詳しく見てみましょう。 以下は、期待が条件付きで適切に実行された場合と、条件付きで適切に実行されなかった場合に関するコメントを含むコードの例です。

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // good

    result = AsyncMethod().Result; // bad

    AsyncMethod().Wait(); // bad

    IEnumerable<Task> tasks = new Task[] {
        AsyncMethod(), OtherAsyncMethod()
    };

    await Task.WhenAll(tasks); // good
    await Task.WhenAny(tasks); // good

    Task.WaitAll(tasks.ToArray()); // bad
}

最初の例では、呼び出しスレッドをブロックせずにタスクが完了するのを待ちます。結果がすでに存在する場合にのみ結果の処理に戻ります。それまで、呼び出しスレッドは独自のデバイスに残されます。

XNUMX 番目のオプションでは、メソッドの結果が計算されるまで呼び出しスレッドをブロックします。 これは、プログラムの貴重なリソースであるスレッドを単純なアイドル状態で占有しているためだけでなく、呼び出すメソッドのコードに await が含まれており、同期コンテキストが呼び出し後に呼び出しスレッドに戻る必要がある場合にも問題です。 await, then we will get a Deadlock : 呼び出しスレッドは非同期メソッドの結果が計算されるのを待ちますが、非同期メソッドは呼び出しスレッドで実行を継続しようとしますが無駄です。

このアプローチのもう XNUMX つの欠点は、エラー処理が複雑なことです。 実際、async/await を使用した場合の非同期コードのエラーは非常に簡単に処理でき、コードが同期している場合と同じように動作します。 一方、タスクに同期待機排除を適用すると、元の例外は AggregateException に変わります。 例外を処理するには、InnerException 型を調べて、XNUMX つの catch ブロック内に if チェーンを自分で記述するか、C# の世界でよく知られている catch ブロックのチェーンの代わりに catch when コンストラクトを使用する必要があります。

XNUMX 番目と最後の例も同じ理由で不良とマークされており、すべて同じ問題が含まれています。

WhenAny メソッドと WhenAll メソッドは、タスクのグループを待機する場合に非常に便利です。これらのメソッドは、タスクのグループを XNUMX つにラップし、グループのタスクが最初にトリガーされたとき、またはすべてのタスクの実行が完了したときに起動します。

スレッドの停止

さまざまな理由により、フローが開始された後にフローを停止する必要がある場合があります。 これを行うにはいくつかの方法があります。 Thread クラスには、適切な名前が付けられた XNUMX つのメソッドがあります。 流産 и 割り込み。 最初のものは使用することを強くお勧めしません。 ランダムな瞬間に呼び出した後、命令の処理中に例外がスローされます。 スレッド中止例外。 整数変数をインクリメントするときにそのような例外がスローされるとは予想しませんよね? この方法を使用すると、これが非常に現実的な状況になります。 コードの特定のセクションで CLR がそのような例外を生成しないようにする必要がある場合は、それを呼び出しでラップできます。 Thread.BeginCriticalRegion, Thread.EndCriticalRegion。 Final ブロッ​​クに記述されたコードはすべて、そのような呼び出しでラップされます。 このため、フレームワーク コードの奥深くでは、空の try を持つブロックは見つかりますが、空の Finally は見つかりません。 Microsoft はこの方法を非常に推奨していないため、.net core には含めていません。

Interrupt メソッドはより予測どおりに機能します。 例外によりスレッドを中断する可能性があります スレッド中断例外 スレッドが待機状態にあるときのみ。 WaitHandle、ロックの待機中、または Thread.Sleep の呼び出し後にハングしているときにこの状態になります。

上で説明した両方のオプションは、予測不可能であるため好ましくありません。 解決策は構造を使用することです キャンセルトークン そしてクラス CancelTokenSource。 重要なのは、CancelTokenSource クラスのインスタンスが作成され、そのインスタンスを所有する人だけがメソッドを呼び出して操作を停止できるということです。 キャンセル。 CancelToken のみがオペレーション自体に渡されます。 CancelToken の所有者は自分で操作をキャンセルすることはできませんが、操作がキャンセルされたかどうかを確認することしかできません。 これにはブールプロパティがあります キャンセル要求中です と方法 ThrowIfCancelRequested。 後者は例外をスローします タスクキャンセル例外 オウム返しされている cancelToken インスタンスで Cancel メソッドが呼び出された場合。 そして、これが私が使用することをお勧めする方法です。 これは、例外操作をどの時点で中止できるかを完全に制御できるようになり、以前のオプションを改善したものです。

スレッドを停止するための最も残酷なオプションは、Win32 API TerminateThread 関数を呼び出すことです。 この関数を呼び出した後の CLR の動作は予測できない場合があります。 MSDN では、この関数について次のように書かれています。 「TerminateThread は危険な機能であり、最も極端な場合にのみ使用する必要があります。 「

FromAsync メソッドを使用してレガシー API をタスクベースに変換する

幸運にも、タスクが導入され、ほとんどの開発者に静かな恐怖を引き起こすことがなくなった後に開始されたプロジェクトに取り組むことができた場合は、サードパーティ製の API と自分のチームの API の両方に、多くの古い API を扱う必要がなくなります。過去に拷問を受けている。 幸いなことに、.NET Framework チームは私たちを世話してくれました。おそらく目標は自分たち自身を世話することでした。 それはともかく、.NET には、古い非同期プログラミング アプローチで書かれたコードを新しい非同期プログラミング アプローチに簡単に変換するためのツールが多数あります。 その XNUMX つは、TaskFactory の FromAsync メソッドです。 以下のコード例では、このメソッドを使用して WebRequest クラスの古い非同期メソッドを Task にラップします。

object state = null;
WebRequest wr = WebRequest.CreateHttp("http://github.com");
await Task.Factory.FromAsync(
    wr.BeginGetResponse,
    we.EndGetResponse
);

これは単なる例であり、組み込み型でこれを行う必要はほとんどありませんが、古いプロジェクトには、IAsyncResult を返す BeginDoSomething メソッドとそれを受け取る EndDoSomething メソッドが溢れています。

TaskCompletionSource クラスを使用してレガシー API をタスクベースに変換する

考慮すべきもう XNUMX つの重要なツールはクラスです。 タスク完了ソース。 機能、目的、動作原理の点では、上で書いた ThreadPool クラスの RegisterWaitForSingleObject メソッドを彷彿とさせるかもしれません。 このクラスを使用すると、古い非同期 API をタスクに簡単かつ便利にラップできます。

これらの目的を目的とした TaskFactory クラスの FromAsync メソッドについてはすでに説明したと思われるでしょう。 ここで、Microsoft が過去 15 年間にわたって提供してきた .net での非同期モデルの開発の歴史全体を思い出す必要があります。タスクベースの非同期パターン (TAP) の前には、非同期プログラミング パターン (APP) がありました。メソッドについてでした 始める何かを返す IAsyncResult とメソッド 終わりそれを受け入れる DoSomething と、近年の遺産として、FromAsync メソッドはまさに完璧ですが、時間の経過とともに、イベント ベースの非同期パターンに置き換えられました (EAP)、非同期操作が完了したときにイベントが発生すると想定していました。

TaskCompletionSource は、イベント モデルを中心に構築されたタスクとレガシー API をラップするのに最適です。 その動作の本質は次のとおりです。このクラスのオブジェクトには Task 型のパブリック プロパティがあり、その状態は TaskCompletionSource クラスの SetResult、SetException などのメソッドを通じて制御できます。 await オペレーターがこのタスクに適用された場所では、TaskCompletionSource に適用されたメソッドに応じて、タスクが実行されるか、例外が発生して失敗します。 まだ明確でない場合は、このコード例を見てみましょう。ここでは、古い EAP API が TaskCompletionSource を使用してタスクにラップされています。イベントが発生すると、タスクは Completed 状態に転送され、await オペレーターを適用したメソッドが示されます。このタスクはオブジェクトを受信すると実行を再開します 結果.

public static Task<Result> DoAsync(this SomeApiInstance someApiObj) {

    var completionSource = new TaskCompletionSource<Result>();
    someApiObj.Done += 
        result => completionSource.SetResult(result);
    someApiObj.Do();

    result completionSource.Task;
}

TaskCompletionSource のヒントとコツ

TaskCompletionSource を使用して実行できるのは、古い API をラップすることだけではありません。 このクラスを使用すると、スレッドを占有しないタスクでさまざまな API を設計できる興味深い可能性が開かれます。 そして、私たちが覚えているように、ストリームは高価なリソースであり、その数は（主に RAM の量によって）制限されています。 この制限は、たとえば、複雑なビジネス ロジックを備えたロードされた Web アプリケーションを開発することで簡単に達成できます。 ロングポーリングのようなトリックを実装する場合に私が話している可能性について考えてみましょう。

つまり、このトリックの本質は次のとおりです。API 側で発生するいくつかのイベントに関する情報を API から受け取る必要がありますが、API は何らかの理由でイベントを報告できず、状態を返すことしかできません。 これらの例としては、WebSocket の時代以前、または何らかの理由でこのテクノロジを使用できなかった時代に、HTTP 上に構築されたすべての API があります。 クライアントは HTTP サーバーに問い合わせることができます。 HTTP サーバー自体はクライアントとの通信を開始できません。 簡単な解決策は、タイマーを使用してサーバーをポーリングすることですが、これによりサーバーに追加の負荷が発生し、平均 TimerInterval / 2 で追加の遅延が発生します。これを回避するために、ロング ポーリングと呼ばれるトリックが発明されました。タイムアウトが経過するかイベントが発生するまでサーバーは停止しません。 イベントが発生した場合は処理され、発生していない場合はリクエストが再度送信されます。

while(!eventOccures && !timeoutExceeded)  {

  CheckTimout();
  CheckEvent();
  Thread.Sleep(1);
}

しかし、そのようなソリューションは、イベントを待っているクライアントの数が増えるとすぐにひどいものになることがわかります。 このような各クライアントは、イベントを待機するスレッド全体を占有します。 はい、イベントがトリガーされるとさらに 1ms の遅延が発生します。ほとんどの場合、これは重大ではありませんが、ソフトウェアを必要以上に悪化させるのはなぜでしょうか? Thread.Sleep(1) を削除すると、100 つのプロセッサ コアが XNUMX% アイドル状態でロードされ、無駄なサイクルで回転することになります。 TaskCompletionSource を使用すると、このコードを簡単に作り直し、上記で特定されたすべての問題を解決できます。

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource<Msg>> tasks;

    public async Task<Msg> AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource<Msg>();
        tasks[userId] = cs;
        await Task.WhenAny(Task.Delay(duration), cs.Task);
        return cs.Task.IsCompleted ? cs.Task.Result : null;
    }

    public void SendMessage(int userId, Msg m) {

        if (tasks.TryGetValue(userId, out var completionSource))
            completionSource.SetResult(m);
    }
}

このコードは本番環境に対応したものではなく、単なるデモです。 実際のケースで使用するには、少なくとも、誰も予期していない時間にメッセージが到着したときの状況に対処する必要もあります。この場合、AsseptMessageAsync メソッドはすでに完了したタスクを返す必要があります。 これが最も一般的なケースである場合は、ValueTask の使用を検討できます。

メッセージのリクエストを受信すると、TaskCompletionSource を作成してディクショナリに配置し、最初に何が起こるか、つまり指定された時間が経過するか、メッセージが受信されるかを待ちます。

ValueTask: その理由と方法

async/await 演算子は、yield return 演算子と同様に、メソッドからステート マシンを生成します。これは新しいオブジェクトの作成であり、ほとんどの場合重要ではありませんが、まれに問題が発生する可能性があります。 このケースは非常に頻繁に呼び出されるメソッドである可能性があり、XNUMX 秒あたり数万、数十万の呼び出しが行われることになります。 ほとんどの場合、すべての await メソッドをバイパスして結果を返すようなメソッドが記述されている場合、.NET はこれを最適化するツールである ValueTask 構造を提供します。 それを明確にするために、その使用例を見てみましょう。非常に頻繁にアクセスするキャッシュがあります。 いくつかの値が含まれている場合は、それらを返すだけですが、そうでない場合は、低速 IO を実行して値を取得します。 後者を非同期で実行したいのですが、これはメソッド全体が非同期になることを意味します。 したがって、メソッドを記述する明白な方法は次のようになります。

public async Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return val;
    return await RequestById(id);
}

少し最適化したいという要望と、このコードのコンパイル時に Roslyn が何を生成するかという若干の懸念があるため、この例を次のように書き換えることができます。

public Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return Task.FromResult(val);
    return RequestById(id);
}

実際、この場合の最適な解決策は、ホットパスを最適化すること、つまり、不必要な割り当てや GC への負荷を与えずにディクショナリから値を取得することですが、それでもデータを取得するために IO にアクセスする必要があるまれなケースでは、 、すべてが古い方法のままプラス/マイナスのままになります。

public ValueTask<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return new ValueTask<string>(val);
    return new ValueTask<string>(RequestById(id));
}

このコード部分を詳しく見てみましょう。キャッシュに値がある場合は構造体を作成します。それ以外の場合、実際のタスクは意味のあるタスクでラップされます。 呼び出し元のコードは、このコードがどのパスで実行されたかは関係ありません。C# 構文の観点から見ると、この場合、ValueTask は通常の Task と同じように動作します。

TaskScheduler: タスク起動戦略の管理

次に検討したい API はクラスです。 タスクスケジューラ およびその派生品。 TPL にはスレッド間でタスクを分散するための戦略を管理する機能があることはすでに上で述べました。 このような戦略は、TaskScheduler クラスの子孫で定義されます。 必要な戦略はほとんどすべてライブラリで見つけることができます。 ParallelExtensionsExtras、Microsoft によって開発されましたが、.NET の一部ではなく、Nuget パッケージとして提供されます。 それらのいくつかを簡単に見てみましょう。

• 現在のスレッドタスクスケジューラ — 現在のスレッドでタスクを実行します
• LimitedConcurrencyLevelTask​​Scheduler — コンストラクターで受け入れられるパラメーター N によって同時に実行されるタスクの数を制限します。
• OrderedTaskScheduler — LimitedConcurrencyLevelTask​​Scheduler(1) として定義されているため、タスクは順番に実行されます。
• 仕事盗むタスクスケジューラ - 実装します 仕事を盗む タスク分散へのアプローチ。 基本的に、これは別個の ThreadPool です。 .NET では ThreadPool がすべてのアプリケーションに対応する静的クラスであるという問題を解決します。つまり、プログラムの一部でそのオーバーロードや誤った使用が別の部分で副作用を引き起こす可能性があります。 さらに、このような欠陥の原因を理解することは非常に困難です。 それ。 ThreadPool の使用が積極的で予測不可能なプログラムの一部では、別個の WorkStealingTaskScheduler を使用する必要がある場合があります。
• キューに登録されたタスクスケジューラ — 優先キューのルールに従ってタスクを実行できます。
• タスクごとのスレッドスケジューラ — 実行されるタスクごとに個別のスレッドを作成します。 完了までに予想外に長い時間がかかるタスクに役立ちます。

良い詳細があります 記事 Microsoft ブログの TaskScheduler について。

タスクに関連するあらゆるものを簡単にデバッグできるように、Visual Studio にはタスク ウィンドウがあります。 このウィンドウでは、タスクの現在の状態を確認し、現在実行中のコード行にジャンプできます。

PLinq と Parallel クラス

タスクとそれについて述べたすべてに加えて、.NET にはさらに 2 つの興味深いツールがあります。PLinq (LinqXNUMXParallel) と Parallel クラスです。 XNUMX つ目は、すべての Linq 操作を複数のスレッドで並列実行することを約束します。 スレッドの数は、WithDegreeOfParallelism 拡張メソッドを使用して構成できます。 残念ながら、ほとんどの場合、デフォルト モードの PLinq には、速度を大幅に向上させるほどのデータ ソースの内部に関する十分な情報がありません。その一方で、試行コストは非常に低くなります。事前に AsParallel メソッドを呼び出すだけで十分です。 Linq メソッドのチェーンを確認し、パフォーマンス テストを実行します。 さらに、パーティション メカニズムを使用して、データ ソースの性質に関する追加情報を PLinq に渡すことができます。 もっと読むことができます ここで и ここで.

Parallel 静的クラスは、Foreach コレクションを並列で反復処理し、For ループを実行し、複数のデリゲートを並列 Invoke 実行するためのメソッドを提供します。 現在のスレッドの実行は、計算が完了するまで停止されます。 スレッドの数は、最後の引数として ParallelOptions を渡すことによって構成できます。 オプションを使用して TaskScheduler と CancelToken を指定することもできます。

所見

レポートの資料とその後の仕事中に収集した情報に基づいてこの記事を書き始めたとき、これほど多くの情報があるとは予想していませんでした。 さて、この記事を入力しているテキスト エディタが 15 ページが終わったと非難しそうに告げてきたら、中間結果を要約します。 他のトリック、API、ビジュアル ツール、落とし穴については、次の記事で説明します。

結論：

• 最新の PC のリソースを使用するには、スレッド、非同期、並列処理を操作するためのツールを知る必要があります。
• .NET にはこれらの目的のためのさまざまなツールが多数あります
• すべてが一度に登場したわけではないため、古い API が見つかることもよくありますが、手間をかけずに古い API を変換する方法があります。
• .NET でのスレッドの操作は、Thread クラスと ThreadPool クラスによって表されます。
• Thread.Abort、Thread.Interrupt、および Win32 API の TerminateThread メソッドは危険であるため、使用はお勧めできません。 代わりに、CancelToken メカニズムを使用することをお勧めします。
• 流れは貴重な資源であり、その供給には限りがあります。 スレッドがイベントの待機でビジー状態になる状況は避けてください。 このためには、TaskCompletionSource クラスを使用すると便利です。
• 並列処理と非同期処理を行うための最も強力かつ高度な .NET ツールは、タスクです。
• C# の async/await 演算子は、ノンブロッキング待機の概念を実装します。
• TaskScheduler 派生クラスを使用して、スレッド間でのタスクの分散を制御できます。
• ValueTask 構造は、ホット パスとメモリ トラフィックの最適化に役立ちます。
• Visual Studio の [タスク] ウィンドウと [スレッド] ウィンドウには、マルチスレッド コードまたは非同期コードのデバッグに役立つ多くの情報が提供されます。
• PLinq は優れたツールですが、データ ソースに関する十分な情報が含まれていない可能性がありますが、これはパーティショニング メカニズムを使用して修正できます。
• 継続するには...

出所： habr.com