読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

4.7 ロックマネージャー: Lock #read_aosa

読書ノート

Berkeley DBの続き

ファイル→ページ→レコードという階層構造が存在する

  • Mpoolと同様、ロックマネージャーも汎用コンポーネントとして作られた
  • Mpoolの場合と同様、他のアプリケーションからもまったく違う方法でロックマネージャーを使えるという点が重要

ロックマネージャを理解する上で重要な概念

  1. ロッカー(誰がロックを獲得したのか)
  2. ロックオブジェクト(ロックされている項目)
  3. 衝突マトリクス(ちょっと何言ってるかわからないけど後述)

ロッカー

  • ロッカーは32ビット符号なし整数
  • Lockers are 32-bit unsigned integers. Berkeley DB divides this 32-bit name space into transactional and non-transactional lockers (although that distinction is transparent to the lock manager).
  • この32ビットの名前空間(に)トランザクショナルなロッカーと非トランザクショナルなロッカーの二つに分割する
  • オレオレルール
  • 非トランザクショナル 長期間の読み込みロックの確保

ロックオブジェクト

  • 任意な長さの不透明(opaque)なバイト文字列(何を隠しているのかよくわからない)

二つの異なるロッカーが特定のオブジェクトをロックしようとしたときは、どちらも同じバイト文字列でそのオブジェクトを表す。つまり、オブジェクトを不透明なバイト文字列で表すときの規約についてはアプリケーション側で決めておく必要がある

  • ID ページ番号 型の構造体

ほとんどの場合、Berkeley DBで表す必要があるのはロックしたい特定のファイルやページだけ

opaque

インターフェース上で未定義のデータ型をopaque data type(不透明型)と呼び、そのような型を指すポインタをOpaqueポインタと呼びます Opaqueポインタについて - white wheelsのメモ

相互参照の問題を回避するために、Opaque型を利用する。中身がなんだかわからないけど定義されているもの

C言語とかC++とかでアレされているやつ

設計講座9

ページレベルのロックはアプリケーションの同時実行性を制限してしまう。ある制御スレッドがデータベースのレコードを変更すると、他のスレッドからは同じページにあるそれ以外のレコードを変更できなくなる。一方レコードレベルのロックなら、全く同じレコードを変更しようとしない限りはそんな制限を受けない。ページレベルのロックをすれば安定性が向上する

小規模な組み込みを想定している

衝突マトリクス

システム内に存在するさまざまな型のロックとその相互作用について定義 ロックを保持するエンティティを「ホルダー」、ロックを要求するエンティティを「リクエスター」

わかりづらいけど✓はNGを意味する

リクエスター/ホルダー No-Lock Read Write Wait iWrite iRead iRW uRead wasWrite
No-Lock
Read
Write
Wait
iWrite
iRead
iRW
uRead
iwasWrite

階層化ロックのサポート

階層化ロックとは、さまざまな項目を階層を保ったままロックすること

ページをロックしたらファイルもまるごとロックする

あるページをロックするということは、ファイルをロックするということでもあるからだ。あるページが変更されているとき、そのページを含むファイルを同時に変更することはできない

って書いてあるけど、ページをロックしたら自動的にファイルもロックするのか(インテンションロックも含んでいるのか)

iはインテンションの意

あるロッカーがコンテナに対するインテンションロックを獲得すると、そのコンテナの中身に対してもロックする意図があるということを表す iRead、iWrite、そしてiWRはすべてインテンションロックであり、それぞれ読み込み、書き込み、その両方に対する意図を指す

エンティティは要素、モノの意

ロックを結合するときには、ひとつのロックを保持するのは次のロックを獲得するまでの間となる。つまり、内部のBtreeページをロックするのは、次のレベルのページを選んでロックするための情報を読み込むまでの間である

設計講座10

汎用性重視の設計にしておいたことが、並列データ格納機能を追加するときに役立った

#

File←iwrite データ←write

より荒い粒度に対する要求なので許される