C（win32）でフレームを送信するためのソケットとスレッドのアプローチ

Question

私は、USBデバイス（USBCap）からフレームをキャプチャしてネットワーク経由で2番目のプログラムImage Server（IMGSvr）に送信します。

どちらのプログラムも、同じマシンまたは同じローカルネットワーク上で実行されます。

USBCapは、複数のUSBデバイス（「チャネル」という名前）をキャプチャします。これを行うために、私はDirectShowラッパー（videoInput）から新しいフレームを取得している各チャンネルにスレッドプロシージャを使用しています。

問題はソケットから始まります：IMGSvrにフレームを送信するのに、ただ1つのTCP SOCK_STREAM接続を使用しています。 send（）はsend（）の後続の呼び出しをブロックしています（他のスレッドによって）utilフレームが送信されます。

すべてのスレッドをブロックすると、なぜ私はマルチスレッドプログラムを使用していますか？

これを解決するにはどうすればよいですか？スレッドにプログラムを適応させると、新しいフレームがフレームのキューに入れられ、別のスレッドがこのキューを空にし、キューに入れられたフレームをIMGSvrに送信することがあります。

あなたはどう思いますか？

新しい要素を書き込むときに、このキューにLOCKを実装する必要がありますか？書き込み

おかげで、 ダニエル・コッホ

Answer 1

send()保証は、それが単一の呼び出しに渡されたすべてのデータが受け入れられることを保証しませんが、アトミックです。したがって、第2のスレッドは、第1のスレッドがそのデータを送信キューに付加するまで待たなければならない。

データが部分的にしか受け入れられず、その後ソケットがロックされておらず、2番目のスレッドがチャンスを得るケースがあります。この場合、無効な出力ストリーム

専用のライターとキューイングメカニズムを使用するアプローチは正しいようです。キューを保護するにはロックが必要ですが、リンクされたリストに項目を追加するのに必要なクリティカルセクションは非常に短いので、ここに競合があってはいけません。