排他処理

複数のプログラムが1つのファイルに同時に書き込みを行なうと整合性が取れなくなる。たとえば，あるファイルに書かれている数値を 1だけ増やすプログラムを2つ走らせたとする。最初，ファイルの内容が

だったとして，1増やすプログラムを2回動かすと中味は12になるはずである。しかしほぼ同時にプログラムを動かすと以下のようになる。

時刻	プログラムその1の流れ↓	プログラムその2の流れ↓
0ms	起動開始
10ms	元ファイルを開く	起動開始
20ms	10を読み取る	元ファイルを開く
30ms	変数に1を足す	10を読み取る
40ms	ファイルに書き込む	変数に1を足す
50ms	終了	ファイルに書き込む
60ms		終了

結果は11になる。

このように，あるファイルの中味を読み取りなんらかの修正を加えるプログラムは，同じプログラムが同時進行している可能性を考慮し，

他のプロセスがそのファイルを処理しているときはそれが終わるまで待つ
自プロセスがファイルをopenしている時間を極力短くする

のような注意を払う必要がある。

同時に2つのプロセスが同じ処理を行なわないようにすることを 排他処理 という。ファイル修正の排他処理には ファイルロックが用いられる。

Rubyにおけるファイルロック

Rubyでは Fileクラスの flockメソッドでロックを行なう。

まず，ファイルロックのないまずい処理例を示す。先に用いた dbm-ops.rb プログラムを同時に動かす実験をしてみる。

ktermその1

./dbm-ops.rb -a
あいうえお,12345
[C-d]

ktermその2

./dbm-ops.rb -a
かきくけこ,abcde
[C-d]

両プログラムを起動してから，各ウィンドウでデータ入力を行ないC-d をタイプする。すると，あとで終わらせた方のデータしか追加されていないことが分かる。

ファイルロック処理を追加してみる。ロックの必要な処理の前にロック設定処理を，後ろにロック解除処理を入れる。

lockfile="ロックファイルの名前"
open(lockfile, "w") do |lf|
  lf.flock(File::LOCK_EX)    # ロック設定
  DBM.open(datafile) do |x|
      :
  end
  lf.flock(File::LOCK_UN)    # ロック解除
end

→ dbm-flock.rb

ktermその1
先に起動する

./dbm-flock.rb -a
./database operation start
いろはにほへと,12345
[C-d]

ktermその2
その1を終わらせる前に起動する

./dbm-flock.rb -a
あたらしい朝,いえーい
[C-d]
./database operation start
(その1終了後処理が始まる)

このプログラムではflockを行なうファイルとしてダミーファイルを openしたが，これは排他処理を行なう必要のあるファイル形式がdbmだからで，普通にopenして修正を行なうファイルの排他処理を行なうなら，そのファイルをopenしたオブジェクトでflockすればよい。

PStoreはtransactionブロックそのものが排他処理を行なう。

flockの注意

先述のとおりflock処理は極力短くする。さもなくばロック解除待ちのプロセスが溢れかえる。dbm-flock.rb は，新規データの入力処理もロック内で行なっているので，入力に時間がかかる場合でもずっとロックがかかったままとなる。データベース更新処理のみをロックするように書き換える。データを追加する部分だけを抜き出したプログラム dbm-add-flock.rb を示す。

#!/usr/bin/env ruby
require 'dbm'                   # dbmクラスを利用
datafile = "./database"         # データベースファイル名
lockfile = datafile+".lck"      # ロックファイル名

data = Hash.new
while csv=gets                  # 先にCSVデータを読んでハッシュに代入
  if /([^,]*),(.*)/ =~ csv
    data[$1] = $2
  end
end

open(lockfile, "w") do |lf|
  lf.flock(File::LOCK_EX)
  DBM.open(datafile) do |x|
    STDERR.puts "#{datafile} update starts."
    for key, val in data
      x[key] = val
    end
    sleep 2                     # 本当は一瞬で終わるが少し時間を掛ける
    STDERR.puts "#{datafile} update ends."
  end
  lf.flock(File::LOCK_UN)
end

排他処理の必要なファイルを修正する場合は File::LOCK_EX (排他ロック)を指定するが，読み取りのみの場合は File::LOCK_SH(共有ロック) を指定する。

デッドロック

複数のプロセスが互いに別プロセスのロック解除を待ち続けて永遠に解除が起きない状態を デッドロック という。

たとえば，2つのファイル A と B があり，それぞれに数値が書かれていたとする。このとき

プロセス1 → 「Aファイルの値+1」をBに書き込む
プロセス2 → 「Bファイルの値+1」をAに書き込む

という2つのプロセスがほぼ同時に走ったとする。プロセス1は「AをロックしてからBをロック」し。プロセス2は「BをロックしてからAをロック」しようとしたとする。もし，「プロセス1がAをだけをロック，プロセス2がBだけをロック」した状態になったら，この状態は永遠に解除されない。

この例の場合，デッドロックを回避するには複数の資源をロックする順位を決めておく。AとBであれば，A→Bという順番でのみロックするように設計する。

一般的には，ロックすべき資源は多数あるのでロックを完ぺきに解除するのは難しい。全体的に可能性を極力下げるよう設計する。

複数資源を同時にロックしない
同時ロックが必要なら順番を決める
ロックしている時間が最短になるよう工夫する

これらを注意するのと同時に，デッドロック回避が本質的に難しいことを考慮して，

ロックしなくていいアルゴリズムに変える
- レコードごとにファイルを分けたりファイルの存在そのものをレコードとして利用する
- 同時アクセスが起きたらエラーにしてよい処理はエラーにする
デッドロックが起きた場合のエラー処理を作り込んでおく
- 時間を置いてリトライ
- タイムアウトを決めてabort

などをしておく。

本日の目次へ

yuuji@e.koeki-u.ac.jp