File Locking - in Unix-like Systems

In Unix-like Systems

Unix-like operating systems (including Linux and Apple's OS X) do not normally automatically lock open files or running programs. Several kinds of file-locking mechanisms are available in different flavors of Unix, and many operating systems support more than one kind for compatibility. The two most common mechanisms are fcntl and flock. A third such mechanism is lockf, which may be separate or may be implemented using either of the first two primitives. Although some types of locks can be configured to be mandatory, file locks under Unix are by default advisory. This means that cooperating processes may use locks to coordinate access to a file among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O.

Two kinds of locks are offered: shared locks and exclusive locks. In the case of fcntl, different kinds of locks may be applied to different sections (byte ranges) of a file, or else to the whole file. Shared locks can be acquired by an unlimited number of processes at the same time, but an exclusive lock can only be acquired by one process, and cannot coexist with a shared lock. To acquire a shared lock, a process must wait until no processes hold any exclusive locks. To acquire an exclusive lock, a process must wait until no processes hold either kind of lock. Unlike locks created by fcntl, those created by flock are preserved across forks, making them useful in forking servers. It is therefore possible for more than one process to hold an exclusive lock on the same file, provided these processes share a filial relationship and the exclusive lock was initially created in a single process before being duplicated across a fork.

Shared locks are sometimes called "read locks" and exclusive locks are sometimes called "write locks". However, because locks on Unix are advisory, this isn't enforced. Thus it is possible for a database to have a concept of "shared writes" vs. "exclusive writes"; for example, changing a field in place may be permitted under shared access, whereas garbage-collecting and rewriting the database may require exclusive access.

File locks apply to the actual file, rather than the file name. This is important since Unix allows multiple names to refer to the same file. Together with non-mandatory locking, this leads to great flexibility in accessing files from multiple or many processes. On the other hand, the cooperative locking approach can lead to problems when a process writes to a file without obeying file locks set by other processes.

For this reason, some Unix-like operating systems also offer limited support for mandatory locking. On such systems, a file whose setgid bit is on but whose group execution bit is off when that file is opened will be subject to automatic mandatory locking if the underlying filesystem supports it. However, non-local NFS partitions tend to disregard this bit. This is an exception to the earlier statement that Unix does not automatically lock open files. This strategy first originated in System V, and can be seen today in the Solaris, HP-UX, and Linux operating systems. It is not part of POSIX, however, and BSD-derived operating systems like FreeBSD, OpenBSD, NetBSD, and Apple's Mac OS X do not support it. Linux also supports mandatory locking through the special "mount(8) -o mand" parameter for filesystem mounting, but this is rarely used.