bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

flock vs fcntl and pthreads


From: Mikhail Kruk
Subject: flock vs fcntl and pthreads
Date: Sun, 13 Apr 2003 23:23:25 -0400 (EDT)

Hi,
[I'm sorry if this is wrong place to ask about this and sorry that I ask a 
couple of questions in the same mail]

I'm compiling on a Red Hat 7.2 system with glibc 2.2.4(-31) and test on a 
Red Hat 7.3 system with glibc 2.2.5(-42). 

We are porting an application to Linux. It makes some Windows-specific 
assumptions about file locking which we're trying to translate into 
Unix/Linux world. First we were using fcntl to do file locking. It turned 
out that while it prevents two applications from accessing one file, two 
threads of the same process can both be granted an exclusive lock to the 
same file (different file descriptors). I tried using flock instead and it 
seems to do what we want: works across both processes and threads. I also 
read in the kernel documentation (locks.txt) that flock implementation is 
unaware of fcntl locks. OK. So now I get into a problem with flock: 
sometimes flock in a non-blocking mode (|LOCK_NB) fails on a file which I 
know is not accessed by anyone else. Retrying for up to a couple of 
seconds is needed to get the lock. I figured that this might be normal and 
related to the load on the server and maybe a couple of threads trying to 
lock files at the same time (since, I figured, internal flock structures 
are probably protected by a pthread mutex). When I got the glibc 2.2.5 
sources to check this, however, it seems that in flock.c flock() is in 
fact calling fcntl! (glibc-xxx/sysdeps/posix/flock.c)

I would really appreciate an explanation of what is really going on 
(difference between flock and fcntl), your opinion on whether flock's 
failures (resource temporarily unavailable) are normal and I should just 
retry for 10 seconds or something like that, and possibly just random 
advice :)

TIA!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]