排他ロックと共有ロックの違いは何ですか?


118

ウィキペディアによると、

共有ロックは「読み取りロック」と呼ばれることもあり、排他ロックは「書き込みロック」と呼ばれることもあります。

「共有」および「排他的」という用語の背後にある理由を説明できますか?


非排他ロックは共有ロックの別名ですか?
Ramesh Papaganti

回答:


417

これは楽しい(そしてふさわしい)類推だと思ったので、この回答を書き留めました。

ロック可能なオブジェクトは、教師(ライター)と多くの学生(リーダー)がいるクラスルームの黒板(ロック可能)と考えてください。

教師がボードに何か(排他ロック)を書き込んでいる間:

  1. まだ書き込み中であり、ビューをブロックしているため、誰もそれを読み取ることができません => オブジェクトが排他的にロックされている場合、共有ロックは取得できません

  2. 他の教師が立ち上がらず、書き込みも開始されないか、ボードが読めなくなり、学生を混乱させる=> オブジェクトが排他的にロックされている場合、他の排他的ロックは取得できません

生徒がボード上にあるものを読んでいるとき(共有ロック):

  1. 彼らはすべて一緒にその上にあるものを読むことができます=> 複数の共有ロックが共存できます

  2. 教師は、ボードをクリアしてさらに書き込みを行う前に、それらが読み終わるのを待ちます=> 1つ以上の共有ロックがすでに存在する場合、排他ロックを取得できません


2
とても良い説明。しかし、POは、サーム自体の説明ではなく、「共有」および「排他的」宗派の起源について問い合わせました。
serhio 2014

これは「1つ以上の共有ロックがすでに存在している場合、排他ロックを取得することはできません。」ですか。本当ですか?ReentrantReadWriteLock?書き込みロックはいつでも取得できると思いました。そうしないと、継続的な読み取りが原因で書き込みが不足する可能性があります。
Kanagavelu Sugumar 2016年

1
@KanagaveluSugumar、はい、それは本当です。別のエンティティがすでに同じオブジェクトに対して読み取りロックを保持している場合、単純に書き込みロックを取得することはできません。これが読み書きロックの要点です。誰かがそれを読んでいるときに何かを上書きした場合、彼らはそれから何を読みますか?「再入可能」読み取り/書き込みロックを具体的に選択した理由はわかりませんが、再入可能とは、再入可能ロックの所有者が再びロックし、その後のすべてのlock()呼び出しを「lock()」できることを意味します最初のものはすぐに正常に戻ります。つまり、すでに所有しているものを正常にロックできます。
ArjunShankar 2016年

2
また、「書き込みロックはいつでも取得できると思っていました。そうしないと、継続的な読み取りが原因で書き込みが不足する可能性があります」とも言われています。他のエンティティがすでに読み取り/書き込みロックを保持している間は、書き込みロックを取得できません。どのようなことができますが起こることは、複数のエンティティがすでにオブジェクトをロックするのを待っている場合、待機はということですwriter待っている読者よりも優先されたときにロックを取得したロックを選択した次の(それが現在の所有者によってロック解除された場合)。これは政策についてです。
ArjunShankar

ありがとうございました!私はReentrantReadWriteLockを選択しました。それは、JavaのReadWriteLockの実装クラスだからです。次に、書き込みスレッドが待機を開始したときに待機する、さらに新しい読み取りスレッドを示すためにフラグが立てられたり、優先度が設定されたりしていますか?継続的な読み取り要求による書き込みスレッドの枯渇を回避する方法は?
Kanagavelu Sugumar 2016年

33

とても簡単です。読み取りロックは、複数のプロセスが同時に読み取ることができるため、共有ロックとも呼ばれます。読み取りロックのポイントは、別のプロセスによる書き込みロックの取得を防ぐことです。対照的に、書き込みロックは、書き込み操作が完了するまで他のすべての操作を禁止します。

したがって、読み取りロックは「今は読み取ることができますが、書き込みたい場合は待機する必要があります」と表示し、書き込みロックは「待機する必要がある」と表示します。


あなたはあなたの研究を支援するために研究していると思いますが、講義をしたいという衝動には抵抗できません。

ロックの無能な使用は、パフォーマンスの頭痛の主な原因です。読み取りロックと書き込みロックを区別するロックシステムの使用は良い出発点ですが、注意深く設計することで、ロックする必要性の多くを排除できる場合があります。たとえば、セッション状態は、状態の要素ごとに1つのグローバルコレクションに保持されるべきでありませ

私は実際にこれが行われたのを見てきました。これはひどい設計であり、セッション状態が最後に変更されるたびにボクシングとコレクションへの変更を引き起こし、長時間の書き込みロックを伴います。オーバーヘッドは不自由で、サーバーをシングルスレッドの動作に効果的に減らしました。

すべてのセッション状態を構造体に単純に集約することは、大きな改善でした。セッション状態の変更は、セッション状態構造体のメンバーの値を変更しただけです。他のセッションにはセッションの状態を直接参照する機会または機会さえなかったので、更新されている唯一のコレクションはセッションのリストでした。その結果、セッション中にロックは完全に不要なり、開始時と終了時のみになり、スループットは3000倍に増加しました。

他の一般的なロックシナリオは、ユーザーアプリケーションのスレッド間で共有されるリソースです。最近のほとんどのフレームワークは、ロックではなくメッセージを使用してこれに対処しています。「UIスレッドに遷移する」ときは、実際には、関数ポインターといくつかのパラメーター(または実装に応じてデリゲートとスタックフレーム)を含むメッセージをキューイングしています。


6
  • 排他的ロックまたは書き込みロックは、ファイルの指定された部分に書き込むためのプロセスの排他的アクセスを提供します。書き込みロックが設定されている間、他のプロセスはファイルのその部分をロックできません。

  • 共有ロックまたは読み取りロックは、他のプロセスがファイルの指定された部分に書き込みロックを要求することを禁止します。ただし、他のプロセスは読み取りロックを要求できます。

詳細:http : //www.gnu.org/software/libc/manual/html_node/File-Locks.html


2

原則はデータベース側でも同じです。Oracleのドキュメントに従って

排他ロックモードは、関連するリソースが共有されないようにします。このロックモードは、データを変更するために取得されます。リソースを排他的にロックする最初のトランザクションは、排他ロックが解放されるまでリソースを変更できる唯一のトランザクションです。

共有ロックモードでは、関連する操作に応じて、関連するリソースを共有できます。データを読み取る複数のユーザーがデータを共有し、共有ロックを保持して、ライター(排他ロックが必要)による同時アクセスを防止します。複数のトランザクションが
同じリソースの共有ロックを取得できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.