この特定のアプリケーションを分析すると、pthread の選択に関連する質問は 1 つだけです。
- センサー リーダーとネットワーク ライターは、アドレス空間を共有する必要がありますか?
この場合、答えは明らかに「いいえ」だと思います。もちろん、それが唯一の可能な質問ではありませんが、唯一の密接な質問です。個別のプロセスを好む理由は次のとおりです。
- アプリケーションの 2 つの部分に共通のコードはありません。RS485 は HTTP/JSON とは大きく異なります
- 責任の分離: RS485 側が UART で待機している場合、本当に HTTP 側をブロックしますか?
- OSにその仕事をさせるので、あなたがする必要はありません。pthreadsを使用する場合、カーネルが無料で行う多くの同期とプリエンプションを処理する必要があり、書く必要のないコードには新しいものはありませんバグ。
さらなる分析には、あなたが与えた以上の詳細が必要ですが、選択について考えるための追加の方法が 1 つあります。スレッドは、プロセス モデルのいくつかの制限を軽減するために発明されました。これらの制限に達することがわかっている場合を除き、別のプロセスを使用してください。
コメントに応じて追加:
私はpsusiの提案されたデザインに半分同意します。必要なプロセスは 2 つだけです。1 つのプロセス (センサー リーダーとしましょう。これは適切な選択です) は、1 つの HTTP 送信者のみをフォークします。2 つのプロセスは、パイプのような従来の IPC を使用して通信できます。センサー プロセスは、パイプにデータがある場合にデータを送信し、子 (http) プロセスはそれを json にパックして途中で送信します。
2 つの長寿命プロセスしか必要とせず、おそらく pthread 実装とほぼ同じ量のコアを使用し、正しく行うのははるかに簡単です。