回答:
これは楽しい(そしてふさわしい)類推だと思ったので、この回答を書き留めました。
ロック可能なオブジェクトは、教師(ライター)と多くの学生(リーダー)がいるクラスルームの黒板(ロック可能)と考えてください。
教師がボードに何か(排他ロック)を書き込んでいる間:
まだ書き込み中であり、ビューをブロックしているため、誰もそれを読み取ることができません => オブジェクトが排他的にロックされている場合、共有ロックは取得できません。
他の教師が立ち上がらず、書き込みも開始されないか、ボードが読めなくなり、学生を混乱させる=> オブジェクトが排他的にロックされている場合、他の排他的ロックは取得できません。
生徒がボード上にあるものを読んでいるとき(共有ロック):
彼らはすべて一緒にその上にあるものを読むことができます=> 複数の共有ロックが共存できます。
教師は、ボードをクリアしてさらに書き込みを行う前に、それらが読み終わるのを待ちます=> 1つ以上の共有ロックがすでに存在する場合、排他ロックを取得できません。
lock()
呼び出しを「lock()」できることを意味します最初のものはすぐに正常に戻ります。つまり、すでに所有しているものを正常にロックできます。
writer
待っている読者よりも優先されたときにロックを取得したロックを選択した次の(それが現在の所有者によってロック解除された場合)。これは政策についてです。
とても簡単です。読み取りロックは、複数のプロセスが同時に読み取ることができるため、共有ロックとも呼ばれます。読み取りロックのポイントは、別のプロセスによる書き込みロックの取得を防ぐことです。対照的に、書き込みロックは、書き込み操作が完了するまで他のすべての操作を禁止します。
したがって、読み取りロックは「今は読み取ることができますが、書き込みたい場合は待機する必要があります」と表示し、書き込みロックは「待機する必要がある」と表示します。
あなたはあなたの研究を支援するために研究していると思いますが、講義をしたいという衝動には抵抗できません。
ロックの無能な使用は、パフォーマンスの頭痛の主な原因です。読み取りロックと書き込みロックを区別するロックシステムの使用は良い出発点ですが、注意深く設計することで、ロックする必要性の多くを排除できる場合があります。たとえば、セッション状態は、状態の要素ごとに1つのグローバルコレクションに保持されるべきではありません。
私は実際にこれが行われたのを見てきました。これはひどい設計であり、セッション状態が最後に変更されるたびにボクシングとコレクションへの変更を引き起こし、長時間の書き込みロックを伴います。オーバーヘッドは不自由で、サーバーをシングルスレッドの動作に効果的に減らしました。
すべてのセッション状態を構造体に単純に集約することは、大きな改善でした。セッション状態の変更は、セッション状態構造体のメンバーの値を変更しただけです。他のセッションにはセッションの状態を直接参照する機会または機会さえなかったので、更新されている唯一のコレクションはセッションのリストでした。その結果、セッション中にロックは完全に不要になり、開始時と終了時のみになり、スループットは3000倍に増加しました。
他の一般的なロックシナリオは、ユーザーアプリケーションのスレッド間で共有されるリソースです。最近のほとんどのフレームワークは、ロックではなくメッセージを使用してこれに対処しています。「UIスレッドに遷移する」ときは、実際には、関数ポインターといくつかのパラメーター(または実装に応じてデリゲートとスタックフレーム)を含むメッセージをキューイングしています。
排他的ロックまたは書き込みロックは、ファイルの指定された部分に書き込むためのプロセスの排他的アクセスを提供します。書き込みロックが設定されている間、他のプロセスはファイルのその部分をロックできません。
共有ロックまたは読み取りロックは、他のプロセスがファイルの指定された部分に書き込みロックを要求することを禁止します。ただし、他のプロセスは読み取りロックを要求できます。
詳細:http : //www.gnu.org/software/libc/manual/html_node/File-Locks.html
原則はデータベース側でも同じです。Oracleのドキュメントに従って
排他ロックモードは、関連するリソースが共有されないようにします。このロックモードは、データを変更するために取得されます。リソースを排他的にロックする最初のトランザクションは、排他ロックが解放されるまでリソースを変更できる唯一のトランザクションです。
共有ロックモードでは、関連する操作に応じて、関連するリソースを共有できます。データを読み取る複数のユーザーがデータを共有し、共有ロックを保持して、ライター(排他ロックが必要)による同時アクセスを防止します。複数のトランザクションが
同じリソースの共有ロックを取得できます。