What is the order in which the POSIX system cleans up locks on files that have not been unlocked?

Question

The POSIX specification for fcntl() states:

All locks associated with a file for this process should be removed when the file descriptor for this file is closed by this process or the process in which this file descriptor terminates.

Is this operation unlocking locks on file segments that were saved by an atomic processor with a completed process? In other words, if byte segments B1..B2 and B3..B4 of a file were locked in the process, but they did not unlock segments before completion, when the system approaches unlocking them, these are segments B1..B2 and B3..B4 both are unlocked before how can another fcntl() operation to block a file segment be successful? If it is not an atomic file, does the order in which these file segments are unlocked by the system depends on the order in which the file segments were originally received?

The specification for fcntl() not specified, but perhaps the POSIX specification has a general provision that defines a deterministic order of operations that will be cleared after a process that fails or fails.

Answer 1

In the section section 2.9.7 in the section "Interaction of streams with ordinary file operations" of the POSIX specification:

All functions are chmod () , close () , fchmod () , fcntl () , fstat () , ftruncate () , lseek () , open () , read () , readlink () , stat () , symlink () and write () must be atomic with respect to each other in the effects specified in IEEE Std 1003.1-2001 when they work with regular files. If each of the two threads calls one of these functions, each call must either see all the specified effects of the other call, or none of them.

So, for a regular file, if a process thread contains locks on file segments and calls close() in the last file descriptor associated with the file, then close() effects (including removing all outstanding file locks that are stored in the process) are atomic with respect to effects calling fcntl() by another process thread to lock the file segment.

The specification for exit() states:

These functions must interrupt the calling process with the following consequences:

• All file descriptors, directory streams [, conversion descriptors, and message catalog descriptors] opened in the calling process must be closed.

• ...

Presumably, open file descriptors are closed, as if the corresponding calls to close() , but, unfortunately, the specification does not say how open file descriptors are “closed”.

The 2004 specification seems even more vague when it comes to the steps of abnormally completing the process. The only thing I could find was the documentation for abort() . At least in the 2008 specification, the _Exit() page has a section called Consequences of terminating the process . However, the wording is still:

• All file descriptors, directory streams, conversion descriptors, and message catalog descriptors opened in the calling process must be closed.

UPDATE: I just opened question 0000498 in the Austin group defect report .

Answer 2

I don’t think the POSIX specification stipulates whether the release of locks is atomic or not, so you should assume that it behaves as inconvenient for you. If you need them to be atomic, this is not so; if you need to be treated separately, they are atomic; if you don't care, some cars will do it one way and other cars differently. So write your code so it doesn't matter.

I am not sure how you will write the code to detect the problem.

In practice, I expect the locks to be released atomically, but the standard does not say, so you should not assume.