問題タブ [readwritelock]

pthread 読み取り/書き込みロックのテストで予期しない結果に遭遇しました。

以下は私のコードです。

何度か実行した後、時折、予期しないものがあることに気付きます。次に例を示します。

0 1 2 3 0

リーダースレッドからの出力です。基本的に、数字のサイズは今のところ5だと言っています。その場合、結果は 0 1 2 3 4 になるはずです。

ところで、追加の相互排他ロックを実装しようとしたところ、予期しない動作が発生しました。

解決策と根本原因に興味があります。誰か助けてくれませんか？

どんな助けでも事前に感謝します。

boost::UpgradeLockableC++14 で使用できることはわかっています。
C++11に似たものはありますか?

std::list を使用して文字列を保持し、1 つのスレッドがリストに書き込み、他のスレッドがそれから読み取ります (最初のものを取得してリストから消去します)。コードは次のとおりです。

行にコンパイルエラーがありますcond.wait(uniquelock, ...

condition_variable で読み取り/書き込みロックを使用する正しい方法は何ですか?

多くのチュートリアルで、ReadWriteLock の再入不可の実装の下に出くわしました。

質問：

このクラスのオブジェクト (たとえばlock) は、同期のためにすべてのリーダー スレッドとライター スレッドで共有されます。

リーダー T1 が を呼び出しlock.lockRead()、これがロック オブジェクトのロックを取得し、同時にリーダー T2lockRead()が同じオブジェクトを呼び出すとします。ただし、T1 は既にオブジェクトをロックしているため、T2 はブロックされ、Queue で待機する必要があります。

では、このコードでは、複数のリーダーが同時に readLock を設定できるようにするにはどうすればよいでしょうか?

私がいつこれを間違えたのか教えてください。

共有リソースへのアクセスを同期するとき、通常のミューテックス (基本的には単なる書き込みロック) の代わりに読み取り/書き込みロックを使用しない理由はありますか?

言い換えれば、選択した優先同期構造としてロックの読み取り/書き込みをデフォルトにするだけで、自分自身を撃っていますか?

常に読み取り/書き込みロックを選択し、それに応じて読み取りロックと書き込みロックを使用する理由の 1 つは、何らかの同期を実装できることであり、パフォーマンスの向上という利点を得る一方で、同期についてもう一度考える必要はありません。ある日、より競合の多い環境にコードをドロップした場合の将来のスケーラビリティ。したがって、実際のコストなしで潜在的なメリットがあると仮定すると、常に使用することは理にかなっています. それは理にかなっていますか？

これは、実際にはリソースが制限されていないシステム上にあり、おそらくパフォーマンスの問題です。また、私はこの質問を一般的に表現しましたが、問題がある場合は、QtQReadWriteLockとQMutex(C++) を特に念頭に置いています。

こんにちは、Java の ReadWriteLock について読んだことがありますが、その再入可能部分を理解しているかどうかはわかりません。1 つのメイン スレッドのみを使用して再入可能性を示す 2 つの簡単なコード例を次に示します。

そして2番目の例

最初のものでは sysout が実行されますが、2 番目のものでは実行されません。なぜですか? 両方のロックは同じスレッドによって取得されるため、ここでは再入可能な状況がありますが、書き込みロックが最初に取得された場合にのみ入口が達成されます。その他の操作 (書き込みまたは読み取り)。

EMPID のように、データベースの多くのテーブルに存在するものを記述 (更新) したいとします。すべての EMPID を 4 つの数字から 5 つに変更したいとします。

これをどのように書きますか？write_lock先頭が a で末尾がロック解除の通常の更新クエリですか?