RHEL for Real Time の理解

リアルタイムプロセッサーコアは、物理的な中央処理装置 (CPU) であり、マシンコードを実行します。ソケットは、プロセッサーとコンピューターのマザーボードとの間の接続です。ソケットは、プロセッサーが配置されるマザーボードの場所です。プロセッサーには次の 2 つのセットがあります。

リアルタイム環境を設計するときは、使用可能なコアの数、コア間のキャッシュレイアウト、およびコアが物理的に接続されている方法に注意してください。

複数のコアが利用可能な場合は、スレッドまたはプロセスを使用します。これらの構造を使用せずに作成されたプログラムは、一度に 1 つのプロセッサーで実行されます。マルチコアプラットフォームは、さまざまなタイプの操作にさまざまなコアを使用することで利点を提供します。

tuna コマンドラインツール (CLI) を使用すると、キャッシュレイアウトを決定し、相互作用するスレッドをコアにバインドして、キャッシュを共有することができます。キャッシュ共有は、相互除外プリミティブ (mutex、条件変数、または同様の) とデータ構造が同じキャッシュを使用するようにすることで、メモリー障害を軽減します。

多くのハードウェアベンダーは、非汎用メモリーアクセス (NUMA) アーキテクチャーとして知られるコアとメモリー間の相互接続の透過的なネットワークを提供するようになりました。

NUMA は、マルチプロセッシングで使用されるシステムメモリー設計であり、メモリーアクセス時間はプロセッサーに対するメモリーの場所によって異なります。NUMA を使用すると、プロセッサーは、別のプロセッサー上のメモリーやプロセッサー間で共有されているメモリーなど、非ローカルメモリーよりも高速に自身のローカルメモリーにアクセスできます。NUMA システムでは、相互接続トポロジーを理解すると、隣接するコアで頻繁に通信するスレッドを配置するのに役立ちます。

taskset ユーティリティーおよび numactl ユーティリティーは、CPU トポロジーを決定します。taskset は、メモリーノードなどの NUMA リソースなしで CPU アフィニティーを定義し、numactl はプロセスと共有メモリーの NUMA ポリシーを制御します。

デマンドページングは、ページスワッピングを備えたページングシステムに似ています。システムは、必要に応じて、または CPU の要求に応じて、セカンダリーメモリーに保存されているページをロードします。プログラムによって生成されたすべてのメモリーアドレスは、プロセッサーのアドレス変換メカニズムを通過します。次に、アドレスはプロセス固有の仮想アドレスから物理メモリーアドレスに変換されます。これは仮想メモリーと呼ばれます。翻訳メカニズムの 2 つの主要コンポーネントは、ページテーブルと翻訳ルックアップバッファー (TLB) です。

物理アドレスが割り当てられたページテーブルエントリーは、常駐ワーキングセットと呼ばれます。オペレーティングシステムが他のプロセスのためにメモリーを解放する必要がある場合、オペレーティングシステムは常駐ワーキングセットからページを交換できます。ページを交換する場合、そのページ内の仮想アドレスへの参照はページフォールトを作成し、ページの再割り当てを引き起こします。

システムの物理メモリーが極端に少なくなると、スワッププロセスがスラッシュを開始します。これにより、プロセスからページが絶えず盗まれ、プロセスの完了が許可されなくなります。/proc/vmstat ファイルで pgfault 値を探すことにより、仮想メモリーの統計を監視できます。

TLB は、参照の局所性の原則に基づいて動作します。つまり、コードが (ループやコール関連の関数など) 長い期間メモリー領域内に留まる場合、TLB 参照はアドレス変換のメインメモリーを回避します。これにより、処理時間が大幅に短縮されます。

決定論的および高速コードを記述する場合は、参照のローカリティーを維持する関数を使用します。これは、再帰ではなくループを使用することを意味します。再帰が避けられない場合は、関数の最後に再帰呼び出しを配置します。これは tail-recursion と呼ばれ、これは比較的小さいメモリー領域でコードが機能し、メインメモリーからのテーブル変換の呼び出しを回避します。

RHEL for Real Time は、物理メモリーをページと呼ばれるチャンクに分割してメモリーを割り当て、それらを仮想メモリーにマップします。リアルタイムで障害が発生するのは、マップされていないか、メモリーで使用できなくなった特定のページをプロセスが必要とする場合です。したがって、障害は基本的に、CPU が必要とするときにページが使用できないことを意味します。プロセスでページフォールトが発生すると、カーネルがこのフォールトを処理するまで、すべてのスレッドがフリーズします。この問題に対処する方法はいくつかありますが、最善の解決策は、ページフォールトを回避するためにソースコードを調整することです。

リアルタイムでアプリケーションでパフォーマンスの低下が見られる場合は、/proc/ ディレクトリーでページ障害に関連するプロセス情報を確認すると便利です。特定のプロセス ID (PID) は、cat コマンドを使用して、次の関連エントリーの /proc/PID/stat ファイルを表示できます。

次の例は、cat コマンドおよび pipe 関数を使用してページ障害を表示し、/proc/PID/stat ファイルの 2 行目、10 行目、および 12 行目のみを返す方法を示しています。

cat /proc/3366/stat | cut -d\ -f2,10,12
  (bash) 5389 0

# cat /proc/3366/stat | cut -d\ -f2,10,12
  (bash) 5389 0

出力例では、PID 3366 のプロセスは bash であり、5389 のマイナーページフォールトがあり、主なページ障害はありません。

メモリーロック (mlock()) システムコールを使用すると、呼び出しプロセスがアドレス空間の指定された範囲をロックまたはロック解除できるようになり、Linux がロックされたメモリーをスワップ空間にページングするのを防ぐことができます。物理ページをページテーブルエントリーに割り当てると、そのページへの参照は比較的高速になります。メモリーロックシステムコールは、mlock() および munlock() カテゴリーに分類されます。

mlock および munlock システムコールは、特定の範囲のプロセスアドレスページをロックおよびロック解除します。成功すると、指定された範囲内のページは、munlock() システムコールがページのロックを解除するまで、メモリーに常駐したままになります。

mlock() および munlock() システムコールは、次のパラメーターを取ります。

成功すると、mlock() および munlock() システムコールは 0 を返します。エラーの場合は、-1 を返し、エラーを示す errno を設定します。

mlockall() および munlockall() システムコールは、すべてのプログラム空間をロックまたはロック解除します。

メモリーロックはページベースで行われ、スタックしません。動的に割り当てられた 2 つのメモリーセグメントが、mlock() または mlockall() によって 2 回ロックされた同じページを共有している場合、1 つの munlock() または munlockall() システムコールを使用してロックを解除します。そのため、二重ロックまたは単一ロック解除の問題を回避するために、アプリケーションがロック解除するページに注意することが重要です。

以下は、二重ロックまたは単一ロック解除の問題を軽減するための最も一般的な 2 つの回避策です。

RHEL for Real Time の共有ライブラリーは、動的共有オブジェクト (DSO) と呼ばれ、関数と呼ばれるコンパイル済みのコードブロックのコレクションです。これらの関数は複数のプログラムで再利用可能であり、実行時またはコンパイル時にロードされます。

Linux は、次の 2 つのライブラリークラスをサポートしています。

ld.so ダイナミックリンカーは、プログラムに必要な共有ライブラリーをロードしてから、コードを実行します。DSO 関数は、ライブラリーをメモリーに 1 回ロードすると、複数のプロセスがプロセスのアドレス空間にマッピングすることでオブジェクトを参照できます。LD_BIND_NOW 変数を使用して、コンパイル時にロードするようにダイナミックライブラリーを設定できます。

プログラムの初期化の前にシンボルを評価すると、パフォーマンスが向上する可能性があります。これは、アプリケーションの実行時に評価すると、メモリーページが外部ディスクにある場合に遅延が発生する可能性があるためです。

RHEL for Real Time では、共有メモリーは複数のプロセス間で共有されるメモリー空間です。プログラムスレッドを使用すると、1 つのプロセスコンテキストで作成されたすべてのスレッドが同じアドレス空間を共有できます。これにより、すべてのデータ構造にスレッドがアクセスできるようになります。POSIX 共有メモリー呼び出しを使用すると、アドレス空間の一部を共有するようにプロセスを設定できます。

以下のサポートされている POSIX 共有メモリー呼び出しを使用できます。

リアルタイムでは、レベル信号割り込みは、電圧遷移を提供する専用の割り込みラインを使用します。デバイスコントローラーは、割り込み要求ラインで信号をアサートすることによって割り込みを発生させます。割り込みラインは、バイナリー 1 またはバイナリー 0 を表す 2 つの電圧のいずれかを送信します。

割り込み信号が回線から送信されると、CPU がリセットするまでその状態のままになります。CPU は状態保存を実行し、割り込みをキャプチャーして、割り込みハンドラーをディスパッチします。割り込みハンドラーは、割り込みの原因を特定し、必要なサービスを実行して割り込みをクリアし、デバイスの状態を復元します。レベル信号による割り込みは、実装は複雑ですが、信頼性が高く、複数のデバイスをサポートします。

リアルタイムでは、多くのシステムがメッセージシグナル割込み (MSI) を使用します。これは、パケットまたはメッセージベースの電気バスに専用のメッセージとして信号を送信します。このタイプのバスの一般的な例として、Peripheral Component Interconnect Express (PCI Express または PCIe) があります。これらのデバイスは、PCIe ホストコントローラーが割り込みメッセージとして解釈するメッセージタイプを送信します。ホストコントローラーはメッセージを CPU に送信します。

リアルタイムでは、ハードウェアに応じて、PCIe システムは次のいずれかを実行します。

リアルタイムでは、PCIe システムはレガシーモードで動作することもできます。レガシーモードでは、レガシー割り込み行は、古いオペレーティングシステムをサポートするために実装されます。または、カーネルコマンドライン上のオプション pci=nomsi を使用して Linux カーネルを起動することもできます。

リアルタイムでは、マスク不可割り込みは、システムの標準的な割り込みマスキング技術が無視できないハードウェア割り込みです。NMI は、マスク可能な割り込みより優先度が高くなります。NMI は、回復不可能なハードウェアエラーの注意を促すために発生します。

リアルタイムでは、NMI は、一部のシステムでハードウェアモニターとしても使用されます。プロセッサーが NMI を受信すると、割り込みベクターが指す NMI ハンドラーを呼び出すことにより、NMI を即座に処理します。指定された時間後に割り込みがトリガーされないなど、特定の条件を満たす場合、NMI ハンドラーは問題に関する警告やデバッグの情報を生成する可能性があります。これは、システムのロックアップを特定し、回避するのに役立ちます。

リアルタイムでは、マスク可能な割り込みは、割り込みマスクレジスターのビットマスクにビットを設定することで無視できるハードウェア割り込みです。CPU は、重要な処理中にマスク可能な割り込みを一時的に無視できます。

リアルタイムでは、システム管理割り込み (SMI) は、レガシーハードウェアデバイスエミュレーションなどの拡張機能を提供し、システム管理タスクにも使用できます。SMI は、特殊な電気信号線を使用し、通常はマスクできないという点で、マスク不可割り込み (NMI) に似ています。SMI が発生すると、CPU はシステム管理モード (SMM) に入ります。このモードでは、SMI を処理するために特別な低レベルハンドラーが実行されます。通常、SMM はシステム管理ファームウェアから直接提供されます。通常は BIOS または EFI です。

リアルタイムの SMI は、レガシーのハードウェアエミュレーションを提供するために最もよく使用されます。一般的な例は、ディスケットドライブを模倣することです。ディスケットドライブが接続されていない場合、オペレーティングシステムはディスケットへのアクセスを試み、SMI をトリガーします。このシナリオでは、ハンドラーが代わりにエミュレートされたデバイスをオペレーティングシステムに提供します。次に、オペレーティングシステムは、エミュレーションをレガシーデバイスとして扱います。

リアルタイムでは、SMI は、オペレーティングシステムが直接関与することなく実行されるため、システムに悪影響を与える可能性があります。不適切に記述された SMI 処理ルーチンは、数ミリ秒の CPU 時間を消費する可能性があり、オペレーティングシステムがハンドラーをプリエンプションできない可能性があります。これにより、他の点では適切に調整された応答性の高いシステムで、定期的に大きな遅延が発生する可能性があります。ベンダーは SMI ハンドラーを使用して CPU 温度およびファン制御を管理する場合があるため、それらを無効にできない場合があります。このような状況では、これらの割り込みを使用するときに発生する問題をベンダーに通知する必要があります。

リアルタイムでは、hwlatdetect ユーティリティーを使用して SMI を分離できます。rt-tests パッケージで入手できます。このユーティリティーは、CPU が SMI 処理ルーチンによって使用されている期間を測定します。

Intel Corporation によって開発された高度なプログラム可能な割り込みコントローラー (APIC) は、次の機能を提供します。

リアルタイムの APIC は、一連のデバイスとテクノロジーを表し、スケーラブルかつ管理可能な方法で多数のハードウェア割り込みを生成し、ルーティングして、処理します。これは、各システム CPU に組み込まれたローカルの APIC と、ハードウェアデバイスに直接接続されている入出力 APIC の組み合わせを使用します。

リアルタイムで、ハードウェアデバイスが割り込みを生成すると、接続された I/O APIC が割り込みを検出し、システム APIC バスを介して特定の CPU にルーティングします。オペレーティングシステムは、IO-APIC がデバイスに接続されていることを認識し、そのデバイス内の回線に割り込みます。Advanced Configuration and Power Interface Differentiated System description Table (ACPI DSDT) には、ホストシステムのマザーボードと周辺コンポーネントの特定の接続に関する情報が含まれて、デバイスは利用可能な割り込みソースに関する情報を提供します。これら 2 つのデータを組み合わせて割り込み階層全体に関する情報を提供します。

RHEL for Real Time は、階層で接続されたシステム APIC を使用し、特定の CPU や CPU をターゲットにするのではなく、負荷分散された方法で CPU に割り込みを提供することで、複雑な APIC ベースの割り込み管理ストラテジーをサポートします。

リアルタイムのプロセスは、簡単に言えば、実行中のプログラムです。プロセスという用語は、複数のスレッドを含む可能性のある独立したアドレス空間を指します。あるアドレス空間内で実行中の 1 つ以上のプロセスの概念が開発されると、Linux は別のプロセスでアドレス空間を共有するプロセス構造に移行していました。これは、プロセスデータ構造が小さいと機能します。

UNIX® スタイルのプロセス設定には、次のものが含まれます。

リアルタイムでは、各プロセスは、親スレッドと呼ばれることが多い単一のスレッドで始まります。fork() システムコールを使用して、親スレッドから追加のスレッドを作成できます。fork() は、新しいプロセス ID を除いて、親プロセスと同じ新しい子プロセスを作成します。子プロセスは、作成プロセスとは独立して実行します。親プロセスおよび子プロセスは同時に実行できます。fork() と exec() のシステムコールの違いは、fork() が親プロセスのコピーである新しいプロセスを開始し、exec() が現在のプロセスイメージを新しいプロセスイメージに置き換えることです。

リアルタイムでは、fork() システムコールが成功すると、子プロセスのプロセス ID が返され、親プロセスはゼロ以外の値を返します。エラーの場合は、エラー番号を返します。

リアルタイムでは、プロセス内に複数のスレッドが存在する可能性があります。プロセスのすべてのスレッドは、その仮想アドレス空間およびシステムリソースを共有します。スレッドは、以下を含むスケジュール可能なエンティティーです。

リアルタイムにおける並列処理を作成するための潜在的なメカニズムは次のとおりです。

リアルタイムスレッドをフォークする前に、コンポーネントの相互作用レベルを評価する必要があります。新しいアドレス空間を作成し、それを新しいプロセスとして実行することは、コンポーネントが互いに独立している場合、または相互作用が少ない場合に役立ちます。コンポーネントがデータを共有したり頻繁に通信したりする必要がある場合は、1 つのアドレス空間内でスレッドを実行する方が効率的です。

リアルタイムでは、fork() システムコールは、成功すると値 0 を返します。エラーの場合は、エラー番号を返します。

Non-Uniform Memory Access (NUMA) や Symmetric multiprocessing (SMP) などのマルチプロセッサーシステムに見られるクロックソースの複数のインスタンスは、それらの間で相互作用し、CPU 周波数スケーリングまたはエネルギーエコノミーモードへの移行などのシステムイベントへの反応により、それらがリアルタイムカーネルに適したクロックソースであるかどうかを判断します。

推奨されるクロックソースは Time Stamp Counter (TSC) です。TSC が利用できない場合は、High Precision Event Timer (HPET) が 2 番目に最適なオプションとなります。ただし、すべてのシステムに HPET クロックがあるわけではなく、一部の HPET クロックは信頼できない可能性があります。

TSC および HPET がない場合のオプションとして、ACPI Power Management Timer (ACPI_PM)、Programmable Interval Timer (PIT)、Real Time Clock (RTC) などがあります。最後の 2 つのオプションは、読み取るのにコストがかかるか、分解能 (時間粒度) が低いかのどちらかであるため、リアルタイムカーネルでの使用は準最適となります。

POSIX は、タイムソースを実装して表すための標準です。システム内のその他のアプリケーションに影響を及ぼさずに、POSIX クロックをアプリケーションに割り当てることができます。これは、カーネルによって選択され、システム全体に実装されるハードウェアクロックとは対照的です。

指定の POSIX クロックを読み取るために使用される関数は <time.h> で定義される clock_gettime() です。clock_gettime() に相当するカーネルはシステムコールです。ユーザープロセスが clock_gettime() を呼び出すと、以下が行われます。

ただし、このコンテキストはユーザーアプリケーションからカーネルへの切り替えには CPU コストがかかります。このコストは非常に低くなりますが、操作が数千回繰り返し行われると、累積されたコストはアプリケーション全体のパフォーマンスに影響を及ぼす可能性があります。カーネルへのコンテキストの切り替えを回避し、クロックの読み出しを速くするために、VDSO (Virtual Dynamic Shared Object) ライブラリー機能の形式で CLOCK_MONOTONIC_COARSE クロックおよび CLOCK_REALTIME_COARSE POSIX クロックのサポートが追加されました。

_COARSE クロックバリアントのいずれかを使用して clock_gettime() が実行する時間測定は、カーネルの介入を必要とせず、ユーザー空間全体で実行されます。これにより、パフォーマンスが大幅に向上します。_COARSE クロックの時間読み取りの分解能はミリ秒 (ms) です。つまり、1ms 未満の時間間隔は記録されません。POSIX クロックの _COARSE バリアントは、ミリ秒のクロック分解能に対応できるアプリケーションに適しています。

以下のコードは、CLOCK_MONOTONIC_COARSE POSIX クロックで clock_gettime() 機能を使用したコード例を示しています。

#include <time.h>
main()
{
	int rc;
	long i;
	struct timespec ts;

	for(i=0; i<10000000; i++) {
		rc = clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
	}
}

#include <time.h>
main()
{
	int rc;
	long i;
	struct timespec ts;

	for(i=0; i<10000000; i++) {
		rc = clock_gettime(CLOCK_MONOTONIC_COARSE, &ts);
	}
}

上記の例を改善するには、より多くの文字列を使用して clock_gettime() の戻りコードを確認したり、rc 変数の値を確認したり、ts 構造のコンテンツが信頼できるようにしたりします。

リアルタイムスレッドは標準スレッドよりも優先度が高くなります。ポリシーには、最小値 1 から最大値 99 までの範囲のスケジューリング優先順位値があります。

次のポリシーは、リアルタイムにとって重要です。

各 SCHED_DEADLINE タスクは、period、runtime、および deadline パラメーターによって特徴付けられます。これらのパラメーターの値は、ナノ秒の整数です。

Red Hat Enterprise Linux の sched_deadline_period_max_us および sched_deadline_period_min_us パラメーターは、SCHED_DEADLINE スケジューリングポリシーの調整可能なカーネルパラメーターです。これらのパラメーターは、このリアルタイムスケジューリングクラスを使用して、タスクの最大および最小許容期間をマイクロ秒単位で制御します。

sched_deadline_period_max_us と sched_deadline_period_min_us は連携して機能し、SCHED_DEADLINE タスクの期間値の許容範囲を定義します。

パラメーターの値はマイクロ秒単位です。たとえば、1 秒は 100000 マイクロ秒に相当します。

リアルタイムでは、プロセスはデフォルトで任意の CPU で実行できます。ただし、プロセスのアフィニティーを変更することにより、事前に選択した CPU で実行するようにプロセスを設定できます。子プロセスは、そのロールの CPU アフィニティーを継承します。

システム上でアフィニティーをチューニングするためのリアルタイムプラクティスは、アプリケーションの実行に必要なコア数を決定してから、それらのコアを分離することです。これは、Tuna ツール、またはビットマスク値を変更するシェルスクリプトを使用して実現できます。

この taskset コマンドは、プロセスのアフィニティーを変更するのに使用でき、/proc/ ファイルシステムエントリーを変更すると割り込みのアフィニティーが変更されます。-p オプションまたは --pid オプション、およびそのプロセスのプロセス識別子 (PID) を指定して taskset コマンドを使用すると、プロセスのアフィニティーをチェックします。

-c オプションまたは --cpu-list オプションは、ビットマスクとしてではなく、コアの数値リストを表示します。アフィニティーは、特定のプロセスをバインドする CPU の数を指定することで設定できます。たとえば、以前に CPU 0 または CPU 1 のいずれかを使用していたプロセスの場合は、CPU 1 でのみ実行できるようにアフィニティーを変更できます。taskset コマンドに加えて、sched_setaffinity() システムコールを使用してプロセッサーアフィニティーを設定することもできます。

カーネルのデッドラインスケジューリングクラス (SCHED_DEADLINE) は、期限が制限された散発的なタスクに対して、Early Deadline First Scheduler (EDF) を実装します。ジョブ期限に従ってタスクに優先順位を付けます。つまり、最も早い絶対期限が最初になります。EDF スケジューラーに加えて、期限スケジューラーは定帯域幅サーバー (CBS) も実装します。CBS アルゴリズムは、リソース予約プロトコルです。

CBS は、各タスクがすべての期間 (T) で実行時間 (Q) を受け取ることを保証します。タスクのすべてのアクティブ化の開始時に、CBS はタスクの実行時間を補充します。ジョブが実行すると、runtime が消費され、タスクが runtime を使い果たした場合、タスクは抑制され、スケジュールが解除されます。スロットリングメカニズムは、単一のタスクがそのランタイムを超えて実行されるのを防ぎ、他のジョブのパフォーマンスの問題を回避するのに役立ちます。

リアルタイムでは、deadline タスクによるシステムの過負荷を回避するために、deadline スケジューラーは、タスクが deadline scheduler で実行するように設定されるたびに実行される受け入れテストを実装します。受け入れテストは、SCHED_DEADLINE タスクが kernel.sched_rt_runtime_us/kernel.sched_rt_period_us ファイルで指定されているよりも多くの CPU 時間を使用しないことを保証します。これは、デフォルトでは 1 秒で 950 ミリ秒です。

ミューテックスは、相互排除という用語に由来します。相互排除オブジェクトは、リソースへのアクセスを同期します。これは、一度に 1 つのスレッドのみがミューテックスを取得できるようにするメカニズムです。

mutex アルゴリズムは、コードの各セクションへのシリアルアクセスを作成するため、一度に 1 つのスレッドだけがコードを実行します。ミューテックスは、mutex 属性オブジェクトと呼ばれる属性オブジェクトを使用して作成されます。これは抽象オブジェクトであり、実装するために選択した POSIX オプションに依存するいくつかの属性が含まれています。属性オブジェクトは、pthread_mutex_t 変数で定義されます。オブジェクトは、ミューテックスに定義された属性を格納します。成功すると、pthread_mutex_init(&my_mutex, &my_mutex_attr) 関数、pthread_mutexattr_setrobust() 関数および pthread_mutexattr_getrobust() 関数は 0 を返します。エラーが発生すると、エラー番号が返されます。

リアルタイムでは、属性オブジェクトを保持して同じ型のミューテックスをさらに初期化するか、属性オブジェクトをクリーンアップ (破壊) することができます。ミューテックスはいずれの場合も影響を受けません。ミューテックスには、標準タイプと高度なタイプのミューテックスが含まれます。

非堅牢なミューテックスは自動的に解放されず、手動で解放するまでロックされたままになります。

バリアは、他のスレッのド同期方法と比較すると、非常に異なる方法で動作します。バリアは、すべてのスレッドとプロセスがこのバリアに到達するまで、すべてのアクティブなスレッドが停止するコード内のポイントを定義します。バリアは、実行中のアプリケーションが実行を続行する前にすべてのスレッドが特定のタスクを完了していることを確認する必要がある状況で使用されます。

リアルタイムのバリアミューテックスは、次の 2 つの変数を取ります。

バリアは、指定された数のスレッドが定義されたバリアに達したときにのみ pass するように状態を設定します。バリア状態が pass するように設定されると、スレッドとプロセスはさらに進みます。pthread_barrier_init() 関数は、定義されたバリアを使用するために必要なリソースを割り当て、attr 属性オブジェクトによって参照される属性でバリアを初期化します。

成功すると、pthread_barrier_init() 関数および pthread_barrier_destroy() 関数はゼロ値を返します。エラーの発生時に、エラー番号が返されます。

リアルタイムでは、条件変数 (condvar) は、POSIX スレッドの設定で、特定条件の達成を待機してから続行します。一般に、通知された状態は、スレッドが別のスレッドと共有するデータの状態に関連しています。たとえば、condvar を使用して、処理キューへのデータエントリーと、キューからのそのデータの処理を待機しているスレッドを通知できます。pthread_cond_init() 関数を使用して、条件変数を初期化できます。

成功すると、pthread_cond_init() 関数、pthread_cond_wait() 関数、および pthread_cond_signal() 関数はゼロ値を返します。エラーの場合は、エラー番号を返します。

前述のミューテックスオプションは、アプリケーションの作成または移植時に考慮すべきミューテックスクラスに関するガイダンスを提供します。

前述の関数タイプのリストと説明は、リアルタイムカーネルのスレッド同期メカニズムに使用する関数に関する情報を提供します。

TCP_NODELAY ソケットオプションは、Nagle のアルゴリズムを無効にします。setsockopt ソケット API 関数を使用して TCP_NODELAY を設定すると、準備が整うとすぐに、複数の小さなバッファー書き込みが個別のパケットとして送信されます。

送信前に連続したパケットを作成することにより、論理的に関連する複数のバッファーを単一のパケットとして送信すると、遅延およびパフォーマンスが向上します。または、メモリーバッファーが論理的に関連しているが連続していない場合は、I/O ベクトルを作成し、TCP_NODELAY が有効になっているソケットで writev を使用してカーネルに渡すことができます。

次の例は、setsockopt ソケット API を介して TCP_NODELAY を有効にする方法を示しています。

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));

TCP_CORK オプションは、ソケット内のすべてのデータパケットを収集し、バッファーが指定された制限を満たすまでそれらを送信しないようにします。これにより、TCP_CORK が無効になっている場合に、アプリケーションがカーネル領域にパケットを作成し、データを送信できるようになります。TCP_CORK は、setsocketopt() 関数を使用してソケットファイル記述子に設定されます。プログラムを開発する際にファイルから一括データを送信する必要がある場合は、TCP_CORK を sendfile() とともに使用することを考慮してください。

論理パケットがさまざまなコンポーネントによってカーネルに組み込まれている場合は、setsockopt ソケット API を使用して値 1 に設定することにより、TCP_CORK を有効にします。これは "ソケットのコーキング” として知られています。TCP_CORK は、コルクが適切なタイミングで取り外されていないと、バグを引き起こす可能性があります。

次の例は、setsockopt ソケット API を介して TCP_CORK を有効にする方法を示しています。

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &one, sizeof(one));

int one = 1;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &one, sizeof(one));

一部の環境では、カーネルがコルクをいつ取り除くかを識別できない場合は、次のように手動でコルクを取り除くことができます。

int zero = 0;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &zero, sizeof(zero));

int zero = 0;
setsockopt(descriptor, SOL_TCP, TCP_CORK, &zero, sizeof(zero));

TCP_NODELAY および TCP_CORK ソケットオプションは、ネットワーク接続の動作に大きく影響します。TCP_NODELAY は、準備ができたらすぐにデータパケットを送信することで利益を得るアプリケーションで、Nagle のアルゴリズムを無効にします。TCP_CORK を使用すると、複数のデータパケットを遅延なく同時に転送できます。

gcc tcp_nodelay_client.c -o tcp_nodelay_client -lrt

gcc tcp_nodelay_client.c -o tcp_nodelay_client -lrt

サンプルプログラムは、これらのソケットオプションが与える可能性のあるアプリケーションへのパフォーマンスの影響に関する情報を提供します。

次の例では、ループバックインターフェイスを使用して、次の 3 つのバリエーションを示します。

chrt ユーティリティーは、スケジューラーポリシーおよび優先度を確認して調整します。希望するプロパティーで新しいプロセスを開始するか、実行中のプロセスの現在のプロパティーを変更できます。

chrt ユーティリティーは、--pid または -p オプションのいずれかを使用して、プロセス ID (PID) を指定します。

chrt ユーティリティーは、次のポリシーオプションを取ります。

次の例は、指定されたプロセスの属性を示しています。

chrt -p 468

# chrt -p 468
pid 468’s current scheduling policy: SCHED_FIFO
pid 468’s current scheduling priority: 85

リアルタイムのプリエンプションは、実行中のタスクを一時的に中断して、後で再開することを目的としたメカニズムです。これは、優先度の高いプロセスが CPU の使用を中断したときに発生します。プリエンプションはパフォーマンスに重大な影響を及ぼす可能性があります。また、継続的なプリエンプションにより、スロットリングと呼ばれる状態が発生する可能性があります。この問題は、プロセスは常にプリエンプティブされ、プロセスを完全に実行できない場合に発生します。タスクの優先度を変更すると、自発的なプリエンプションを減らすことができます。

/proc/PID/status ファイルの内容を表示することにより、単一のプロセスで発生する自発的および非自発的なプリエンプションを確認できます。ここで、PID はプロセス ID です。

次の例は、PID 1000 のプロセスのプリエンプションステータスを示しています。

grep voluntary /proc/1000/status

# grep voluntary /proc/1000/status
voluntary_ctxt_switches: 194529
nonvoluntary_ctxt_switches: 195338

リアルタイムプロセスは、異なる一連のライブラリー呼び出しを使用して、ポリシーおよび優先度を制御します。関数には、sched.h ヘッダーファイルをインクルードする必要があります。シンボル SCHED_OTHER、SCHED_RR、および SCHED_FIFO も、sched.h ヘッダーファイルで定義する必要があります。

この表では、リアルタイムスケジューラーのポリシーおよび優先度を設定する関数を示します。

sched_yield() 関数は、実行中のプロセス以外のプロセスをプロセッサーが選択できるように設計されています。このタイプの要求は、適切に作成されていないアプリケーション内から発行すると失敗する可能性があります。

この sched_yield() 関数がリアルタイム優先度のプロセス内で使用されると、予期しない動作が表示される可能性があります。sched_yield() を呼び出すプロセスは、同じ優先度で実行しているプロセスのキューの末尾に移動します。同じ優先度で実行されている他のプロセスがない場合は、sched_yield() を呼び出したプロセスは引き続き実行されます。プロセスの優先度が高い場合は、ビジーループが発生し、マシンが使用できなくなる可能性があります。

一般的には、リアルタイムプロセスでは sched_yield() を使用しないでください。

getrusage() 関数は、指定されたプロセスまたはそのスレッドから重要な情報を取得します。次のような情報を報告します。

getrusage() を使用すると、アプリケーションにクエリーを実行して、パフォーマンスの調整とデバッグの両方のアクティビティーに関連する情報を提供できます。getrusage() は、/proc/ ディレクトリー内のいくつかの異なるファイルからカタログ化する必要があり、アプリケーションの特定のアクションまたはイベントと同期するのが難しい情報を取得します。

リアルタイムスケジューリングポリシーには、共通した大きな特徴が 1 つあります。それは、より優先度の高いスレッドがスレッドに割り込むか、スレッドがスリープまたは I/O の実行によって待機状態になるまで、リアルタイムスケジューリングポリシーは実行を続けるという点です。

SCHED_RR の場合、オペレーティングシステムは、実行中のスレッドに割り込み、同じ SCHED_RR 優先度を持つ別のスレッドを実行可能にします。このようないずれの場合も、優先度の低いスレッドが CPU 時間を取得できるようにするポリシーを定義する POSIX 仕様によりプロビジョニングが行われることはありません。リアルタイムスレッドのこの特性は、特定の CPU の 100% を独占するアプリケーションの作成が非常に簡単であることを意味します。ただし、これにより、オペレーティングシステムに問題が発生します。たとえば、オペレーティングシステムは、システム全体のリソースと CPU ごとのリソースの両方を管理し、これらのリソースを記述するデータ構造を定期的に調べて、それらのハウスキーピングアクティビティーを実行する必要があります。しかし、コアが SCHED_FIFO スレッドによって独占されていると、そのコアはハウスキーピングタスクを実行できません。最終的にシステム全体が不安定になり、クラッシュする可能性があります。

RHEL for Real Time カーネルでは、割り込みハンドラーは優先度が SCHED_FIFO のスレッドとして実行されます。デフォルトの優先度は 50 です。割り込みハンドラースレッドよりも高い SCHED_FIFO ポリシーまたは SCHED_RR ポリシーが割り当てられた cpu-hog スレッドでは、割り込みハンドラーの実行を防ぐことができます。これにより、これらの割り込みによるシグナルのデータを待機しているプログラムが枯渇し、エラーが発生します。

リアルタイムカーネルには、リアルタイムタスクで使用する帯域幅の割り当てを可能にする保護メカニズムが搭載されています。この保護メカニズムは、リアルタイムスケジューラーのスロットルと呼ばれています。

リアルタイムスロットリングメカニズムのデフォルト値は、リアルタイムタスクで CPU 時間の 95% を使用できるように定義します。残りの 5% はリアルタイム以外のタスク (SCHED_OTHER および同様のスケジューリングポリシーで実行されるタスク) に割り当てられます。1 つのリアルタイムタスクが CPU タイムスロットの 95% を占有している場合、その CPU 上の残りのリアルタイムタスクは実行されないことに注意してください。残りの 5% の CPU 時間は、リアルタイム以外のタスクでのみ使用されます。デフォルト値は、次のようなパフォーマンスの影響を与える可能性があります。

リアルタイムスケジューラーのスロットリングは、/proc ファイルシステム内の次のパラメーターによって制御されます。

スレッドスタベーションは、スレッドがスタベーションしきい値よりも長く CPU 実行キューにあり、進行しない場合に発生します。スレッドスターベーションの一般的な原因は、CPU にバインドされた SCHED_FIFO や SCHED_RR など、固定優先度のポーリングアプリケーションを実行することです。ポーリングアプリケーションは I/O をブロックしないため、kworkers などの他のスレッドがその CPU で実行されなくなる可能性があります。

スレッドスタベーションを減らすための初期の試みは、リアルタイムスロットリングと呼ばれます。リアルタイムスロットリングでは、各 CPU に非リアルタイムタスク専用の実行時間の一部があります。スロットリングのデフォルト設定はオンであり、CPU の 95% がリアルタイムタスク用に割り当てられ、5% がリアルタイム以外のタスク用に予約されます。これは、1 つのリアルタイムタスクが原因でスタベーションが発生している場合には機能しますが、CPU に複数のリアルタイムタスクが割り当てられている場合には機能しません。以下を使用して問題を回避できます。