私はC＃を使用して、24時間年中無休で動作し、可動機械がアプリケーションに依存する、複数のリアルタイムの高速マシンビジョンアプリケーションを作成しました。ソフトウェアで問題が発生した場合、現実の世界ではすぐに目に見える問題が発生します。
C＃/。Netがそうするためのかなり良い機能を提供していることがわかりました。他の人が言ったように、ガベージコレクションのトップに留まることは間違いありません。処理をいくつかの論理ステップに分割し、それぞれが別々のスレッドで機能するようにします。私はProducer Consumerプログラミングモデルがこれにうまく機能することを発見しました。おそらく ConcurrentQueue は初心者向けです。
あなたは次のようなものから始めることができます：
- スレッド1はカメラの画像をキャプチャし、何らかの形式に変換して、ImageQueueに入れます
- スレッド2はImageQueueを使用して画像を処理し、ProcessedQueueに配置されるデータオブジェクトを作成します
- スレッド3はProcessedQueueから消費し、その結果に対して興味深いことを行います。
スレッド2に時間がかかりすぎる場合でも、スレッド1と3は相変わらず問題を抱えています。あなたがマルチコアプロセッサを持っているなら、あなたは数学でより多くのハードウェアを投げるでしょう。上記で書いたスレッドの代わりに複数のスレッドを使用することもできますが、結果を手動で順序付けする必要があります。
編集
他の人々の答えを読んだ後、おそらくあなたは私の「リアルタイム」の定義を議論することができます。私の場合、コンピュータはターゲットを作成し、実際のリアルタイムのモーションを行うモーションコントローラに送信します。モーションコントローラーは、タイミング、最大/最小範囲、スムーズな加速/減速、安全センサーなどの独自の安全レイヤーを提供します。これらのコントローラーは、工場全体で1ms未満のサイクルタイムでセンサーを読み取ります。
ガベージコレクトが定義された時間内にシステムの応答を停止することがあるので、「ハードリアルタイムシステム」にメインストリームのガベージコレクションされた言語を使用することはできません。オブジェクトの割り当てを回避することは役立ちますが、証明の方法が必要です。ガベージを作成しておらず、ガベージコレクターが起動しません。
ただし、ほとんどの「リアルタイム」システムは、実際には常に厳しい時間制限内で応答する必要はないため、すべてがダウンして、「リアルタイム」が意味することを実行します。
システムの一部が「ハードリアルタイム」である必要がある場合でも、UIのようにシステムの他の大きなパーツは必要ありません。
（「リアルタイム」ではなく、アプリが高速である必要があると思います。100年ごとに1フレームが失われると、何人が殺されるでしょうか？）
もちろんです。重要なのは、ガベージコレクションとメモリ管理をできるだけ回避することです。可能な場合はバッファまたはオブジェクトプールを使用して、新しいオブジェクトをできるだけ回避するようにしてください。
- もちろん、誰かがそれを行うためのライブラリを開発しました：AForge.NET
- C＃だけでなく、あらゆるリアルタイムアプリケーションと同様に、@ Davidが提案するようにバッファーを管理する必要があります。
- それだけでなく、 XNA Framework （3Dゲームなど）もあり、C＃を使用して DirectX をプログラミングすることもできます。これは非常にリアルタイムです。
- また、必要に応じて C＃でのポインタ操作 も実行できることをご存知ですか？
それは、それがいかに「リアルタイム」である必要があるかに依存します。つまり、タイミング制約とは何か、そして「何かをする」必要がある速さ。
あなたが「何かをする」ことを多分300msごとに.NETで処理できる場合、たとえばタイマーイベントで言うと、私はWindowsが大丈夫であることを発見しました。これは、年齢や速度の異なる複数のシステムで当てはまるものです。いつものように、YMMV。
しかし、その数は多くのアプリケーションにとって非常に長いです。多分あなたのためではない。
いくつかの調査を行って、アプリケーションがアプリケーションに対して十分に速く応答することを確認してください。