私はC++で、自分で作成したマップを使用してデータを格納するプロジェクトに取り組んでいます。この意味でのマップは、「地理的な」マップに似ているため、画像になります。読み取りと書き込みにはさまざまなスレッドがあります。マップのデータは、整数のベクトルのstdベクトルに格納されます。そのサイズは変更されず、ゲッターおよびセッター機能を介して特定のピクセルのコンテンツのみが変更されます。
私の問題は次のとおりです。ピクセルの値が符号を変更したり、本来の値と完全に異なったりするという意味で、すべてが正常に機能することもありますが、画像が破損することがよくあります。これは、ピクセルへのスレッド化された読み取り/書き込みアクセスの問題である可能性がありますか？その場合、標準のベクトルの代わりに何を使用する必要がありますか？ミューテックスを使用して、1つのスレッドのみがベクターの読み取りまたは書き込みを行うようにしましたが、これらの読み取り/書き込み操作は頻繁に発生するため、すべての操作でベクターをロックするとアプリケーションが遅くなります。
なんらかのロックが必要になります。それがあなたのパフォーマンスをひどく損なうことを防ぐために、あなたはロックの範囲をできるだけ小さくするように努めるべきです。たとえば、個々の行ベクトルをロックして、異なる行への書き込みが互いに干渉しないようにすることができます。どのようなソリューションが最適かは、アクセスパターンとプラットフォームによって異なります。
マルチスレッドを実行するときは、スレッドのスコープを可能な限り分離するようにしてください。
考えて例を挙げてください。壁があり、それを黒と白のストライプでペイントしたいとします。そして仕事をスピードアップするために、あなたは2人の従業員を雇うことにしました。
これで、このジョブを2つの方法で割り当てることができます。1.黒のストライプのペイントを1人のワーカーに割り当て、白のストライプを別のワーカーに割り当てます。2.壁を2つのパーティションに分割し、左側のパーティションを1人のワーカーに割り当て、右側の部分を2番目のワーカーに割り当てます。
どちらがより良いパフォーマンスをもたらす可能性がありますか？
一般的なケースでは、作業者の作業領域が十分に分離されており、一方が他方が仕事をするのを待つ必要がないため、2番目の方が優れています。もちろん、最初のアプローチは間違いではありませんが、1人の作業員がどこかで絵を描いていて、2人目の男も同じ場所に到着し、最初の作業が終了するのを待たなければならない可能性があります。ここで、それぞれ10人の作業員が特定の色を1つだけペイントしているとしたらどうなるか想像してみてください。
マルチスレッドプログラミングも同様です。問題のあるデータをより適切に分割できれば、スレッドを効果的に機能させることができます。
軽量ロックを使用してください。それはウィンドウズで「CriticalSection」を使用します。または、TinyThread（http://tinythreadpp.bitsnbites.eu/）のように、独自のユーザースペースロックを記述します。これらはASMで記述されており、実際にロックおよびロック解除するためのオーバーヘッドはほとんどありません。
ロック自体が高速であることを確認したら、それでも動作が遅い場合は、ロックの競合があるためです。たとえば、複数のスレッドがすべて同じリソースをロックする必要があります。使用例では、「読み取り/書き込み」ミューテックスのようなものを検討してください。これは、読み取りミューテックスと書き込みミューテックスを持つクラスです。ミューテックスの「readLock」メソッドは、ミューテックスの参照カウントをインクリメントするために数サイクルだけロックします。「readUnlock」は参照カウントをデクリメントします。「writeLock」は、読み取りミューテックスをロックし、リーダーが読み取りミューテックスをロックしないようにするフラグを設定します。次に、書き込みミューテックスをロックして、書き込み操作を実行します。したがって、一度に1つの書き込み操作のみが発生し、書き込み中に読み取りが発生しないことを保証します。ただし、同時読み取りは許可されます。