ファイルロック

ファイルロックとは、コンピュータのファイルへのアクセスを一時的に1人のユーザーや1つのプロセスに制限する機構。このロックの目的はいわゆる 「仲裁更新 interceding update」のシナリオを防ぐことである。

電子メールのスプールファイル

UNIXで電子メールをディスクに保存するときに伝統的に使われるフォーマットmboxは、一つのファイルに複数の電子メールメッセージを記録している。そのため、mboxに対し複数のプロセスが互いを考慮しないまま同時に書き込みや削除を行うと、仲裁更新問題が発生して消したはずのメールが復活してしまったり、逆に新たに受信したメールが消えてしまう。
これを防ぐため、各OSのファイルロック機構やロックファイルでmboxをロックすることでこの問題を回避している。

データベースの保守作業

データベースを構成している物理ファイル全体についてシリアライズ（逐次化）を施す。これで他のプロセスがファイルにアクセスするのを防ぐことができるし、関連するレコード群をロックするよりも事実上効率的かもしれない（多数のレコードロックをかけたり外したりするオーバヘッドを考慮した場合）。

UNIX

UNIXではオープン中のファイル（および実行中プログラム）は自動的にロックされない。UNIXの系統によってファイルロックの機構は異なり、多くのUNIX系システムは互換性のために複数のファイルロック機構をサポートしている。最も共通して使われているのは、fcntl と flock である。強制的にロックをかける設定にできる場合もあるが、UNIXのファイルロックは基本的に advisory（助言、補助）である。つまり、プロセスはロックに従ってファイルアクセスを抑制することもできるが、プログラムによってはロックを無視してファイルにアクセスすることも可能である。
ロックには共有ロックと排他ロックがある。fcntlでは、同一ファイル内で一部を共有ロックにしたり、別の部分を排他ロックにしたり、あるいはファイル全体をロックしたりできる。共有ロックは任意の個数のプロセスが同時にかけることができるが、排他ロックは1つのプロセスしかかけられず、（ファイルの同じ領域で）共有ロックとも共存できない。共有ロックをかける際に、先に排他ロックがかかっていたら、その排他ロックが外されるまで待たされる。排他ロックをかける際には、その領域に何のロックもかかっていない状態になるまで待たされる。
共有ロックを「リードロック」、排他ロックを「ライトロック」と呼ぶこともある。しかし、UNIXのロックは強制力がないので、リード専用/ライト専用ということではない。データベースにも「共有書き込み」と「排他書き込み」というコンセプトがある。例えば、あるフィールドの内容の書き換えは共有書き込みで可能だが、ガベージコレクションのようなものやデータベース全体の書き換えは排他書き込みになるだろう。
inodeと非強制的ロックの組合せにより、多くのプロセスがファイルに自由にアクセスすることができる。一方、ロックに従わないプロセスが簡単にファイルアクセスできてしまうという問題もある。このため、UNIX系オペレーティングシステムには「強制ロック; mandatory lock」もサポートしているものもある。

問題点

flockにもfcntlにも、他のオペレーティングシステムに慣れたプログラマから見ると奇異な点がある。
flockは NFS などのネットワークファイルシステムでは機能しない。BSDでは何も起きないし、Linuxではエラーとなる。同じファイルへの（ひとつのプロセスからの）flock呼び出しは、ロックの状態を変更する（共有から排他へ、あるいは排他から共有へ）。しかし、このとき一時的に古いロックを外してから新しいロックをかける。例えば、排他ロックから共有ロックにかけ変えようとしたとき、一瞬の隙をついて別のプロセスが排他ロックをかけたら、元々ロックをかけていたプロセスが締め出されてしまう。
プロセスはひとつのファイルに対応するファイル記述子を複数個持つことができる。このうちのいずれかを使ってfcntlでロックをかけていたとする。このとき、同じファイルに対応する別のファイル記述子をクローズすると、そのファイル上にそのプロセスが設定した全ロックが解除されてしまう。また、fcntlのロックは子プロセスに受け継がれない。このfcntlのクローズに関連した動作は、ライブラリのサブルーチン内でファイルにアクセスすることが多いアプリケーションなどで問題を発生することが多い。

Linux

Linux 2.4 とその後の版では "dnotify" 機構によってファイルの外見上の変化を通知してもらうことができる（fcntl で F_NOTIFY を指定）。ただし、この機構は Linux 2.6.13 では inotifyで置き換えられた。
また、強制ロックもサポートしていて "mount -o mand" というファイルシステムをマウントする時のパラメータを設定しておき、個別のファイルディスクリプタにfcntlを設定して使用する。ただし、多数のバグが存在し、滅多に使われない。

BTRON

BTRONには、他の主なOSとは根本的に異なるファイルシステムを採用しており、厳密にはファイルロックという概念は無い。このファイルシステムはTADと呼ばれ、仮身や実身と呼ばれる要素からなる。
仮身はWindowsなどの環境におけるアイコンのような概念であるが、一つの仮身は二重に開くことはできない。一方、実身とはファイルの実体であり、一つの実身に複数の仮身を存在させることができる。もし実身の中に自らの仮身を作るとループができ、この場合、個々のBTRON仕様OSの実装を別とすれば理論上はメモリが許す限り無制限に開くことも可能になる。こうして別々の仮身から開かれた同一実身は、いずれのプロセスより更新が行われると、この更新情報を記録し、同時に開かれていた「同一実身」の「別の仮身」が改めて保存を行おうとするとアラートを返し、確認する仕組みになっている。

Java

Javaでは、ファイルの読み書き時は、Windows上では、java.io.FileInputStream は削除ロックが、java.io.FileOutputStream では、削除ロックと書き込みロックがかかる。明示的に、読み書きロックを使用するには、java.nio.channels.FileChannel の lock() メソッドを使用する。

ロックファイル

ロックファイルはシェルスクリプトなどのプログラムでファイルロックの代替として使われる手法である。ロックファイルは内容は無関係で（ただし、ロック保持者のプロセス識別子を書き込んでおくことが多い）、存在することで他者に対して何らかの資源がロックされていることを知らせるのに使われる。通常ファイル以外のリソースを排他制御したときなどに主に使われる。
ロックファイルを使う場合、その操作がアトミックであることを保証するよう注意しなければならない。ロックを作成するとき、ロックファイルが存在しないことを確認してから作成するが、その途中で他のプロセスがロックファイルを先に作成してしまうかもしれない。これを防ぐ様々な手法がある。例えば、そのために設計された専用システムコールを使ったり（しかしシェルスクリプトから直接そのようなシステムコールを使うことはできない）、一時的な名前でロックファイルを作っておいて確認してから本来の名前にするなどの手法がある。