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

Following the example in "Advanced Programming in the UNIX Environment"
book (http://apuebook.com/), I've written a function which will lock
and unlock an entire file:

int
lock_register(int fd, int type)
{
struct flock fl;

fl.l_type = type;
fl.l_start = 0;
fl.l_whence = SEEK_SET;
fl.l_len = 0;
return(fcntl(fd, F_SETLK, &fl));

}

And these header macros define the actual set & remove lock function
calls:

#define place_lock(fd)  lock_register((fd), F_WRLCK)
#define remove_lock(fd) lock_register((fd), F_UNLCK)

It's been run in both debian and redhat environments, and 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.

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

On 27 Sep 2006 09:37:19 -0700, denis.papathanasiou@gmail.com wrote:

[...]

>It's been run in both debian and redhat environments, and 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.

Your program should of course check the return status of
fcntl(F_UNLCK), but in general there is no reason why an attempt to
release a lock that you currently hold should ever fail.

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

Yes, closing the file descriptor will release the locks.

But, be a bit careful, the semantics of close() and fcntl() locks are
tricky: when a file descriptor is close, all locks held by the process
on the corresponding file are released, no matter which file
descriptor the locks were obtained through.

Cheers,

Michael

denis.papathanasiou@gmail.com wrote:

> 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.
>
> Is invoking a close() on the file descriptor enough to remove the lock,
> or do we need to take other action when that occurs?

This is a "can't happen" case. There's really no conceivable scenario
in which it could happen, so there's no way to know what the "right
thing" to do is. I think you can make a case for two options:

1) Terminate the program. This is probably best if the program is
mission critical. You don't want it to do the wrong thing, and you have
no idea what just happened. Maybe somehow you got the wrong file
descriptor or a cosmic ray flipped a bit.

2) Close the file. This is probably best if the program is typical.

DS