読み出しロックを適用するには、 \fIfd\fP は読み出し用にオープンされていなければならない。 書き込みロックを適用するには、 \fIfd\fP
は書き込み用にオープンされていなければならない。 読み書き両方のロックを適用するには、読み書き両用で ファイルをオープンしなければならない。
-When placing locks with \fBF_SETLKW\fP, the kernel detects \fIdeadlocks\fP,
-whereby two or more processes have their lock requests mutually blocked by
-locks held by the other processes. For example, suppose process A holds a
-write lock on byte 100 of a file, and process B holds a write lock on byte
-200. If each process then attempts to lock the byte already locked by the
-other process using \fBF_SETLKW\fP, then, without deadlock detection, both
-processes would remain blocked indefinitely. When the kernel detects such
-deadlocks, it causes one of the blocking lock requests to immediately fail
-with the error \fBEDEADLK\fP; an application that encounters such an error
-should release some of its locks to allow other applications to proceed
-before attempting regain the locks that it requires. Circular deadlocks
-involving more than two processes are also detected. Note, however, that
-there are limitations to the kernel's deadlock\-detection algorithm; see
-BUGS.
+\fBF_SETLKW\fP でロックを適用する際、 カーネルは\fIデッドロック\fPの検出を行う。 2 つ以上のプロセスが、
+他のプロセスが保持するロックにより互いにブロックされるようなロック要求を行っているかを検査する。 例えば、 プロセス A があるファイルのバイト 100
+に対して書き込みロックを保持していて、 プロセス B がバイト 200 に対して書き込みロックを保持しているとする。 各プロセスが
+\fBF_SETLKW\fP を使って他のプロセスによるすでにロックされているバイトをロックしようとすると、 デッドロック検出がない場合、
+両方のプロセスが無限に停止することになる。 カーネルはこのようなデッドロックを検出すると、 停止していたロック要求の一つをエラー \fBEDEADLK\fP
+ですぐに失敗させる。 このエラーを受け取ったアプリケーションは、 必要なロックを再度獲得しようとする前に、
+他のアプリケーションが実行できるように自分が保持するロックのいくつかを解放する必要がある。 3
+つ以上のプロセスが関連する循環するデッドロックも検出される。 ただし、 カーネルのデッドロック検出アルゴリズムには制限がある点に注意すること。
+「バグ」を参照。
ろコードロックは \fBF_UNLCK\fP で明示的に削除されるだけでなく、 そのプロセスが終了した際には自動的に解放される。
.P
.PP
オープンファイル記述ロックを使うとこれらの問題が解決できる。
.SS "オープンファイル記述ロック (非 POSIX)"
-Open file description locks are advisory byte\-range locks whose operation is
-in most respects identical to the traditional record locks described above.
-This lock type is Linux\-specific, and available since Linux 3.15. For an
-explanation of open file descriptions, see \fBopen\fP(2).
-
-The principal difference between the two lock types is that whereas
-traditional record locks are associated with a process, open file
-description locks are associated with the open file description on which
-they are acquired, much like locks acquired with \fBflock\fP(2). Consequently
-(and unlike traditional advisory record locks), open file description locks
-are inherited across \fBfork\fP(2) (and \fBclone\fP(2) with \fBCLONE_FILES\fP), and
-are only automatically released on the last close of the open file
-description, instead of being released on any close of the file.
+オープンファイル記述ロックはバイト範囲に対するアドバイザリーロックで、 ほとんどの点で上述の昔からあるレコードロックと等価である。 このロック種別は
+Linux 固有であり、 Linux 3.15 以降で利用できる。 オープンファイル記述の説明は \fBopen\fP(2) を参照。
+
+2 つのロック種別の主な違いは、 昔からあるレコードロックはプロセスに関連付けられるのに対して、
+オープンファイル記述ロックはロックが獲得されるオープンファイル記述に関連付けられる点である。 この動作は \fBflock\fP(2)
+で獲得されるロックによく似ている。 結果として (昔からあるアドバイザリーレコードロックと違い)、 オープンファイル記述ロックは \fBfork\fP(2)
+(や \fBCLONE_FILES\fP 付きの \fBclone\fP(2)) の前後で継承され、 ファイルのクローズ時に解放されるのではなく、
+オープンファイル記述の最後のクローズ時にのみ自動的に解放される。
.PP
-Open file description locks always conflict with traditional record locks,
-even when they are acquired by the same process on the same file descriptor.
-
-Open file description locks placed via the same open file description (i.e.,
-via the same file descriptor, or via a duplicate of the file descriptor
-created by \fBfork\fP(2), \fBdup\fP(2), \fBfcntl\fP(2) \fBF_DUPFD\fP, and so on) are
-always compatible: if a new lock is placed on an already locked region, then
-the existing lock is converted to the new lock type. (Such conversions may
-result in splitting, shrinking, or coalescing with an existing lock as
-discussed above.)
-
-On the other hand, open file description locks may conflict with each other
-when they are acquired via different open file descriptions. Thus, the
-threads in a multithreaded program can use open file description locks to
-synchronize access to a file region by having each thread perform its own
-\fBopen\fP(2) on the file and applying locks via the resulting file
-descriptor.
+オープンファイル記述ロックは常に昔からあるレコードロックと競合する。 たとえ、
+ロックが同じプロセスによって同じファイルディスクリプターに対して行われたとしてもである。
+
+同じオープンファイル記述経由 (同じファイルディスクリプター経由や \fBfork\fP(2), \fBdup\fP(2), \fBfcntl\fP(2)
+\fBF_DUPFD\fP などで作成されたファイルディスクリプターの複製経由) で適用されたオープンファイル記述ロックは常に互換性がある。 つまり、
+すでにロックされている領域に対して新しいロックが適用された場合、 既存のロックは新しいロック種別に変換される。 (上記で説明した通り、
+このような変換の結果、 既存のロックの分割、 縮小、 結合が行われることがある。)
+
+一方、 異なるオープンファイル記述経由で獲得されると、 オープンファイル記述ロックは互いに競合する。 したがって、
+マルチスレッドプログラムのスレッドは、 各スレッドがそれぞれ自分で \fBopen\fP(2) を実行し、
+得られたファイルディスクリプター経由でロックを適用することで、
+オープンファイル記述ロックを使って一つのファイル領域えのアクセスを同期させることができる。
.PP
-As with traditional advisory locks, the third argument to \fBfcntl\fP(),
-\fIlock\fP, is a pointer to an \fIflock\fP structure. By contrast with
-traditional record locks, the \fIl_pid\fP field of that structure must be set
-to zero when using the commands described below.
+昔からあるレコードロックの場合と同様、 \fBfcntl\fP() の第 3 引き数 \fIlock\fP は \fIflock\fP 構造体へのポインターである。
+昔からあるレコードロックと違い、 下記で説明するコマンドを使う際には、 この構造体のフィールド \fIl_pid\fP に 0 を設定しなければならない。
-The commands for working with open file description locks are analogous to
-those used with traditional locks:
+オープンファイル記述ロックで使用できるコマンドは、 昔からあるロックのコマンドと同じである。
.TP
\fBF_OFD_SETLK\fP (\fIstruct flock *\fP)
(\fIl_type\fP が \fBF_RDLCK\fP か \fBF_WRLCK\fP の場合は) オープンファイル記述のロックの獲得を、 (\fBF_UNLCK\fP
.PP
.\" commit 57b65325fe34ec4c917bc4e555144b4a94d9e1f7
.\"
-In the current implementation, no deadlock detection is performed for open
-file description locks. (This contrasts with process\-associated record
-locks, for which the kernel does perform deadlock detection.)
+現在の実装では、 オープンファイル記述ロクではデッドロックの検出は行われない。 (これがプロセスと関連付けられるレコードロックとは異なる点である。
+プロセスと関連付けられるレコードロックではカーネルはデッドロックの検出を行う。)
.SS "強制ロック (mandatory locking)"
\fI警告\fP: Linux の強制ロックの実装は信頼性に欠けるものである。 下記の「バグ」の節を参照のこと。
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2015-01-11 03:53+0900\n"
-"PO-Revision-Date: 2015-01-18 17:07+0900\n"
+"PO-Revision-Date: 2015-01-18 20:14+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"before attempting regain the locks that it requires. Circular deadlocks "
"involving more than two processes are also detected. Note, however, that "
"there are limitations to the kernel's deadlock-detection algorithm; see BUGS."
-msgstr ""
+msgstr "B<F_SETLKW> でロックを適用する際、 カーネルはI<デッドロック>の検出を行う。 2 つ以上のプロセスが、 他のプロセスが保持するロックにより互いにブロックされるようなロック要求を行っているかを検査する。 例えば、 プロセス A があるファイルのバイト 100 に対して書き込みロックを保持していて、 プロセス B がバイト 200 に対して書き込みロックを保持しているとする。 各プロセスが B<F_SETLKW> を使って他のプロセスによるすでにロックされているバイトをロックしようとすると、 デッドロック検出がない場合、 両方のプロセスが無限に停止することになる。 カーネルはこのようなデッドロックを検出すると、 停止していたロック要求の一つをエラー B<EDEADLK> ですぐに失敗させる。 このエラーを受け取ったアプリケーションは、 必要なロックを再度獲得しようとする前に、 他のアプリケーションが実行できるように自分が保持するロックのいくつかを解放する必要がある。 3 つ以上のプロセスが関連する循環するデッドロックも検出される。 ただし、 カーネルのデッドロック検出アルゴリズムには制限がある点に注意すること。 「バグ」を参照。"
#. type: Plain text
#: build/C/man2/fcntl.2:431
"in most respects identical to the traditional record locks described above. "
"This lock type is Linux-specific, and available since Linux 3.15. For an "
"explanation of open file descriptions, see B<open>(2)."
-msgstr ""
+msgstr "オープンファイル記述ロックはバイト範囲に対するアドバイザリーロックで、 ほとんどの点で上述の昔からあるレコードロックと等価である。 このロック種別は Linux 固有であり、 Linux 3.15 以降で利用できる。 オープンファイル記述の説明は B<open>(2) を参照。"
#. type: Plain text
#: build/C/man2/fcntl.2:497
"are inherited across B<fork>(2) (and B<clone>(2) with B<CLONE_FILES>), and "
"are only automatically released on the last close of the open file "
"description, instead of being released on any close of the file."
-msgstr ""
+msgstr "2 つのロック種別の主な違いは、 昔からあるレコードロックはプロセスに関連付けられるのに対して、 オープンファイル記述ロックはロックが獲得されるオープンファイル記述に関連付けられる点である。 この動作は B<flock>(2) で獲得されるロックによく似ている。 結果として (昔からあるアドバイザリーレコードロックと違い)、 オープンファイル記述ロックは B<fork>(2) (や B<CLONE_FILES> 付きの B<clone>(2)) の前後で継承され、 ファイルのクローズ時に解放されるのではなく、 オープンファイル記述の最後のクローズ時にのみ自動的に解放される。"
#. type: Plain text
#: build/C/man2/fcntl.2:500
msgid ""
"Open file description locks always conflict with traditional record locks, "
"even when they are acquired by the same process on the same file descriptor."
-msgstr ""
+msgstr "オープンファイル記述ロックは常に昔からあるレコードロックと競合する。 たとえ、 ロックが同じプロセスによって同じファイルディスクリプターに対して行われたとしてもである。"
#. type: Plain text
#: build/C/man2/fcntl.2:513
"the existing lock is converted to the new lock type. (Such conversions may "
"result in splitting, shrinking, or coalescing with an existing lock as "
"discussed above.)"
-msgstr ""
+msgstr "同じオープンファイル記述経由 (同じファイルディスクリプター経由や B<fork>(2), B<dup>(2), B<fcntl>(2) B<F_DUPFD> などで作成されたファイルディスクリプターの複製経由) で適用されたオープンファイル記述ロックは常に互換性がある。 つまり、 すでにロックされている領域に対して新しいロックが適用された場合、 既存のロックは新しいロック種別に変換される。 (上記で説明した通り、 このような変換の結果、 既存のロックの分割、 縮小、 結合が行われることがある。)"
#. type: Plain text
#: build/C/man2/fcntl.2:521
"threads in a multithreaded program can use open file description locks to "
"synchronize access to a file region by having each thread perform its own "
"B<open>(2) on the file and applying locks via the resulting file descriptor."
-msgstr ""
+msgstr "一方、 異なるオープンファイル記述経由で獲得されると、 オープンファイル記述ロックは互いに競合する。 したがって、 マルチスレッドプログラムのスレッドは、 各スレッドがそれぞれ自分で B<open>(2) を実行し、 得られたファイルディスクリプター経由でロックを適用することで、 オープンファイル記述ロックを使って一つのファイル領域えのアクセスを同期させることができる。"
#. type: Plain text
#: build/C/man2/fcntl.2:532
"I<lock>, is a pointer to an I<flock> structure. By contrast with "
"traditional record locks, the I<l_pid> field of that structure must be set "
"to zero when using the commands described below."
-msgstr ""
+msgstr "昔からあるレコードロックの場合と同様、 B<fcntl>() の第 3 引き数 I<lock> は I<flock> 構造体へのポインターである。 昔からあるレコードロックと違い、 下記で説明するコマンドを使う際には、 この構造体のフィールド I<l_pid> に 0 を設定しなければならない。"
#. type: Plain text
#: build/C/man2/fcntl.2:535
msgid ""
"The commands for working with open file description locks are analogous to "
"those used with traditional locks:"
-msgstr ""
+msgstr "オープンファイル記述ロックで使用できるコマンドは、 昔からあるロックのコマンドと同じである。"
#. type: TP
#: build/C/man2/fcntl.2:535
"In the current implementation, no deadlock detection is performed for open "
"file description locks. (This contrasts with process-associated record "
"locks, for which the kernel does perform deadlock detection.)"
-msgstr ""
+msgstr "現在の実装では、 オープンファイル記述ロクではデッドロックの検出は行われない。 (これがプロセスと関連付けられるレコードロックとは異なる点である。 プロセスと関連付けられるレコードロックではカーネルはデッドロックの検出を行う。)"
#. type: SS
#: build/C/man2/fcntl.2:596 build/C/man2/fcntl.2:1668
#: build/C/man2/vhangup.2:69
msgid "B<capabilities>(7), B<init>(1)"
msgstr "B<capabilities>(7), B<init>(1)"
-
-#~ msgid ""
-#~ "B<dup2>() makes I<newfd> be the copy of I<oldfd>, closing I<newfd> first "
-#~ "if necessary, but note the following:"
-#~ msgstr ""
-#~ "B<dup2>() は I<newfd> を I<oldfd> の複製として作成する。 必要であれば最初"
-#~ "に I<newfd> をクローズする。 以下の点に注意すること。"
-
-#~ msgid ""
-#~ "If I<newfd> was open, any errors that would have been reported at "
-#~ "B<close>(2) time are lost. A careful programmer will not use B<dup2>() "
-#~ "or B<dup3>() without closing I<newfd> first."
-#~ msgstr ""
-#~ "I<newfd> がオープンされていると、 B<close>(2) した時に報告されるはずのエ"
-#~ "ラーが失われてしまう。 B<dup2>() や B<dup3>() を使う前に先ず I<newfd> を"
-#~ "クローズするようにした方がいいだろう。"
-
-#~ msgid ""
-#~ "(Non-POSIX.) The above record locks may be either advisory or mandatory, "
-#~ "and are advisory by default."
-#~ msgstr ""
-#~ "上述のロックにはアドバイザリロック (advisory lock) と強制ロック "
-#~ "(mandatory lock) の二種類があるが、デフォルトではアドバイザリロックとな"
-#~ "る。"
-
-#~ msgid ""
-#~ "B<flock>() does not lock files over NFS. Use B<fcntl>(2) instead: that "
-#~ "does work over NFS, given a sufficiently recent version of Linux and a "
-#~ "server which supports locking."
-#~ msgstr ""
-#~ "B<flock>() は NFS 上のファイルのロックをしない。代わりに B<fcntl>(2) を"
-#~ "使用すること。これにより、十分に新しいバージョンの Linux と、ロック機能を "
-#~ "サポートした NFS サーバを使用することにより、NFS 上でロックができる。"
-
-#~ msgid ""
-#~ "The child does not inherit record locks from its parent (B<fcntl>(2))."
-#~ msgstr ""
-#~ "子プロセスは親プロセスからレコードロック (B<fcntl>(2)) を引き継がない。"
-
-#~ msgid ""
-#~ "The Linux kernel has a B<sysinfo>() system call since 0.98.pl6. Linux "
-#~ "libc contains a B<sysinfo>() routine since 5.3.5, and glibc has one "
-#~ "since 1.90."
-#~ msgstr ""
-#~ "Linux カーネルは 0.98.pl6 から B<sysinfo>() システムコールを持っている。 "
-#~ "Linux の libc は 5.3.5 より、glibc では 1.90 より B<sysinfo>() ルーチンを"
-#~ "含んでいる。"
-
-#~ msgid "Underlying kernel interface"
-#~ msgstr "背後のカーネルインタフェース"
OSDN Git Service
