mirror of https://github.com/mkerrisk/man-pages
Noted that lock conversions are not atomic.
This commit is contained in:
parent
5984622e7b
commit
6a916f1c28
16
man2/flock.2
16
man2/flock.2
|
@ -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),
|
||||
|
|
Loading…
Reference in New Issue