標準Linuxカーネルと比較してRT LinuxカーネルでリアルタイムC ++アプリケーション（ユーザースペースとLinuxドライバ）をプログラムするのに問題はありますか？
Linux RTパッチはカーネルスケジューラ、セマフォ、ミュートなどを変更します。これらの変更が開発者にとって透明であるかどうか疑問に思います。それとも、そのようなアプリケーションを作成するときに特別な注意を払うべきですか？
答え1
状況によって異なります。実際にミューテックスとセマフォを使用するカーネル空間ドライバを開発する場合は、パッチがあるかどうかをすばやく確認する必要があります。これは開発者としての責任であり、ウェブサイトからの回答は問題を解決できません。
主にユーザースペースソフトウェアを開発する場合は、安定している必要があるカーネルインターフェースとのみ戦っているため、これらの変更は影響を受けません。
強力なリアルタイム要件には、通常、ユーザー空間アプリケーションは推奨されません。
RTコアはほとんどの主要なディストリビューションで利用できるので、RTの楽しみ以外に特別なものは必要ないという結論に達しました。次の点を念頭に置いてください。https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application
答え2
私はC ++でRTアプリケーションを書いた経験がありません。代わりにAdaを使用しましたが、Erlangが適切かもしれません。 （RT Javaもありますが経験はありません。）
原則として、IPCツール（言及どおり）やマルチプログラミングツールなどを考慮すると、forkC ++を使用することは問題になりません。明示的なメモリ管理は、マスターするまでエラーが発生しやすいです。
RT Linuxは一般的なLinuxの拡張です。 （これは多くのRTOSで共通です。これは非RTSの拡張です。しかし、時間共有、オペレーティングシステム。 )
RT タスクが非 RT プロセスと共存するために、RTOS は特定のアクションを実行します。たとえば、タスクをメモリにロックしたり、プロセスよりも高い優先順位を割り当てたりします。その目的は、非RTプロセスがRT操作をブロックしないようにすることです（したがって、潜在的に期限を守らないようにすることができます。RTSの全体的な目的は、これが発生しないようにすることです）。
RT Linuxの場合は、Linuxカーネルを割り当てます。最低優先順位。
RT Linuxは、Linuxカーネルの下とハードウェアの上にあります。ただし、Linuxカーネルはそれを認識しません。つまり、ハードウェアとRT Linuxを全体的に（つまりハードウェアとして）扱います。それにもかかわらず、すべてのハードウェア割り込みはRT Linuxカーネルによってブロックされ、そのうちのいくつか（RTタスクに関連する）はRTOSによって処理されます（残りは処理のために通常のLinuxカーネルに渡されます）。
RT LinuxはRTスケジューリングアルゴリズムを使用して、「予測可能な」動作（RT用語で）を保証します。つまり、すべての作業が締め切りに従います。これは、そのような保証ができないLinuxとは異なります。また、RT Linuxは仮想メモリをサポートしていません。これは（前後にスワップ）、コンテキスト切り替えが長く（制限されていない）、予測不能な待ち時間が発生するためです。 （実際、すべてのRT Linuxタスクにはハードウェアへのフルアクセス権があります。）