Optimistic and Pessimistic Concurrency Control

• 並列制御

  • 楽観ロック

    • ロックしてねえじゃねえかってやつ

      • 言葉として便利だし、広まってしまったからしゃーない

  • 悲観ロック

    • ロックには2種類

      • 共有ロック

        • R
        • 他の誰にも専有ロックさせない

      • 専有ロック

        • R/W
        • 他の誰にも共有/専有ロックさせない

• コンフリクトがあまり起きず、起きたとしても重大にならないなら楽観ロックがよい

  • liveness稼げる
  • 実装らく

• コンフリクトが起きたが最後、マージが困難なら悲観ロック

  • ビジネスロジックのデータとか

• いずれの解決策を選んでも、問題から真に開放されるわけではない

  • 並列性の問題そのものと同じくらいの新たな問題

Preventing Inconsistent Reads

• 複数人で変更を加えて、それぞれはテストが通るが、合体すると壊れるやつ

  • 1人がクラスA,もう1人が依存先クラスBをいじるようなケース

• 本質的にはinconsistent read

  • 依存先クラスBの変更がチェックインされた時点で、クラスAをいじっている人から、変更後のクラスBが見えていない

• Pessimistic Lock

  • read(shared) lock
  • write(exclusive) lock
  • 誰かがread lockをかけていると、誰もwrite lockできない
  • 誰かがwrite lockをかけていると、誰もいかなる種類のlockもできない
  • コンフリクトを未然に防ぐ

• Optimistic Lock

  • データにバージョンマーカーを含める

    • タイムスタンプ
    • 連番
  • コンフリクトを検出し、lost updateを防ぐ

• inconsistent readをなくすには

  • Optimistic Lockと同じことする

    • データの全ビットにマーカーをつける
    • 単に「読んでるだけ」で「使ってはいない」ファイルの仕分けが困難

  • Temporal Reads

    • タイムスタンプやimmutableなラベルをつけてデータを読み出す
    • その時点でのデータを取得できる
    • データソースは全バージョンを持たないといけない
    • CVSなどでは良い
    • DBではいささか高コスト

Deadlocks

• 悲観ロックでおきるやつ

• どう対処する

  • 犠牲者をたてる

    • 誰かの変更を捨て、デッドロックを抜け出す

    • ロックにタイムリミットを設けるのもこれ

      • タイムリミットが切れた者が犠牲者

  • ロックの追加取得を禁止する

    • デッドロックは、そもそもロックを追加取得するせいでおきる
    • 最初に必要なロックを全部取得させて未然に防ぐ

  • ロックの取得順を強制する

    • 辞書順とか
    • これも未然に防ぐやつ

• 複数採用してよい

  • ベルトとサスペンダを両方着用するようなもの
  • だが、安全側に倒したほうが良い
  • デッドロック対策が漏れるよりよい