ノンブロッキングタイマーとサーバーのソリューションはブーストスレッドですか？

Question

私のプロジェクトにはキュー、サーバー、タイマーがあります。サーバーはデータを受信して​​キューに入れ、タイマーがキューを処理します。キューが処理されると、外部プロセスはpopenでオープンされます。つまり、popenはプロセスが終了するまでタイマーをブロックします。

私が間違っていても、サーバとタイマーの両方が同じio_serviceにリンクされているため、サーバがデータを受信すると、io_serviceが次のイベントに進むのをブロックしてしまいます。キュー内のプロセスが実行されている場合はタイマーブロック。

私はboost :: threadに基づいたソリューションで考えていますが、私はスレッドを使用したことがないので、どのアーキテクチャを使うべきかはわかりません。私のオプションは次のとおりです。

2つのスレッド - タイマー用とサーバー用の2つのスレッド、それぞれ独自のio_serviceを使用します 1つのスレッド - 独自のio_serviceを持つタイマーのスレッドです。サーバーは、キュー（簡単なマップ）を共有する必要があります両方の方法では、メインプロセスに

ままなので、私は誰かが見てみることを望んでいる場合は、私がミューテックスや他のもの

といくつかの問題があると思いますコードは、https://github.com/MendelGusmao/CGI-for-LCD-Smartie

ありがとうございます！

Answer 1

サーバーが接続をリッスンし、データを処理し、そのデータをあるスレッドでキューに入れることができない理由はわかりませんが、タイマーはこれらのアイテムを別のスレッドのキューから取り出し、待ち行列データを処理するためにpopen()を介して処理する。私が見逃していた細部がない限り、サーバーがリッスンするソケット（またはパイプ、FIFOなど）は、libcランタイムによって内部でpopen()によって開かれるパイプとは別です。サーバーとタイマーのスレッドは互いにブロックされません。メモリをオーバーフローさせずにサーバから入るデータを格納するのに十分なスペースがキュー内にあることを確認するだけです（つまり、データレートの高いアプリケーションで、データがそれが処理されている、あなたは最終的にメモリが足りなくなります）。

最後に、muextes経由で共有キューを守ることは良いことですが、実際にはバインドされたキューを使用するかどうかを記述しているような単一のプロデューサ/コンシューマの状況では必要ありません（つまり、リングバッファ）。あなたが無制限のキューを決定した場合、そこにいくつかのロックレスアルゴリズムがありますが、それらはかなり複雑で、std::queue<T>のような無制限のキューを保護することが絶対必要です。

Answer 2

Windowsスレッドを使って説明したものとほぼ同じことを実装しました。私の消費者は、キューが長すぎるときにプロデューサによって起動されるイベントHANDLEを待っていました。待ち行列にタイムアウトがあったため、待ち行列が十分に速く満たされない場合でも、消費者は依然として待ち行列を処理します。それはメインスレッドがそのために使用されたので、ウィンドウのサービスでした。そして、はい、ミューテックスは共有オブジェクトにアクセスする必要があります。

私は2つのスレッド（メインを除く）、1つのミューテックス、1つの共有オブジェクトを使用しました。私はあなたのより良い選択肢はロジックをよりきれいに保つので、2つのスレッドであると思います。メインスレッドは2つのスレッドを開始して待機します（またはシグナル、制御、出力に使用できます）.2つのスレッドはそれぞれ独自のジョブを実行しています。