MW211 EXIT

devlog
設計/排他制御
2014年09月09日
ロック(排他制御)には以下の種類がある
  ①参照用共有ロック
  ②更新用共有ロック(楽観的ロック)
  ③更新用占有ロック(悲観的ロック)

参照の場合、他に影響を与えないから基本的にロックの必要はない。
但し、他が更新中の場合は、そちらを優先させなきゃならないので
その手続きとして「共有ロック」を行う。
「共有ロック」は、「共有ロック」同士(同時に参照のみ)なら排他なし、
他方が「占有ロック」ならその完了を待つことになる。
(逆に「占有ロック」しようという方は、本「共有ロック」の解除を待つ必要がある)
だから「共有ロック」とは、「ロック」とはいうものの実際には「ロック」はせず
他ロックのお伺いを立てる手続きのことといえる。

更新の場合、他に影響が大なので、占有する必要がある。
ということで、「占有ロック」を行う。
「占有ロック」は、「占有ロック」だろうが「共有ロック」だろうが
他でロックをしている場合はその完了を待たねばならない一方、
自分がロックしている間は他が待ちとなる強力なロックだ。
(後述の「楽観的ロック」との対比から「悲観的ロック」とも言われる)

ところで、更新の場合にもう少し穏便にロックできないものかという考えがある。
大々的に「占有ロック」をすると他から苦情が来るので
「占有ロック」なんかしないで、こっそり更新してしまいたいという場合だ。
そもそもなんでロックが必要かというと更新する対象を一旦参照するけど
それが更新前に誰かに変更されるとおかしくなっちゃうので、
その期間をまるごと占有しなければならないからだ。
だったら、更新時に誰かに変更されていたのをみつけたら
やり直してしまえばロックする必要がないじゃんというのが、
「楽観的ロック」の発想。
自分の優先度を下げる控えめなロックなため、他が他がと更新されまくると
なかなか更新できないという欠点は持つけれど。
一応、参照時には他の参照と同様に「共有ロック」はかけるので
「共有ロック」の分類に属する。
但し、更新処理時(最後の一瞬)は、さすがに排他制御かけなきゃなんないので
実際は「排他ロック」を行っている。
(但し、割合が低いので「共有ロック」が前面に出る感じ)
分類:設計