From 6a916f1c287ad6e11e7086c347a66833fc0cf03b Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Tue, 10 May 2005 06:43:47 +0000 Subject: [PATCH] Noted that lock conversions are not atomic. --- man2/flock.2 | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/man2/flock.2 b/man2/flock.2 index 771748128..7678cd52e 100644 --- a/man2/flock.2 +++ b/man2/flock.2 @@ -27,6 +27,7 @@ .\" Modified Fri Dec 11 17:57:27 1998 by Jamie Lokier .\" Modified 24 Apr 2002 by Michael Kerrisk .\" 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),