「4月1日に発生したJALのシステム障害は追加されたキャッシュの排他処理によるデッドロックが原因」記事へのコメント

キャッシュの排他制御機構？

[inuneko (4117)]

この場合のキャッシュの排他制御機構って何だろう。 良かれと思ってDogpile対策にStale Cache返却ロジックでも勝手にfcntl lockで組み込んだのかね？(勝手な想像)

Re:

[Anonymous Coward]

キャッシュと本物が互いの排他をとって互いに更新しようとしたんじゃない？

Re:

[Anonymous Crow (45505)]

前提
・キャッシュは、ほぼ読み込みのみ
・ディスクは、読み書きがある
・キャッシュとディスクはネットワーク上の別ノード

当初
・ディスクのみ排他処理アリ

パッチ後
・キャッシュ、ディスクともに「個々に」排他処理アリ

問題点
・トランザクション的に次の２パターンがあった
　1.キャッシュアクセス　→　ディスクアクセス
　2.ディスクアクセス　→　キャッシュアクセス
・キャッシュアクセス、ディスクアクセスで別々に排他処理をしていた

開けてみればシンプルなデッドロックではありますが・・・・

Re:キャッシュの排他制御機構？

[Anonymous Coward]

キャッシュとディスクで別々に排他処理してたなら

1 ロック(C)→キャッシュアクセス→アンロック(C)→ロック(D)→ディスクアクセス→アンロック(D)
2 ロック(D)→ディスクアクセス→アンロック(D)→ロック(C)→キャッシュアクセス→アンロック(C)

でデットロックしないと思うんだけど

1 ロック(C)→キャッシュアクセス→ロック(D)＜ここでデッドロック＞→ディスクアクセス→アンロック(D)→アンロック(C）
2 ロック(D)→ディスクアクセス→ロック(C)＜ここでデッドロック＞→キャッシュアクセス→アンロック(C)→アンロック(D)

みたいに、キャッシュアクセスの中でディスクアクセス（およびその逆）があるならなら解るんだけど

Re:

[Anonymous Coward]

ディスクとキャッシュで同じはずの値を格納している変数にアクセスして比較するわけだから、アクセス中にディスクの値が変わってしまうと意味がないんだと思う。

つまり、元々

2. ロック(D)→アクセス(D)→アクセス(C)→アンロック(D)

だったんじゃないかな。

ここでキャッシュのロックを実装してしまうと
「アクセス(C)」の部分が「ロック(C)→アクセス(C)→アンロック(C)」に置き換わるわけだから、

2. ロック(D)→アクセス(D)→ロック(C)→アクセス(C)→アンロック(C)→アンロック(D)

になるのが自然だと思う。