Re: Record Locking with fcntl(): what to do if unlock (F_UNLCK) fails?



On 27 Sep 2006 07:02:56 -0700, denis.papathanasiou@xxxxxxxxx staggered
into the Black Sun and said:
int lock_register(int fd, int type)
{
struct flock fl;

fl.l_type = type;
fl.l_start = fl.l_len = 0;
fl.l_whence = SEEK_SET;
return(fcntl(fd, F_SETLK, &fl));
}
#define place_lock(fd) lock_register((fd), F_WRLCK)
#define remove_lock(fd) lock_register((fd), F_UNLCK)

in the tests done so far, it works exactly as expected. One potential
problem, though, is what to do if the call to remove_lock fails. I'm
concerned about the possibility about creating an unresolvable
deadlock in a case like this.

At that point, remove_lock will return -1, and the calling code should
handle that in whatever manner is appropriate. If you'd like to check
which PID is holding the lock you'd like to release, "man 2 fcntl"
should help, particularly the text near the F_GETLK keyword. WARNING:
This junk may or may not be portable. The basics of fcntl will be, but
specifics might not be. Don't ask me; I haven't messed with fcntl on
non-Linux platforms.

Is invoking a close() on the file descriptor enough to remove the
lock, or do we need to take other action when that occurs?

If process N is holding a lock on file F, having process M close() file
F won't help process M one bit. Fortunately, you can figure out which
process is holding the lock with a few more lines of code. It's not
even insanely difficult--unless there's some sort of subtle trap that
I've missed in the man page--which *could* happen! A bit of short code
made it clear that it seems to work as advertised though. HTH,

--
One OS to rule them all, with DRM to find them
One OS to bring them all and with the EULA bind them
In the Land of Redmond where the shadows lie.
There is no Darkness in Eternity/But only Light too dim for us to see
.



Relevant Pages

  • Re: Record Locking with fcntl(): what to do if unlock (F_UNLCK) fails?
    ... which PID is holding the lock you'd like to release, "man 2 fcntl" ... F won't help process M one bit. ... process is holding the lock with a few more lines of code. ...
    (comp.os.linux.misc)
  • Re: FreeBSD 7.0 crashed when running super-smack upon PostgreSQL
    ... Is there any chance I can get remote access to a box holding the synchronized kernel, kernel debugging symbols, source code, and core dump? ... It sounds like TCP in a user thread is stumbling over a violation of system invariants (don't sleep while holding a mutex) performed by another thread. ... We need to track down the original thread and figure out why it's sleeping while holding that lock -- perhaps it's a user thread performing a copyin/copyout holding the lock, or perhaps an ithread or other software interrupt thread acquiring a lock of an inappropriate type while holding the lock. ... kgdb has its own thread ID scheme so you'll need to use info threads to track down the right kgdb thread id before you can select the identified kernel thread/process. ...
    (freebsd-stable)
  • RE: [PATCH] OsdSynch.c modernization
    ... acpi@xxxxxxxxxxx] On Behalf Of Jung-uk Kim ... That is a far better fit than the sx lock stuff you are doing. ... Does ACPI-CA want to mallocwhile holding an ACPI ... I guess it wants to mallocwhile holding spin lock although I ...
    (freebsd-current)
  • Re: Locking in C++
    ... even if the file is locked by fcntl or lockf, ... > But it's even worse than that; The locking functions provided to obtain ... > a lock operate on file descriptors, ...
    (comp.unix.programmer)
  • Re: Linux, fcntl vs flock and pthreads
    ... First we were using fcntl to do file locking. ... I tried using flock instead and it ... >seconds is needed to get the lock. ...
    (comp.unix.programmer)