ローカル ネットから UDP データを読み取り、そのデータを現在の値テーブル (CVT) に格納するアプリを設計する必要があります。
次に、別のスレッドが来て、CVT から値を読み取り、メッセージを送信し、UDP 経由で送信します。CVT エントリは、float や int などの個々のスカラーで構成されます。
私の質問は、CVT からの更新/読み取りを保護するために、どの程度の相互排除が必要ですか?
別の言い方をすれば、32 ビット int に書き込むスレッドとその int から読み取る別のスレッドがある場合、そのためにミューテックスを使用する必要がありますか?
リーダースレッドが絶対的な最新の値を保存していなくてもかまいません。変更中にその場所を読み取ろうとすることだけが心配です。キーワード「volatile」が Java でこのシナリオに使用されることは知っていますが、C++ では同じことを行いません。
ここでの多くは、スレッド化をサポートするために使用しているプラットフォームの種類によって異なります。利用可能なアトミック型がある場合は、それらをそのまま使用できます。それ以外の場合は、はい、ミューテックス (ある種の -- 多くのプラットフォームには複数の型があります) でほとんど立ち往生しています。
この問題について説明しているように、ライターが 1 つしかない場合は、既にスレッドセーフです (コードが 32 ビット以上のワード幅のプロセッサで実行されると仮定します。この場合、32 ビットの書き込みはアトミックです)。
ストレージ修飾子はvolatile、変数が非標準のロードストア セマンティクスを持っていること、つまり、メモリ内の値と一貫性を保つ CPU レジスタ内のコピーに依存できないことをコンパイラに伝えます。
一般的な副作用は、その変数の周りの最適化を無効にすることです (つまり、メモリ内のストレージがその下で変更されないことに依存する最適化)。その結果、使用するたびにメモリからリロードされます。
volatileこれは、マルチスレッドの状況で が役立つ 数少ない機会の 1 つです。
現在の値テーブルに何を使用しているかによって異なります。SQLServer のようなデータベースを使用している場合は、データベースがそれを処理するため、心配する必要はありません。
ファイルシステムを使用している場合、問題は残ります。
要求をキューに入れ、順番に応答する TCP ベースのクライアント/サーバーを作成できます。
メモリを使用している場合は、ミューテックスを使用する必要があります。
32ビットがメモリ内で適切に整列されている限り、それはほとんどの最新のプラットフォームでデフォルトで実行されているため、実質的にスレッドセーフintであると推測しています.int