[Top][All Lists]
[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!
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- flock vs fcntl and pthreads,
Mikhail Kruk <=