そのため、Linux/POSIX環境で成長しているCプログラムに取り組んでおり、どのように進めればよいかわからない領域に遭遇しました。
基本的に、モジュールパターンを使用して、さまざまな外部ハードウェアおよびI/O操作(ファイルモジュール、カメラモジュール、シリアルモジュールなど)で使用するコードを開発しています。これらの操作の一部には少し時間がかかります。完了までの時間です。明らかな理由により、独自のスレッドに配置する必要があります。
私の質問は基本的にこれに要約されます:モジュール自体が内部操作のスレッド化を制御する必要がありますか、それとも各モジュールの「上」の呼び出しコードが生の関数自体にスレッド化を実装する必要があります。
一方では、複雑さの観点から、中央のポイントから複数のモジュールのスレッド化を制御しなければならないことは少し混乱する可能性があることがわかります。ただし、モジュールがそれ自体でスレッド化を実装している場合は、個々のプロセスのコンテキストと制御が失われます。妥協案として、インターフェイスヘッダーファイルを介してスレッドオブジェクトを公開することも考えられますが、その場合は、最初のステップに戻る可能性があります。
モジュールは現在、コードの抽象的な機能ブロックとして設計されており、構成変数の外部にはほとんど公開されていません(したがって、特定のビルドまたはリビジョンのハードウェアを実装するさまざまなモジュールを備えた汎用の「カメラ」インターフェイスになります)。 IO操作は集中的ではありませんが、完了するまでに時間がかかる傾向があります。したがって、公開されたbool/enum変数を使用してステータスを示す可能性がありますか?
最善のオプションは、両方のアプローチを使用することですが、スレッドが所有者だけに知られるようにすることを十分に認識してください。
各モジュールの目標は次のとおりです。
これらの箇条書きを実現する最も簡単な方法は、モジュールのAPIをブロックして同期させることです。これは、モジュールがスレッドを使用したり、スレッドを外部で管理したりするべきではないという意味ではありません。これは、モジュールがAPIの背後で内部スレッドを使用する必要がある場合、APIユーザーから非表示にして、関数呼び出しがユーザーに同期して見えるようにすることを意味します。
ほとんどの場合、ブロッキングと同期は機能しますが、常に機能するとは限りません。呼び出しに時間がかかりすぎる場合や同期が適切でない場合は、モジュールのAPIを非同期にすることをお勧めします。そうは言っても、これにより呼び出しコードが複雑になるため、APIに長い時間がかかる可能性のある呼び出しがある場合でも、呼び出し元がインターフェイスを呼び出す高レベルの操作をすでに管理している場合は、インターフェイスをブロックしたままにしておく方がよい場合があります。
より高いレベルの操作と言えば、モジュールAPIのスレッディングの組み込み方法にのみ焦点を当てた場合の問題は、モジュール操作がより完全なシステム操作の一部に過ぎない傾向があることです。したがって、呼び出し元のコードも、長い操作処理を調整するために独自のスレッドを管理する必要があります。シームレスな統合を実現するには、モジュールスレッドが呼び出し元/上位レベルのコードに認識されておらず、同様にモジュールが呼び出し元のスレッドを認識していないことが非常に重要です。
ほとんどの場合、メインプログラムでスレッドを管理し、各モジュールでその機能を実行する必要があります。これを行うには、モジュールがすべてサポートする必要があるAPIを定義する必要があります。メインプログラムは、スレッドの開始時にこのAPIから関数を呼び出します。スレッドが完了またはキャンセルされた後にクリーンアップするのは2番目、スレッドの進行状況を報告する3番目は、メインプログラムが進行状況を表示できるようにするためです。メーター。
確実にする最も簡単な方法は、モジュールがすべてのスレッド管理を行うと想定して、2つのモジュールをスタブアウトすることです。 2番目のモジュールを作成するときに最初のモジュールからコピーして貼り付けるコードは、メインプログラムのスレッドマネージャーにリファクタリングするのに適した候補です。