manページ  — FCNTL

struct flock {
        off_t   l_start;        /* 開始位置のオフセット */
        off_t   l_len;          /* len = 0 はファイル末尾までという意味 */
        pid_t   l_pid;          /* ロック所有者 */
        short   l_type;         /* ロックタイプ: 読取り / 書込みなど */
        short   l_whence;       /* l_start のタイプ */
};

ロックは現在のファイル末尾以降で開始したり、 ファイル末尾を越えて延長することはできますが、 ファイルの先頭より前で開始したり、 ファイルの先頭を越えて延長することはできません。 l_len が 0 に設定されている場合、ロックはそのファイルの ファイルオフセットの可能な最大の値まで延長されます。 l_whence と l_start がファイルの先頭を指しており、しかも l_len が 0 の場合はファイル全体がロックされます。 アプリケーションがファイル全体をロックしようとしているだけなら、 flock(2) システムコールの方がはるかに効率的です。

ファイル内の各バイトについて最大で 1 つのタイプのロックが設定されます。 呼び出しプロセスが F_SETLK 要求、または F_SETLKW 要求で指定した領域内に既存のロックを保持しているとき、 要求から正常に戻る前に、 指定の領域内の各バイトについて以前の ロックタイプが新しいロックタイプで置き換えられます。 共有ロックと 排他的ロックのところで前述したように、 別のプロセスが指定の領域内にロックを保持しており、しかもそれらのロック のタイプが要求で指定されたタイプと競合するとき、 F_SETLK 要求は失敗し、 F_SETLKW 要求はブロックします。

このインタフェースは、System V と IEEE Std 1003.1-88 ("POSIX.1") が要求する不毛なセマンティクスに完全に従っています。 つまり、あるプロセスが保持している、 あるファイルと結び付けられたすべてのロックは、 そのファイルの記述子の いずれか がそのプロセスによって クローズされたときに解除されます。 これは、サブルーチンライブラリがアクセスする可能性のあるファイル全てを アプリケーションが認識している必要があることを意味します。 たとえば、パスワードファイルを更新するアプリケーションが、 更新を行うためにパスワードファイルデータベースをロックし、 レコードを取り出すために getpwnam(3) を呼び出したとしましょう。 getpwnam(3) はパスワードデータベースをオープンし、読み取り、 そしてクローズするので、ロックは失われます。 データベースをクローズすると、ライブラリルーチン がデータベースへのロックを要求したことがない場合でさえ、 プロセスがデータベースに結び付けたすべての ロックが解放されてしまうのです。 このインタフェースの別のさほど重要でないセマンティクス上の問題は、 ロックが fork(2) システムコールを使用して作成された子プロセスによって継承されないことです。 flock(2) インタフェースは、はるかに合理的な last close セマンティクスを採用し、 ロックが子プロセスによって継承されるようになっています。 ライブラリを使用するときにロックの整合性を確実にする、 またはロックを子プロセスに渡したいアプリケーションについては flock(2) システムコールをお勧めします。

fcntl(), flock(2) および lockf(3) のロックは互換性があります。 異なったロックのインタフェースを使用するプロセスは、 同じファイルを安全に使用することができます。 しかしながら、同じプロセスの内部では これらのインタフェースのうちの 1 つのみが使用されるべきです。 fcntl() を介してあるプロセスによってあるファイルがロックされている場合、 flock(2) または lockf(3) を使用している他のプロセスの視点からは、 そのファイルの中のあらゆるレコードはロックされているかのように見えます。 また、その逆も同様です。 ブロックするロックを保持しているプロセスがファイル記述子を以前に flock(2) でロックしていた場合、 fcntl(F_GETLK) は l_pid に -1 を入れて戻ります。

プロセスの、あるファイルに結び付けられたすべてのロックは そのプロセスが終了するときに解除されます。

execve(2) の呼び出し前に取得されたすべてのロックは、 新規プログラムがそれらを解放するまで有効なままです。 新規プログラムがロックについて知らないならば、 プログラム終了まで解放されません。

あるロックした領域を制御しているプロセスが、 別のプロセスがロックした領域をロックしようとして 休眠状態にされる場合に、デッドロックが発生する可能性があります。 この実装では、ロックされた領域がアンロックされるまでの休眠が デッドロックを引き起こす可能性を検出すると、 EDEADLK エラーで失敗します。

さらに、 fd が (ソケット上で開いている記述子とは反対に) 端末デバイス上で開いている記述子を参照する場合、 cmd で F_SETOWN を指定すると tcsetpgrp(3) と同じ理由で処理を失敗する可能性があり、 tcgetpgrp(3) で述べたような 理由で cmd で F_GETOWN を指定した場合に処理に失敗する可能性があります。