The practical difference between
lockf() is in the semantics (behaviour with respect to closing and passing), applicability over NFS and other shared filesystems, and whether the advisory locks are visible to other processes using
fcntl() locks or not.
The library you’re using simply has logic to pick the desired semantics based on the current platform.
If the semantics (behaviour over descriptor passing, forking, etc.) is acceptable, you should prefer
fcntl() locks over
flock() locks in Linux, simply because the former works on NFS etc. filesystems, whereas the latter does not. (On BSDs and Mac OS X, I believe you need to explicitly use
lockf() is just a wrapper around
flock() locks are separate (and will only work on local filesystems, not on e.g. NFS mounts on kernels prior to 2.6.12). That is, one process can have an advisory exclusive
flock() lock on a file, while another process has an advisory exclusive
fcntl() lock on that same file. Both are advisory locks, but they do not interact.
On Mac OS X and FreeBSD,
fcntl() locks all interact, although developers are recommended to use only one of the interfaces in an application. However, only
fcntl() locks work on NFS mounts (and, obviously, only if both NFS client and server have been configured to support record locks, which is surprisingly rare in e.g. web hosting environments; a huge cause of headaches for some web (framework) developers).
POSIX does not explicitly specify how
fcntl() locks should interact, and there have been differences in the past. Now, the situation has calmed down a bit, and one can approximately say that
fcntl()locks are the most reliable
Across architectures, they have the best chance of working right on e.g. shared filesystems — NFS and CIFS mounts, for example.
lockf()is implemented as “shorthand” for
The other alternative, as “shorthand” for
flock(), is possible, but nowadays rare.
flock()have different semantics wrt. inheritance and automatic releases
fcntl()locks are preserved across an
exec(), but not inherited across a
fork(). The locks are released when the owning process closes any descriptor referring to the same file.
In Linux, FreeBSD, and MAc OS X,
flock()locks are coupled with the open file descriptor: passing the descriptor also passes the lock. (The man pages state that “the lock is on the file, not on the file descriptor”. This is not a contradiction. It just means that the lock applies to the file. It is still coupled to the descriptor, in such a way that duplicating the descriptor also passes the same lock, too.) Therefore, it is possible that multiple processes have the same exclusive advisory
flock()lock on the same file at the same time, if they obtained the descriptor from the originator after the
File locking is surprisingly complicated issue. I have personally had best results by simply sticking to
fcntl() locking. The semantics wrt.
fcntl() locks are not the easiest to work with, and in certain cases can be frankly infuriating; it’s just that I’ve found it to yield the best — most reliable, most portable, least surprising — results.