Community Blog

/proc/locks

Linuxでは、現在システム内に存在する全ファイルロックを/proc/locksから確認でき、獲得済みファイルロックの

• ロック種類（FLOCK/POSIX/OFDLCK、ADVISORY/MANDATORY/MSNFS、READ/WRITE/RW/NONE/UNLCK）
• プロセスID
• ファイル情報（デバイス番号、inode番号）
• ファイル内のロック範囲

が得られます。獲得待ちのロック要求も確認でき、この場合はロック種類の冒頭に->が付加されます。

/proc/locksの例

1: POSIX  ADVISORY  WRITE 11636 08:11:205 0 EOF
1: -> POSIX  ADVISORY  READ  11640 08:11:205 0 EOF
2: FLOCK  ADVISORY  WRITE 2437 00:0c:5305 0 EOF
3: POSIX  ADVISORY  READ  2229 00:0c:4290 4 4
    :

2プロセス間の排他制御

排他ロック（ライトロック）の場合、一般に期待されるのは（アプリケーションが定めたロック作法に従う）他プロセスをブロックさせる動作です。簡単に確認できる動作ですが、単純なテストプログラムを付属ソースファイル一式に含めておきます（sibling.c）。これは兄弟プロセス（すなわち継承などの関連性を持たない二プロセス）で同じファイルをロックし、相手プロセスがファイルロックを保持している限り、自プロセスはロックを獲得できないことを確認するプログラムです。/* do something */の部分は、本来ならばファイルI/Oを実行しますが、テストプログラムでは単にスリープすることにしました。

兄弟プロセスによる同一ファイルのロック――sibling.c（抜粋）

#include "libtp.h"

struct lock_ops *ops;

static void lock_it(char *fname)
{
            :
        fd = open_and_pat(fname, O_RDWR, pat, sizeof(pat));
                                                        ファイルオープン
        err = ops->lock(fd, NULL);                      ファイルロック

        /* do something */
        sleep(1);
        GREP_LOCK(pat);                                 /proc/locksを確認

        err = ops->unlock(fd, NULL);                    アンロック
            :
}

int main(int argc, char *argv[])
{
            :
        fname = argv[1];
        method = argv[2];
        ops = lock_ops(method);

        for (i = 0; i < 2; i++) {
                pid[i] = fork();
                if (!pid[i]) {
                        lock_it(fname);                 2つの子プロセスで実行
                        exit(0);
                }
        }
            :
}

sibling.cにはコマンドラインパラメータを2つ与えます。ロックするファイル名と、flock(2)とPOSIXロックのどちらを使用するかを表す文字列です。また、本記事用の自作ライブラリを使用しているので簡単に補足します。

int open_and_pat(char *fname, int flags, char pat[], int n)

ファイルをオープンし、ファイルディスクリプタを返す。また、そのファイルを表すデバイス番号、inode番号の文字列を生成し、patへ代入する。この文字列を/proc/locks内の検索に使用する。

void GREP_LOCK(char *pat)

ファイルを表すデバイス番号、inode番号の文字列を受け取り、/proc/locks内を検索し、その結果を表示する。

struct lock_ops *lock_ops(char *str)

与えられた文字列から、flock(2)とfcntl(2)のインタフェースの差異を吸収する簡易抽象化構造体を返す。

struct lock_ops {
    int (*lock)(int fd, char *prefix);
    int (*unlock)(int fd, char *prefix);
};

引数strに"bsd"、"flock"のいずれかを渡せば、flock(2)の単純ラッパ関数をメンバに持つstruct lock_opsを指すポインタを返す。POSIXロック（fcntl(2)）を指定する場合は"posix"または"setlkw"を与える。"fcntl"と指定しても良いが、後述するOFDロックと区別しにくくなるため、記事内に提示するサンプルプログラムの実行例では使用しない。

sibling.cは期待通りの実行結果を示します。2プロセスが同じファイルに対しロックを試み、先にファイルロックを獲得したプロセスが明示的にアンロックするまで、後のプロセスはロックを獲得できず待たされます。flock(2)でもPOSIXロックでも同じように動作することが確認できます。

sibling.cの実行結果

/tmp/testfile is (dev 0806, inum 11)                    対象ファイルは dev=08:06, inum=11

$ ./sibling /tmp/testfile flock
pid 2831 is wanting ...
pid 2831 acquired flock                                 先のプロセスがロック獲得
pid 2832 is wanting ...                                 後のプロセスはロック解放待ち
lock_it:28: 1: FLOCK  ADVISORY  WRITE 2831 08:06:11 0 EOF
lock_it:28: 1: -> FLOCK  ADVISORY  WRITE 2832 08:06:11 0 EOF
pid 2831 releases                                       先のプロセスがロック解放
pid 2832 acquired flock                                 後のプロセスがロック獲得
lock_it:28: 2: FLOCK  ADVISORY  WRITE 2832 08:06:11 0 EOF
pid 2832 releases

$ ./sibling /tmp/testfile posix
pid 2834 is wanting ...
pid 2834 acquired posix
pid 2835 is wanting ...
lock_it:28: 1: POSIX  ADVISORY  WRITE 2834 08:06:11 0 EOF
lock_it:28: 1: -> POSIX  ADVISORY  WRITE 2835 08:06:11 0 EOF
pid 2834 releases
pid 2835 acquired posix
lock_it:28: 2: POSIX  ADVISORY  WRITE 2835 08:06:11 0 EOF
pid 2835 releases

1プロセスでのデッドロック？

では次に兄弟プロセスではなく、単一プロセスで同じファイルを二度オープンし、2つのfdに対し順次排他ロック（ライトロック）する場合を考えてみましょう。すでにロックを獲得しているならば、二度目のファイルロックで自らデッドロックするように思えますが、実際にそうなるでしょうか？

1プロセスによる同一ファイルに対する2fdのロック――two-opens.c（抜粋）

struct lock_ops *ops;
char pat[16];

static int lock_it(char *fname)
{
            :
        fd = open_and_pat(fname, O_RDWR, pat, sizeof(pat));
        snprintf(a, sizeof(a), "fd %d", fd);
        err = ops->lock(fd, a);
            :
}

int main(int argc, char *argv[])
{
            :
        fname = argv[1];
        method = argv[2];
        ops = lock_ops(method);

        for (i = 0; i < 2; i++)
                fd[i] = lock_it(fname);                 子プロセスを作成せず二度実行
        GREP_LOCK(pat);
            :
}

two-opens.cの実行結果

$ ./two-opens /tmp/testfile flock none
fd 3 pid 2839 is wanting ...
fd 3 pid 2839 acquired flock
fd 4 pid 2839 is wanting ...                            後のロックが先のロックの解放待ち
                                                        デッドロック
$ fgrep -Hw 2839 /proc/locks
/proc/locks:1: FLOCK  ADVISORY  WRITE 2839 08:06:11 0 EOF
/proc/locks:1: -> FLOCK  ADVISORY  WRITE 2839 08:06:11 0 EOF
                                                        自プロセスは処理を進められない
                                                        ため先のロックを解放できない

$ ./two-opens /tmp/testfile posix none
fd 3 pid 2842 is wanting ...
fd 3 pid 2842 acquired posix
fd 4 pid 2842 is wanting ...
fd 4 pid 2842 acquired posix                            2つのロックがともに成功
main:50: 1: POSIX  ADVISORY  WRITE 2842 08:06:11 0 EOF  実際に獲得したロックはひとつ

例にはアンロック処理を含めてありませんが、付属ソースコード一式にあるtwo-opens.cではアンロック/クローズ処理も実装してあります。上記実行例にある"none" はアンロック、クローズいずれも実行しない指定です。

実際に試してみると、flock(2)は予想通りデッドロックするのに対し（もちろんノンブロッキングモードを使用しない場合）、POSIXロックは二度目のロックも成功します。同一ファイルの同一バイト範囲に対するPOSIXロックのライトロック（F_WRLCK）が同時に複数存在することはあり得ません。この場合は、同一プロセスが同じPOSIXロックを獲得しようとしても何も変わらず、エラーにもならないと仕様として定められています。二度ロックしたと言っても存在しているロックはひとつのため、一度のアンロック操作でロックは解放されます。では、二度目のアンロックはエラーになるのかと言うとそうでもなく、POSIXロックのアンロックは常に成功する仕様です。すなわち、一度目のアンロックは期待通りロックを解除後成功を返し、二度目のアンロックは何もしないままやはり成功を返しエラーにはなりません。

同一fdでのデッドロック？

two-opens.cを変形させてもうひとつ例を挙げます。two-opens.cでは同じファイルを二度オープンし、2つのfdに対しロック操作を実行しましたが、今度は同じfdを二度ロックしてみます。やはり排他ロック（ライトロック）ですので、通常ならば自らデッドロックするような動作に思えます。

1プロセスによる同一fdに対するロック――one-open.c（抜粋）

    :
fname = argv[1];
fd = open_and_pat(fname, O_RDWR, pat, sizeof(pat));
method = argv[2];                               オープンは一度
ops = lock_ops(method);

for (i = 0; i < 2; i++) {
        err = ops->lock(fd, NULL);              同一fdを二度ロック
        GREP_LOCK(pat);
}
    :

one-open.cの実行結果

$ ./one-open /tmp/testfile flock
pid 2860 is wanting ...
pid 2860 acquired flock
main:25: 1: FLOCK  ADVISORY  WRITE 2860 08:06:11 0 EOF
pid 2860 is wanting ...
pid 2860 acquired flock
main:25: 1: FLOCK  ADVISORY  WRITE 2860 08:06:11 0 EOF

$ ./one-open /tmp/testfile posix
pid 2861 is wanting ...
pid 2861 acquired posix
main:25: 1: POSIX  ADVISORY  WRITE 2861 08:06:11 0 EOF
pid 2861 is wanting ...
pid 2861 acquired posix
main:25: 1: POSIX  ADVISORY  WRITE 2861 08:06:11 0 EOF

one-open.cを実際に試してみると、flock(2)もPOSIXロックもデッドロックせず、二回のロックに成功します。POSIXロックの方は先のtwo-opens.cの例から仕様としてエラーにならない動作を理解できますが、flock(2)の方は何故でしょう。対象ファイルは同じなのですし、two-opens.cとの動作の違いの原因として考えられるものはfdしかありません。

整理のため、ここまでの内容を簡単に表にまとめておきます。

表1:各テストプログラムの動作

flock(2)

two-opens.cとone-open.cのflock(2)の動作の違いは、、fdが意味するOFD（オープンファイル情報）が大きな役割を果たしており、すなわちflock(2)のロックはOFDに対応します。OFD自体が「自分が表すファイルを、このプロセスがロックしている」という情報を持つわけではなく、別途カーネル内に作成されたファイルロックを表す構造体との対応関係が作成されます（俗に言う紐付け）。同一プロセスが同一対象に対し同一ロックを実行しても、POSIXロック同様にflock(2)でもデッドロックしません。ここで同一対象と判断する根拠がflock(2)ではOFDです。複製ではないfdの場合は（先に挙げたtwo-opens.c）、OFDが異なるため同一対象と判断されず別ロックとみなされ、その結果デッドロックします。

OFDとの対応関係を判断するflock(2)の動作を、別のテストプログラムから確認してみましょう。

    ：
fname = argv[1];
method = argv[2];
ops = lock_ops(method);
p = argv[3];
if (!strcmp(p, "unlock"))
        do_close = 0;
else if (!strcmp(p, "close"))
        do_close = 1;

fd[0] = open_and_pat(fname, O_RDWR, pat, sizeof(pat));
printf("got fd %d\n", fd[0]);
fd[1] = dup(fd[0]);                             fdを複製
printf("got fd %d\n", fd[1]);

snprintf(a, sizeof(a), "fd %d", fd[0]);
err = ops->lock(fd[0], a);                      元のfdをロック
GREP_LOCK(pat);

snprintf(a, sizeof(a), "fd %d", fd[1]);
if (do_close) {
        printf("%s closes\n", a);
        err = close(fd[1]);                     複製したfdをクローズ
} else
        err = ops->unlock(fd[1], a);            複製したfdをアンロック
GREP_LOCK(pat);
    ：

$ ./flock-dup /tmp/testfile flock unlock
got fd 3
got fd 4
fd 3 pid 2863 is wanting ...
fd 3 pid 2863 acquired flock
main:39: 1: FLOCK  ADVISORY  WRITE 2863 08:06:11 0 EOF  元のfdのロックを獲得
fd 4 pid 2863 releases                                  複製したfdをアンロック
main:48: pid 2863 has no locks on 08:06:11              元のfdのロックが解放される

$ ./flock-dup /tmp/testfile flock close
got fd 3
got fd 4
fd 3 pid 2864 is wanting ...
fd 3 pid 2864 acquired flock
main:39: 1: FLOCK  ADVISORY  WRITE 2864 08:06:11 0 EOF  元のfdのロックを獲得
fd 4 closes                                             複製したfdをクローズ
main:48: 1: FLOCK  ADVISORY  WRITE 2864 08:06:11 0 EOF  元のfdのロックは維持される

    :
fname = argv[1];
method = argv[2];
ops = lock_ops(method);
p = argv[3];
if (!strcmp(p, "unlock"))
        do_close = 0;
else if (!strcmp(p, "close"))
        do_close = 1;

fd = open_and_pat(fname, O_RDWR, pat, sizeof(pat));
err = ops->lock(fd, NULL);                      親プロセスがロック
GREP_LOCK(pat);

pid = fork();                                   子プロセスの作成
if (!pid) {
        if (do_close) {
                printf("pid %d closes\n", getpid());
                err = close(fd);                子プロセスがクローズ
        } else
                err = ops->unlock(fd, NULL);    子プロセスがアンロック
        exit(0);
} else
        wait(NULL);
GREP_LOCK(pat);
    :

$ ./flock-fork /tmp/testfile flock unlock
pid 2869 is wanting ...
pid 2869 acquired flock
main:36: 2: FLOCK  ADVISORY  WRITE 2869 08:06:11 0 EOF  親プロセスがロック
pid 2870 releases                                       子プロセスがアンロック
main:50: pid 2869 has no locks on 08:06:11              ロックが解放される

$ ./flock-fork /tmp/testfile flock close
pid 2871 is wanting ...
pid 2871 acquired flock
main:36: 1: FLOCK  ADVISORY  WRITE 2871 08:06:11 0 EOF  親プロセスがロック
pid 2872 closes                                         子プロセスがクローズ
main:50: 1: FLOCK  ADVISORY  WRITE 2871 08:06:11 0 EOF  ロックは維持される

ファイルロックとプロセスID

本記事を執筆中にOpenVZプロジェクト、CRIUプロジェクト（Checkpoint/Restore in Userspace、クリウ）のコアメンバがLKMLへこんな問題と改造パッチ案を投げかけました。曰く、

• /proc/locksのPIDの欄に表示されるflock(2)のプロセスIDが正確ではない。
• flock(2)のロックは継承されるため、ロックを獲得した親プロセスがfork(2)後にファイルをクローズした、親プロセスが終了したなどの場合に発生する。すなわち、/proc/locksに親プロセスIDが表示されたままだが、実際にファイルロックを保持しているのは子プロセスである。
• 現状の/proc/locks からでは、実際にファイルロックを保持しているプロセスを特定できない。
• flock(2)にLOCK_TESTフラグを新規に設けたい。このフラグにより、指定した種類のロックが対象ファイルに設定されているか否かを調べる。

LKML上ではちょっとよく分からないという反応があったため、具体例を挙げた補足も投稿されました。

• LOCK_EX（排他ロック）の場合はまだ良い。次の例では子プロセスのみがファイルロックを獲得している。この場合は親プロセス、子プロセスそれぞれでflock(LOCK_EX)を試み、成功した子プロセスのみがすでにロックを獲得していると判断できる。

pid = fork();
fd = open("/foo"); /* both parent and child has _different_ files */
if (pid == 0)
        /* child only */
        flock(fd, LOCK_EX);

• しかし、次のLOCK_SH（共有ロック）の例では

  1. /fooをオープンした親プロセス
  2. 子プロセス（最終的に終了している）
  3. 子プロセスからロックを継承した孫プロセス

の3プロセスがあり、ファイルロックを保持しているのは孫プロセスのみである。

pid = fork();
fd = open("/foo"); /* yet again -- two different files */
if (pid == 0) {
        flock(fd, LOCK_SH);
        pid2 = fork();
        if (pid2 != 0)
                exit(0);
}

この場合に/proc/locksが表示するプロセスIDはロックを設定した子プロセスのものであり、現在実際にロックを保持しているプロセスを特定する術がない。

• 先に挙げたflock(LOCK_EX)同様にflock(LOCK_SH)を試みても、親プロセスでも孫プロセスでも成功してしまうため、実際にロックを保持しているプロセスを特定できない。
• 仮に親プロセスと孫プロセスからflock(LOCK_EX)を試みると、孫プロセスのみが成功する。これで判断できるかと思いきや、もし他プロセスが/fooをLOCK_SHしていれば、どのプロセスからもflock(LOCK_EX)が成功せず、やはりプロセスの特定にはいたらない。

考えてみれば、POSIXロックにはロックを獲得せずにロックの存在を調べるF_GETLKがあるのに、flock(2)には相当する機能がありません。ここで提案されたLOCK_TESTはF_GETLKに相当すると言えます。

後述するOFDロックを実装した開発者もLOCK_TESTに賛同し、mainlineに実装される見込みが高くなりました。ただ、OFDロックもそうでしたが、このような新機能の追加はライブラリ（glibcプロジェクト）やマニュアルページ（man-pagesプロジェクト）も巻き込んで進めなければならず、LKML以外にも多くの人の賛同を得なければならないめ、時間は多少かかるかもしれません。

閑話休題：CRIUとfile handle

LOCK_TESTを提案したのはCRIUプロジェクトのコアメンバですが、筆者は最近CRIUに触れる機会があり初めて中を覗いてみました。すると、前記事「ファイルオープンと新フラグ」で採り上げたfile handleシステムコールを活用していることが分かり、意外な発見でした。Checkpoint/Restoreとは、てっきり従来からある、稼働中のシステムの全メモリをディスクへダンプするようなことだろうと勝手に想像していましたが、CRIUでは"in userspace"という名前が表すように別のアプローチを採っていました。

プロセスのファイルオープンの状態をダンプ（checkpoint作成）する処理で、/proc下から得たfile handleを保存し、その後のプロセスの状態を再現（restore）する処理では、open_by_handle_at(2)を用いファイルをオープンするアプローチと分かり、"in userspace"に納得してしまいました。カーネルにダンプ/リストアする機能を追加するのではなく、ユーザプロセスで必要な情報を得て処理するアプローチです（多くの情報を/procから得るようです）。すべてのオープンをfile handleのみで再現するわけではないようですが、カーネルメモリをダンプしないアプローチは注目に値すると思います。

従来のカーネルメモリをダンプするアプローチではデバッグ目的ばかりだったと思いますが、CRIUでは最近人気のDockerなどのコンテナを動作させたまま、ダンプし別環境で再現することで「移動」を実現する、時間のかかるシステム起動処理の完了時点の状態をダンプし、次回起動時には再現することで時間短縮を図るなどの用途も想定しているようです。

tmpfsなど一部のファイルシステムではfile handle（inode番号）の永続性を期待できず別途対応が必要だと思いますし、まだまだ実用化は不透明ですが、面白いアプローチだと思います。

POSIXロック

さて、flock(2)がOFDを基にロック対象が同一か否かを判断するのに対し、POSIXロックでは何を根拠に判断するのでしょうか？ 先に結論を言ってしまいますが、OFDではなく、プロセスID（およびinode）により判断しています。この動作を確認するには、先に挙げたtwo-opens.cを改造したtwo-opens-one-close.cが分かりやすいでしょう。

二度のオープンと一度のクローズ

同じファイルを二度オープンし（すなわち複製ではない）、POSIXロックによりひとつのfdをロック後、別fdをクローズしてみます。POSIXロックは影響を受けるでしょうか？一般的、感覚的には、fdが異なるという理由からPOSIXロックは影響を受けないことが期待されますが、その期待は裏切られます。

別fdのクローズによるPOSIXロックのアンロック――two-opens-one-close.c（抜粋）

    :
fname = argv[1];
method = argv[2];
ops = lock_ops(method);

for (i = 0; i < 2; i++)
        fd[i] = open_and_pat(fname, O_RDWR, pat, sizeof(pat));
                                                同じファイルを二度オープン
snprintf(a, sizeof(a), "fd %d", fd[0]);
err = ops->lock(fd[0], a);                      fd[0]をロック
GREP_LOCK(pat);

printf("fd %d closes\n", fd[1]);
close(fd[1]);                                   fd[1]をクローズ
GREP_LOCK(pat);
    :

two-opens-one-close.cの実行結果

$ ./two-opens-one-close /tmp/testfile posix
fd 3 pid 2882 is wanting ...
fd 3 pid 2882 acquired posix
main:30: 1: POSIX  ADVISORY  WRITE 2882 08:06:11 0 EOF  fd 3をロック
fd 4 closes                                             fd 4をクローズ
main:34: pid 2882 has no locks on 08:06:11              fd 3がアンロックされる

実行結果が示す通り、同じファイルをオープンしたfd 4をクローズしただけで、fd 3に対するPOSIXロックはアンロックされてしまいます。二度明示的にオープンしているのですからOFDは2つ存在しています。OFDが異なるにもかかわらず、POSIXロックはアンロックされる仕様です。

このPOSIXロックのアンロック動作は弊害が大きく、以前から問題視されてきました。例えば、コールしたライブラリ関数が内部で同じファイルをオープン/クローズしただけでも（すなわち別fd）、既に自プロセスが獲得済みのロックが意図せずアンロックされてしまう問題が起こります。もちろん逆の場合もあります。ライブラリ関数が内部でロックしておいても、自プロセス内のどこかでオープン/クローズすればやはり意図せずアンロックされてしまいます。同様に、オープン時にO_CLOEXECを指定したfdをロック後にexecした場合や、dup2(2)による間接的なファイルクローズでも予想外のアンロックが発生します。

また、fork(2)した場合では、OFDと対応関係を持つflock(2)のロックは自動的に子プロセスに継承されるのに対し、POSIXロックはOFDとの対応関係を持たないため継承されません。この動作もたびたび問題視されます。プログラマから見ればfdをロックしたという意識があり、子プロセスも同じfdを持っているのだからと考えてしまうためだと思います。

さらに、ややマイナになるかもしれませんが、マルチスレッド時に問題になることもあります。先に挙げたtwo-opens.cが示すように、同一プロセスからのPOSIXロックは複数回成功します。この動作ではスレッド間排他制御を実現できません。

参考のため、先に挙げたflock-dup.c、flock-fork.cでPOSIXロックを実行した例、およびtwo-opens-one-close.cでflock(2)を実行した例も挙げておきます。ロックに対応する情報は何かを意識しながら、動作の違いを見比べてください。

POSIXロックを指定したflock-dup.c、flock-fork.cの実行結果

$ ./flock-dup /tmp/testfile posix unlock
got fd 3
got fd 4
fd 3 pid 2358 is wanting ...
fd 3 pid 2358 acquired posix
main:39: 1: POSIX  ADVISORY  WRITE 2358 08:06:11 0 EOF  元のfdのロックを獲得
fd 4 pid 2358 releases                                  複製したfdをアンロック
main:48: pid 2358 has no locks on 08:06:11              元のfdのロックが解放される

$ ./flock-dup /tmp/testfile posix close
got fd 3
got fd 4
fd 3 pid 2359 is wanting ...
fd 3 pid 2359 acquired posix
main:39: 3: POSIX  ADVISORY  WRITE 2359 08:06:11 0 EOF  元のfdのロックを獲得
fd 4 closes                                             複製したfdをクローズ
main:48: pid 2359 has no locks on 08:06:11              元のfdのロックが解放される

$ ./flock-fork /tmp/testfile posix unlock
pid 2366 is wanting ...
pid 2366 acquired posix
main:36: 1: POSIX  ADVISORY  WRITE 2366 08:06:11 0 EOF  親プロセスがロック
pid 2367 releases                                       子プロセスがアンロック
main:50: 1: POSIX  ADVISORY  WRITE 2366 08:06:11 0 EOF  ロックは維持される

$ ./flock-fork /tmp/testfile posix close
pid 2368 is wanting ...
pid 2368 acquired posix
main:36: 3: POSIX  ADVISORY  WRITE 2368 08:06:11 0 EOF  親プロセスがロック
pid 2369 closes                                         子プロセスがクローズ
main:50: 3: POSIX  ADVISORY  WRITE 2368 08:06:11 0 EOF  ロックは維持される

flock(2)を指定したtwo-opens-one-close.cの実行結果

$ ./two-opens-one-close /tmp/testfile flock
fd 3 pid 2374 is wanting ...
fd 3 pid 2374 acquired flock
main:30: 1: FLOCK  ADVISORY  WRITE 2374 08:06:11 0 EOF  fd 3をロック
fd 4 closes                                             fd 4をクローズ
main:34: 1: FLOCK  ADVISORY  WRITE 2374 08:06:11 0 EOF  fd 3はアンロックされない

表2:各テストプログラムの動作（2）

本記事で取り上げなかったPOSIXロックの長所

ここまでの内容でPOSIXロックの方が劣るような印象を受けた方も居るかもしれません。動作に問題があるのはその通りですが、優れている点もあります。例えば、次の点があります。

• ロック範囲はファイル全体に限定されず、バイト単位で指定可能（このためレコードロックとも呼ばれる）。
• ロック種別（リードロック、ライトロック）をアトミックに変換可能。
• 上記二点から、既存ロックの一部分だけの種別変換も可能。例えば、広い範囲のライトロックの中間部分だけをリードロックに変換すると、ライトロック、リードロック、ライトロックの3つに分割される。
• デッドロック検知、回避機能を備える。
• POSIXにより標準化されている。

OFDロックの実行

OFDロック導入のために新たなシステムコールを新設したわけではなく、fcntl(2)にコマンドフラグを追加する形で実装されました。インタフェースはPOSIXロックと同様で、移行しやすいと思います。F_GETLK、F_SETLK、F_SETLKWそれぞれに対応するF_OFD_GETLK、F_OFD_SETLK、F_OFD_SETLKWを追加しただけのインタフェースです。ひとつだけ注意点があり、引数のstruct flockのl_pidはゼロで初期化しておく必要があります。また、POSIXロックが備えるデッドロック検知、回避機能は実装されていません。

それではこれまで使用したテストプログラムを改造し、新OFDロックの動作を確認してみます。すべて先に挙げたテストプログラムですので、flock(2)、POSIXロックでの結果と見比べてみてください。

本記事用に自作したライブラリはOFDロックにも対応していますので、すべてのテストプログラムでflock(2)、POSIXロック、OFDロックの動作の違いを確認できます。もちろんOFDロックの実行にはバージョンがv3.15以上のLinuxカーネルが必要です。

OFDロックの実行結果

$ ./sibling /tmp/testfile ofd
pid 2837 is wanting ...
pid 2837 acquired ofd                                   先のプロセスがロック獲得
pid 2838 is wanting ...                                 後のプロセスはロック解放待ち
lock_it:28: 2: OFDLCK ADVISORY  WRITE 2837 08:06:11 0 EOF
lock_it:28: 2: -> OFDLCK ADVISORY  WRITE 2838 08:06:11 0 EOF
pid 2837 releases
pid 2838 acquired ofd                                   後のプロセスがロック獲得
lock_it:28: 1: OFDLCK ADVISORY  WRITE 2838 08:06:11 0 EOF
pid 2838 releases

$ ./two-opens /tmp/testfile ofd
fd 3 pid 2843 is wanting ...
fd 3 pid 2843 acquired ofd
fd 4 pid 2843 is wanting ...                            後のロックが先のロックの解放待ち
                                                        デッドロック
$ fgrep -Hw 2843 /proc/locks
/proc/locks:2: OFDLCK ADVISORY  WRITE 2843 08:06:11 0 EOF
/proc/locks:2: -> OFDLCK ADVISORY  WRITE 2843 08:06:11 0 EOF
                                                        自プロセスは処理を進められない
                                                        ため先のロックの解放できない

$ ./one-open /tmp/testfile ofd                          一fdではデッドロックしない
pid 2862 is wanting ...
pid 2862 acquired ofd
main:25: 1: OFDLCK ADVISORY  WRITE 2862 08:06:11 0 EOF
pid 2862 is wanting ...
pid 2862 acquired ofd
main:25: 1: OFDLCK ADVISORY  WRITE 2862 08:06:11 0 EOF

$ ./flock-dup /tmp/testfile ofd unlock
got fd 3
got fd 4
fd 3 pid 2867 is wanting ...
fd 3 pid 2867 acquired ofd
main:39: 1: OFDLCK ADVISORY  WRITE 2867 08:06:11 0 EOF  元のfdのロックを獲得
fd 4 pid 2867 releases                                  複製したfdをアンロック
main:48: pid 2867 has no locks on 08:06:11              元のfdのロックが解放される

$ ./flock-dup /tmp/testfile ofd close
got fd 3
got fd 4
fd 3 pid 2868 is wanting ...
fd 3 pid 2868 acquired ofd
main:39: 2: OFDLCK ADVISORY  WRITE 2868 08:06:11 0 EOF  元のfdのロックを獲得
fd 4 closes                                             複製したfdをクローズ
main:48: 2: OFDLCK ADVISORY  WRITE 2868 08:06:11 0 EOF  元のfdのロックは維持される

$ ./flock-fork /tmp/testfile ofd unlock
pid 2877 is wanting ...
pid 2877 acquired ofd
main:36: 1: OFDLCK ADVISORY  WRITE 2877 08:06:11 0 EOF  親プロセスがロック
pid 2878 releases                                       子プロセスがアンロック
main:50: pid 2877 has no locks on 08:06:11              ロックが解放される

$ ./flock-fork /tmp/testfile ofd close
pid 2879 is wanting ...
pid 2879 acquired ofd
main:36: 2: OFDLCK ADVISORY  WRITE 2879 08:06:11 0 EOF  親プロセスがロック
pid 2880 closes                                         子プロセスがクローズ
main:50: 2: OFDLCK ADVISORY  WRITE 2879 08:06:11 0 EOF  ロックは維持される

$ ./two-opens-one-close /tmp/testfile ofd
fd 3 pid 2883 is wanting ...
fd 3 pid 2883 acquired ofd
main:30: 2: OFDLCK ADVISORY  WRITE 2883 08:06:11 0 EOF  fd 3をロック
fd 4 closes                                             fd 4をクローズ
main:34: 2: OFDLCK ADVISORY  WRITE 2883 08:06:11 0 EOF  fd 3のロックは維持される

本記事では、POSIXロックが抱える問題点を解説し、その対策としてLinuxカーネルに追加された新OFDロックを紹介しました。今後も折にふれLinuxカーネルの新機能を紹介したいと思います。

(初出: H26/9)

Copyright (C) 2014 SENJU Jiro