lockf(2)

構文

#include <unistd.h>

int lockf(int fildes, int function, off_t size);

説明

lockf() 関数によって、ファイルの領域をセマフォ (通知ロック) に用いたり、ロックするプロセスだけにアクセスを制限する (強制モードのレコードロック) ことができます。 ロックしたリソースにアクセスしようとする他のプロセスは、 エラーが返ってくるかリソースのロックが解除されるまでスリープ します。 プロセスのすべてのロックは、そのファイルが最初にクローズ された時に、そのプロセスがそのファイルをまだオープンしていても 解放されます。プロセスのもつすべてのロックは、そのプロセス が終了した時に解放されます。

fildes はオープンされたファイル記述子です。 この関数呼出しでロックを確立するには、 このファイル記述子は書込み専用パーミッション (O_WRONLY) またはリード/ライト パーミッション (O_RDWR) でオープンされていなければなりません open(2) を参照)。

呼び出したプロセスが PRIV_LOCKRDONLY 特権 getprivgrp(2) を参照して下さい) をもつグループに含まれている場合には、 読取り専用パーミッション (O_RDONLY) でオープンしたロックファイルについて lockf() を使うことができます。

function は実行される動作を指定する制御値です。 function に許される値は、 <unistd.h> に以下のように定義されています。

function のその他の値は将来の拡張用であり、実現 されていない場合は結果としてエラーになります。

F_TEST は、指定した範囲に別のプロセスによるロックが存在するかどうかを検 出するのに用いられます。 lockf() は、その範囲がアクセス可能であれば 0 を返し、そうでなければ -1 を返します。この場合には errno は EACCES に設定されます。 F_LOCK と F_TLOCK はファイルのある範囲を、その範囲が利用可能ならばロックします。 F_ULOCK はそのファイルの範囲からロックを解除します。

size ロックまたはロック解除される連続したバイトの数です。 ロックされるリソースはそのファイルの現在のオフセットから始まって size が正の時には前方に広がり、 負の時には後方に (現在のオフセットを含まずにそれ以前の方へ) 広がります。 size が 0 のときは、現在のオフセットから実現できるもっとも大きなファイルの終 端までをロックします (つまり現在のオフセットから、現在のあるいはこれから 将来にわたっての、そのファイルの終端までです)。 ロックされるためには、その部分がファイルにアロケートされている必要は ありません。なぜなら、そのようなロックはファイルの終端を越えて存在する ことができるからです。

F_LOCK または F_TLOCK でロックされた範囲は、 同じプロセスに以前ロックされた範囲を部分的にも全体でも含むことが でき、また逆に含まれることもできます。 このようなことが起きるか、隣接する範囲ができると、それらは 1 つの範囲に 統合されます。 リクエストが アクティブロックのテーブルに新しい要素を追加することを要求したが テーブルがすでにいっぱいである時、エラーが返されて新しい範囲はロックさ れません。

F_LOCK と F_TLOCK リクエストは、リソースが使用可能でなかった時にとる動作のみが違います。 F_LOCK は、呼び出したプロセスをリソースが使用可能になるまでスリープさせま す。それに対し、 F_TLOCK は他のプロセスがその範囲をすでにロックしていれば EACCES エラーを返します。

F_ULOCK は、そのプロセスが制御している 1 つまたはそれ以上のロックされた範囲 の全体、または一部を解放できます。 ロックされた範囲の中央の一部を解放するには、アクティブロックのテーブ ルに要素を追加する必要があります。このテーブルがいっぱいである場合は、 EDEADLK エラーが返され要求された範囲は解放されません。

S_ENFMT のファイルモードの通常のファイルは、グループ実行ビットがセットされて いないので、強制される方針が可能になります。 強制を可能にすると、 ロックされた範囲をアクセスする読書きは、 O_NDELAY がクリアされている場合は、 範囲全体が利用可能になるまでスリープし、 O_NDELAY がセットされている場合は-1 を返して errno をセットします。 exec() のような他のシステム機能によるファイルアクセス は、この強制ポリシーにはしたがいません。 ディレクトリ, パイプ, およびスペシャルファイルに対しての ロックは勧告のみであり、強制ポリシーは用いられません。

ロックしたリソースを制御するプロセスが、別のプロセス のロックしたリソースをアクセスしようとしてスリープする時には、 デッドロックの可能性が起きます。そこで、 fcntl() , lockf() , read() , または write() fcntl(2) , lockf(2) , read(2) および write(2) を参照) の呼出しはロックされたリソースについてスリープする前に デッドロックにならないかどうか走査します。 wait() および pause() システムコール wait(2) および pause(2) を参照) に関してはデッドロック の検査は行われません。 そのためデッドロックの可能性は消えていません。 通常のファイルについて O_CREATE と O_TRUNC フラグをセットして creat() または open() を呼び出すと、 別のプロセスがそのファイルの一部をロックしていて、 ファイルが現在強制モードになっている時には、 EAGAIN エラーが返ります。

ネットワーク機能

戻り値

正常終了すると 0 を返します。異常終了すると -1 を返し、エラーを示す値が errno にセットされます。

エラー

lockf() は、以下の条件のいずれかを満たす時に異常終了します。

警告

wait() または pause() システムコールが強制ロックに反して使用されている場合、 デッドロック状態が発生する可能性があります (詳細は wait(2) または pause(2) を参照して下さい)。

ファイル記述子がクローズされるとき、呼出しプロセスからのそのファイルに対するすべてのロックは、そのファイル (例えば、 dup() または open() を通して得られたファイル) の他のファイル記述子が、まだ存在する場合であっても、解除されます。

ユーザーのアドレス空間の中のバッファを使ったプロセス にも予期しない結果が起こり得ます。 プロセスは、ロックされているまたは、ロックされていたデータを読み込んだり 書き込んだりしてしまうかも知れません。標準入出力パッケージ stdio(3S) は、予期しないバッファリングのもっとも一般的な原因です。

不良な環境では、公共のリソースをロックするのに間違って使われ てしまうかも知れません。これは、強制が可能になっている公共の読出しファ イルに関しては特に起こり得ます。

PRIV_LOCKRDONLY 機能は使わないようにしてください。この機能は旧製品との互換性 のためだけに用意されたものです。 この機能は、以降の HP-UX のリリースでは変更されたり、廃止されたりする可能性があります。

ロックのデフォルトは、 ファイルパーミッションの setgid ビットがセットされていなければ勧告モードです。

参照

lockd(1M), statd(1M), chmod(2), close(2), creat(2), fcntl(2), creat64(2), open(2), pause(2), read(2), stat(2), wait(2), write(2), unistd(5)

標準準拠

lockf(): SVID2, SVID3, XPG2