Noted that lock conversions are not atomic.

This commit is contained in:
Michael Kerrisk 2005-05-10 06:43:47 +00:00
parent 5984622e7b
commit 6a916f1c28
1 changed files with 15 additions and 1 deletions

View File

@ -27,6 +27,7 @@
.\" Modified Fri Dec 11 17:57:27 1998 by Jamie Lokier <jamie@imbolc.ucc.ie>
.\" Modified 24 Apr 2002 by Michael Kerrisk <mtk-manpages@gmx.net>
.\" Substantial rewrites and additions
.\" 2005-05-10 mtk, noted that lock conversions are not atomic.
.\"
.TH FLOCK 2 2002-04-24 Linux "Linux Programmer's Manual"
.SH NAME
@ -163,7 +164,20 @@ and
.BR fcntl (2)
locks have different semantics with respect to forked processes and
.BR dup (2).
.SH "SEE ALSO"
.PP
Converting a lock
(shared to exclusive, or vice versa) is not guaranteed to be atomic:
the existing lock is first removed, and then a new lock is established.
Between these two steps,
a pending lock request by another process may be granted,
with the result that the conversion either blocks, or fails if
.B LOCK_NB
was specified.
(This is the original BSD behaviour,
and occurs on many other implementations.)
.\" Kernel 2.5.21 changed things a little: during lock conversion
.\" it is now the highest priority process that will get the lock -- mtk
.SH SEE ALSO"
.BR close (2),
.BR dup (2),
.BR execve (2),