ファイルロック機構（flock・fcntl・リース）

勧告的ロックと強制的ロック：合意がなければ効かない

ファイルロックの最初の落とし穴は、ほとんどのロックが「勧告的（advisory）」であることです。勧告的ロックは、ロックを取得した事実をカーネルに登録するだけで、他プロセスの read/write を物理的に止めません。協調する側が「書く前に必ずロックを取りに行く」という規約を守って初めて排他が成立します。規約を無視して直接 write するプロセスがいれば、ロックは何の防御にもなりません。鍵ではなく、共有黒板に貼る「使用中」の付箋に近い仕組みです。

これに対し 強制的（mandatory）ロック は、ロック中のバイト範囲への read/write をカーネルが自動でブロックまたはエラー化する、本物の鍵です。POSIXは規定するものの、Linuxの実装は危険なレースを抱え、対象ファイルシステムを mand オプションでマウントし、ファイルに setgid かつグループ実行ビットなしという特殊なモード設定が要るという扱いづらさもあり、長く非推奨でした。Linux 5.15で CONFIG_MANDATORY_FILE_LOCKING 自体が削除され、事実上廃止されています。実務では「強制ロックは存在しないもの」と考え、勧告的ロックの規約を全員で守る前提で設計します。

flockとfcntl：所有権モデルが根本的に違う

Linuxには伝統的に2系統の勧告的ロックAPIがあり、「ロックが誰のものか」という所有権の単位が決定的に異なります。ここを混同すると、forkや二重openでロックが意図せず消えたり自滅したりします。

flock のロックは**オープンファイル記述（struct file）**に紐づきます。open 1回で生まれる記述が所有者なので、dup や fork で同じ記述を共有するfdは同じロックを指し、別々に open した2つのfdは別の所有者として互いに競合します。この「記述単位」という性質は、fdの三層構造（ファイルディスクリプタとオープンファイルテーブルの構造）を押さえているとそのまま理解できます。

一方、伝統的 fcntl（F_SETLK/F_SETLKW）のロックは**（プロセス, inode）の組**に紐づきます。これが2つの悪名高い罠を生みます。

flock と fcntl のロックは別系統で互いに見えない点も重要です（一部の古いシステムやNFS実装を除く）。同じファイルに flock と fcntl を混在させても排他できないため、システム全体でどちらか一方に統一します。

OFDロック：fcntlの欠陥を所有権モデルから修正する

二重openの自滅とfork非継承は、いずれも「所有者が（プロセス, inode）である」ことに起因します。そこでLinux 3.15（POSIX.1-2024で標準化）が導入したのが**OFDロック（Open File Description lock）です。F_OFD_SETLK/F_OFD_SETLKW/F_OFD_GETLK を使うと、ロックの所有者が flock と同じくオープンファイル記述（struct file）**になり、バイト範囲指定という fcntl の利点はそのまま残ります。

所有者が記述になることで、別々に open した2つのfd（=別記述）はスレッド間でも独立した所有者となり、互いに正しく競合します。これでマルチスレッドのファイル間排他が安全に書けます。逆に fork 後は親子が同一記述を共有するため、子もロックを保持し続けます。新規コードでバイト範囲ロックが要るなら、伝統的 fcntl ではなく OFDロックが第一選択です。

所有権モデルの違い（同じファイルを2回 open した場合）

 flock / OFDロック:                fcntl(伝統):
   open#1 → 記述A → ロックA           open#1 ┐
   open#2 → 記述B → ロックB           open#2 ┴→ (プロセス,inode) で1つの所有者
   AとBは別所有者 → 正しく競合         → どちらかを close すると両方のロックが消える

デッドロック検出とリース：カーネルが見るグラフと逆方向の通知

F_SETLKW/F_OFD_SETLKW（待機付き取得）では、ロック待ちのプロセスが循環するデッドロックが起こり得ます。AがレコードR1を持ってR2を待ち、BがR2を持ってR1を待つ典型です。fcntl/OFDロックではカーネルがロック保持者と待機者の有向グラフを内部に持ち、新たな待機を登録する直前にそのグラフを走査して循環を探します。循環が見つかれば待機を成立させず、即座に EDEADLK を返してデッドロックを未然に防ぎます。これは排他制御とデッドロックで扱う検出アルゴリズムを、カーネルがファイルロックに対して実装したものです。

リース（lease） は、これまでのロックとは方向が逆の仕組みです。fcntl(fd, F_SETLEASE, F_RDLCK or F_WRLCK) でファイルにリースを設定したプロセスは、他のプロセスがそのファイルを open したり truncate しようとした瞬間に通知（既定で SIGIO）を受け取ります（シグナル）。リース保持者はその通知を受けてキャッシュを書き戻すなどの後始末を行い、リースを降格・解除します。一定時間（/proc/sys/fs/lease-break-time、既定45秒）内に応じないと、カーネルが強制的にリースを破棄して相手のopenを進めます。

リースの典型用途は、ユーザ空間のファイルサーバ（Samba等）が「自分がファイルをキャッシュ中だが、他者がアクセスし始めたら即座に知りたい」というキャッシュ整合性の通知です。ロックが「自分がアクセスする間、他者を待たせる」のに対し、リースは「他者がアクセスし始めたら自分が動く」という非対称な役割分担になっています。

まとめ

• Linuxの古典的ファイルロックは大半が勧告的で、協調プロセス同士の規約として働く。強制ロックは事実上廃止され、信頼できないアクセスの防御には使えない。
• flockはオープンファイル記述（struct file）単位、伝統的fcntlは（プロセス, inode）単位。所有権モデルの違いから、fcntlはforkで継承されず、同一inodeの二重open＋片方closeで自滅する。
• **OFDロック（F_OFD_SETLK 系）**は所有者を記述単位に変え、fcntlの欠陥を直しつつバイト範囲指定を残す。新規コードでの範囲ロックの第一選択。
• fcntl/OFDロックはカーネルが保持者・待機者の有向グラフを走査して循環を検出し**EDEADLK**を返す。リースは他者のopen/truncateを検知してSIGIOで持ち主に通知する、方向が逆のキャッシュ整合性向け機構。

所有権モデルの土台はファイルディスクリプタとオープンファイルテーブルの構造、検出と回避の原理は排他制御とデッドロックとデッドロック、通知に使うSIGIOはシグナルを合わせて読むと、ファイルロックという地味だが事故の多い領域の全体像が原理から見渡せます。