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 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> .\" Modified 24 Apr 2002 by Michael Kerrisk <mtk-manpages@gmx.net>
.\" Substantial rewrites and additions .\" 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" .TH FLOCK 2 2002-04-24 Linux "Linux Programmer's Manual"
.SH NAME .SH NAME
@ -163,7 +164,20 @@ and
.BR fcntl (2) .BR fcntl (2)
locks have different semantics with respect to forked processes and locks have different semantics with respect to forked processes and
.BR dup (2). .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 close (2),
.BR dup (2), .BR dup (2),
.BR execve (2), .BR execve (2),