Boost の shared_mutex は再帰的ではないようです。(全体を再実装することなく)
5 に答える
このスレッドとこの優れた説明を見てください。なぜshared_mutex
一般的に悪い考えなのか. したがって、それも悪い考えであることに同意しない場合は、パフォーマンスを向上させることはできないため、共有recursive_mutex
せずに使用してください。大きな変更がなくても、少しだけきれいなコードを受け取ることができます。
プロジェクトで shared_mutex を使用して、多くのスレッドがデータを頻繁に読み取り、ほとんど変更しない場合に、非常に競合するマップをロックしようとしました。少し悪いパフォーマンス結果を受け取りました
shared_mutexは設計、つまりプログラムでどのように使用するかによって異なるため、これは悪い考えであるというAndyには部分的に同意しません。共有ミューテックスを使用して長時間頻繁に読み取る場合は、まれな書き込みで読み取るための短い頻繁なロックに単純なミューテックスを使用する場合よりも効率的なパフォーマンスが得られると思います。つまり、shared_mutexは、何か長いことを同時に行う方法です。そして、この場合、長いロックは悪い設計ではないと思います。
あなたは私をサポートしますか、それとも私は間違っていますか?
私は以前、個人的にこの道を進んできました。簡単な答えはノーです。shared_recursive_mutexはありません。
再帰的ミューテックスが一般的にどのように悪い考えであるかについて他の人があなたに言うことには本当に同意しません、それは確かに時間を節約し、いくつかのエラーを防ぐことができます。ただし、独自のshared_recursive_mutexを実装したくない場合は、非再帰的なミューテックスを使用する必要があります。そう悪くはない。
boost::recursive ミューテックスは排他的です。shared_mutex を拡張する必要があると思います。現在のスレッド ID をセットに保持し、ロックを提供する関数でセットに存在するかどうかを確認できます。
そのような場合は、 shared_ptrを使用する必要があります。ミューテックスを shared_ptr に配置すると、ミューテックスで参照カウントが行われ、同様の結果が得られます。