私のLinuxC++アプリケーションは、センサーデータを定期的に読み取っています。読み出しは、単純なファイルI / O操作で行われます（OSはファイルに書き込み、アプリケーションはこのファイルから読み取ります）。私のプラットフォームに関するいくつかの情報：
センサーデータを読み取るための2つのアプローチを検討しました。
どのアプローチがより多くの感覚を生み出しますか、他の選択肢はありますか？両方のソリューションのコストはどれくらいですか（たとえば、最初のアプローチでのメインスレッドのブロック、または2番目のアプローチでのコンテキスト切り替え）？
アプリケーションやハードウェアについては何も知りませんが、考慮すべき点がいくつかあります。
したがって、どちらのソリューションも自動的に「簡単」に実行できます。
1秒に1回だけ発生する読み取りの「コンテキスト切り替え」については心配しません。それは関係ありません。
特にアプリケーションがユーザースペースで実行されていることを考慮すると、ハイパースレッディングのないシングルコアCPUでも、1秒に1回のコンテキストスイッチのコストは問題ではないと思います。したがって、実際にはタイムクリティカルではありません。メインスレッドでセンサーをポーリングすると、アプリケーションのロジックが複雑になります。したがって、その目的でスレッドを開始することをお勧めします。
メインスレッドは他に何をする必要がありますか？ブロックしても大丈夫ですか？その場合、別のスレッドでタイマーなどを実行する必要はありません。
メインスレッドが定期タイマーの待機をブロックできない場合は、別のスレッドを作成する必要があります。スレッド間のデータ通信は、両方のスレッドにアクセス可能で、ミューテックス（pthread_mutex_tを検索）を介して保護されているオブジェクトを介して行うことができます。これは非常に簡単です。
どのソリューションが優れているか、そしてどのようなコストがかかるかについては、メインスレッドが他に何をしているかによって異なります。しかし、これほど単純なものの場合、どちらの方法もほぼ同じである必要があり、コンテキストの切り替えは何にも影響を与えないはずです。パフォーマンスに最も影響を与えるのは、読み取りのパフォーマンスがどれほど高いかです。
各反復には1秒以上かかるため、スリープループはタイミングを歪めます。タイマーにはその問題はなく、このシナリオのために作られています。したがって、タイマーを選択します。
トリガーは1秒に1回だけなので、パフォーマンス面では違いはありません。
Linuxドライバーがセンサーデータを読み取り、それをデバイスファイルに毎秒書き込む場合は、アプリケーションでタイマーロジックを複製しないでください。1秒間スリープした後でも、アプリケーションは1秒前と同じデータを読み取る場合があります。より良いアプローチは、デバイスファイルでブロッキング読み取りを呼び出すスレッドを用意することです。新しいセンサーデータが利用可能になり、読み取りリターンをブロックすると、スレッドはデータを処理して読み取りを再度呼び出すことができます。