0

タスクスケジューラとは、設計されているアルゴリズムに従ってスレッドに作業を分散するワーカースレッドプールの実装を意味します。（Intel TBBのように）

「リアルタイム」の制約は、作業が予測可能な時間で行われることを意味することを私は知っています（私は速度について話していません）。したがって、私の推測では、タスクスケジューラを使用すると、特定の時間より前に一部のタスクが実行されることを保証できず、アプリケーションをこれらの制約で使用できなくなります。

それとも私は何かが足りないのですか？両方を持つ方法はありますか？たぶん、処理できるデータの量に仮定を強制することによって？または、予測可能なタスクスケジューラがありますか？

私は、（ビデオゲームのような）ソフトリアルタイムではなく、「ハード」リアルタイム制約について話している。

明確にするために：

C ++には、この種のコンテキストでは使用できない機能（new、delete、throw、dynamic_cast）があることが知られています。それらは予測できません（これらの操作の1つにどれだけの時間を費やすことができるかはわかりません。実行前にさえ知られていないパラメーターが多すぎることに依存します）。リアルタイムのコンテキストで実際に使用することはできません。私が尋ねるのは、タスクスケジューラには、リアルタイムアプリケーションで使用できなくなるのと同じ予測不可能性があるのでしょうか。

4

3 に答える 3

3

リアルタイムという用語は非常に柔軟です。「ハード リアルタイム」とは、数十マイクロ秒で「正しく動作する」か「正しく動作しない」かの違いを意味する傾向があります。すべての「リアルタイム」システムがそのようなリアルタイム性を必要とするわけではありません。

私はかつて、携帯電話用の無線基地局で働いていました。ボード上のデバイスの 1 つに、約 2 ミリ秒ごとに発生する割り込みがありました。正しい操作 (呼び出しを失わない) のために、割り込みを処理する必要がありました。つまり、割り込み内で作業を行い、ハードウェア レジスタに新しい値を 100 マイクロ秒以内に書き込む必要がありました。160 マイクロ秒後に割り込みが行われなかった場合、システムは再起動します。これは、特にプロセッサが数十 MHz で実行されていたため、「ハード リアルタイム」です。

ビデオ プレーヤーを作成する場合、数ミリ秒単位のリアルタイムが必要です。

「表示株価」は、おそらく 100 ミリ秒の範囲内になる可能性があります。

Web サーバーの場合、大きな問題なく 1 ～ 2 秒以内に応答することはおそらく許容されます。

また、「X よりも悪い場合は失敗を意味する」という違いがあります (上記の 100 マイクロ秒または切断された通話の場合のように、数週間に 1 回以上発生する場合は悪いことです。年に数回でも、実際には問題があります)修正する必要があります)。これを「ハードリアルタイム」と呼びます。

しかし、他のシステムでは、締め切りに間に合わないということは、「ああ、もう一度やり直さなければならない」または「ビデオのフレームが少しちらついた」ことを意味します。これを「ソフトリアルタイム」と呼びます。

最新のハードウェアの多くは、「ハード リアルタイム」(10 秒または 100 マイクロ秒の範囲) を困難にします。これは、グラフィックス プロセッサがプロセッサのメモリへのアクセスを単純に停止するか、プロセッサが熱くなるとstopclkピンが 100 マイクロ秒引き抜かれるからです。 ...

Linux や Windows などの最新の OS のほとんどは、実際には「ハード リアルタイム」であることを意図していません。これらの OS の一部には、100 マイクロ秒を超える割り込みを無効にするコードのセクションがあります。

最新のハードウェアを備えた主流の最新の OS から、優れた "ソフト リアルタイム" (つまり、締め切りに間に合わなくても、失敗ではなく、わずかな煩わしさに過ぎない) をほぼ確実に得ることができます。システムをハード リアルタイムにするには、おそらく OS の変更または専用のリアルタイム OS (およびおそらく適切な特殊なハードウェア) のいずれかが必要になるでしょう。

しかし、そのようなハード リアルタイムを必要とするものは世界でもほんのわずかです。多くの場合、ハード リアルタイムの要件はハードウェアによって処理されます。たとえば、上記で説明した次世代の無線基地局は、より賢いハードウェアを備えていたため、次の 2 時間以内に新しい値を与える必要がありました。数ミリ秒で完了し、「数十マイクロ秒で完了するための狂ったラッシュ」はありませんでした。最新の携帯電話では、GSM または UMTS プロトコルは主に専用の DSP (デジタル シグナル プロセッサ) によって処理されます。

「ハード リアルタイム」要件とは、特定の期限 (または一連の期限) を守れない場合、たとえ期限を守れなかったことが 1 回だけであっても、システムが実際に機能していない場合です。ただし、システムが異なれば、締め切りが迫っている実際の時間に対するシステムの感度も異なります (Jerry Coffin が言及しているように)。ハードリアルタイムシステムのリアルタイム要件を処理する上で、市販の汎用 OS が完全に適切であるケースを見つけることはほぼ確実に可能です。また、特殊なシステムがなければ、このような厳しいリアルタイム要件を満たすことができないケースが他にもあることは間違いありません。

OS からミリ秒未満の保証が必要な場合は、デスクトップ Windows や Linux は適していません。これは実際には、OS とスケジューラの設計の全体的な哲学にかかっており、ハード リアルタイム OS を構築するには、ロックや、あるスレッドが別のスレッドをブロックしたり、実行をブロックしたりする可能性などについて、多くのことを考慮する必要があります。

あなたの質問に当てはまる答えは1つではないと思います。はい、確かに、厳しいリアルタイム要件を持つシステムでスレッドプールを使用できます。OSでこれに対する特定のサポートがない限り、おそらくミリ秒未満で実行することはできません。また、スレッドプール自体の一部ではない、最も優先度の高いリアルタイム動作を処理するために、専用のスレッドとプロセスが必要になる場合があります。

これがあなたの答えに「はい」または「いいえ」と言っていない場合は申し訳ありませんが、OSの実際の動作を調査し、それがどのような保証を提供できるかを確認する必要があると思います（最悪の場合）。また、最悪のシナリオとは何かを決定する必要があります。また、締め切りに間に合わなかった場合に何が起こるかを決定する必要があります。(多くの) 人が死んでいる (飛行機が空から落ちてくる) か、何百万ドルもの損失を被る銀行員がいる場合は、緑色です。交差点で 2 方向のライトが同時に点灯しますか、それともスピーカーから悪い音がしますか?

于 2013-03-11T20:32:14.613 に答える
3

はい、できますが、簡単ではありません。また、制限があります。

スケジューラーを記述して、(たとえば) 割り込みハンドラー、例外ハンドラー (など) が発生してから一定時間経過することなく呼び出されることが保証されるようにすることができます。特定のスレッドが、(たとえば) 特定の秒 (または適切な秒の端数) から少なくとも X ミリ秒の CPU 時間を取得することを保証できます。

後者を強制するには、通常、アドミタンス基準が必要です。つまり、スケジューラーが「申し訳ありませんが、CPU の負荷がすでに高すぎるため、これをリアルタイム スレッドとしてスケジュールできません。

それ以外の場合は、CPU 時間の少なくとも (たとえば) 99% がリアルタイム タスク (存在する場合) に割り当てられることを保証するだけであり、その上でシステムを設計する人は、十分な数の実際のタスクをスケジュールする必要があります。 -これにより、すべてのタスクが十分に迅速に終了することが保証されます。

リアルタイム要件の「厳しさ」は、必要な応答速度とほぼ完全に直交していることを付け加えておきます。むしろ、それはほとんど完全に、遅刻の結果の深刻さに関するものです.

たとえば、原子力発電所を考えてみましょう。多くの場合、数分、場合によっては数時間の期間を扱っています。特定のチャンバーを、たとえば 50 万ガロンの水で満たすことは、マイクロ秒やミリ秒では実現しません。

同時に、後の回答の結果は非常に大きくなる可能性があります。病院の設備のように少数の死者を出すだけでなく、数百または数千の死者、数億の損害などを引き起こす可能性があります。ほとんどの典型的な基準では締め切りが異常に「緩い」にもかかわらず、リアルタイムの要件が得られるのと同じくらい「難しい」.

反対に、デジタル オーディオの再生には、はるかに厳しい制限があります。遅延やドロップアウトは、場合によっては数ミリ秒までかなり聞こえることがあります。同時に、大規模なコンサート (またはその程度の何か) にサウンド処理を提供していない限り、ドロップアウトの結果は通常、ユーザー側のちょっとした煩わしさです。

もちろん、この 2 つを組み合わせることも可能です。明らかな例として、高頻度の取引では、締め切りがマイクロ秒 (またはそれくらい) のオーダーになる可能性があり、締め切りに間に合わなかった場合の損失は簡単に数百万または数千になる可能性があります。数百万 (ドル|ユーロ|ポンド|など)

于 2013-03-11T21:10:31.633 に答える
0

「リアルタイム」とは、単に「速い」という意味ではなく、システムが現実の世界で締め切りに間に合うように対応できることを意味します。これらの期限は、現実の世界で何を扱っているかによって異なります。

タスクが特定の時間枠内に終了するかどうかは、スケジューラではなくタスクの特性です。スケジューラーは、どのタスクがリソースを取得するかを決定する場合があり、タスクが期限までに終了しない場合は、他のタスクが期限に間に合うように、タスクが停止されるか、リソースの使用が制限される場合があります。

ですから、質問に対する答えは、ワークロード、締め切り、およびスケジューラを一緒に検討し、要件を満たすようにシステムを構築する必要があるということです。任意のタスクを予測可能な時間内に完了させる魔法のスケジューラはありません。

アップデート：

タスク スケジューラは、必要な保証があれば、リアルタイム システムで使用できます。他の人が言ったように、それらの保証を提供するタスク スケジューラがあります。

コメントについて: 問題は、所要時間の上限です。

new と delete をオーバーロードして目的のパフォーマンス特性を実現する場合は、それらを使用できます。問題は新規および削除ではなく、動的メモリ割り当てです。new と delete が汎用の動的アロケーターを使用する必要はありません。これらを使用して、確定的な動作でワークロードに適したサイズの静的に割り当てられたプールから割り当てることができます。

dynamic_cast について: 私は使用しない傾向にありますが、リアルタイム コードで禁止する必要があるほどパフォーマンスが非決定論的であるとは思いません。これは同じ問題の例です。最悪の場合のパフォーマンスを理解することが重要です。

于 2013-03-12T01:09:43.707 に答える