Things UNIX can do atomically — Crowley Code!

This is a list of things that UNIX-like/POSIX-compliant operating systems can do atomically, making them useful as building blocks for thread-safe and multi-process-safe programs without mutexes or read/write locks. The list is by no means exhaustive and I expect it to be updated frequently in the near future.

The philosophy here is to let the kernel do as much of the work as possible. At my most pessimistic, I trust the kernel developers more than myself. More practically, it is foolish to waste CPU time by locking an operation that is already atomic. Added on 2010-01-07.

operation on pathname

The actions below are best left to the local file system. More than a few people have written in to cry foul if any of these techniques are used on an NFS mount. Truth. When multiple kernels are involved, the kernel cannot take care of all the locking well for us. Added on 2010-01-06.

• mv -T atomically alters the target to the directory pointed to by And is indispensable when deploying new code. Update 2010-01-06: Both operands are symlinks. (So ​​it’s not a system call, it’s still useful.) A reader pointed this out ln -Tfs Accomplishes the same task even without the second symlink. Added on 2010-01-06. Removed on 2010-01-06: strace(1) It turns out that ln -Tfs actually calls symlink(2), unlink(2)And symlink(2) Once again, it has been disqualified from this page. mv -T call ends rename(2) which can atomically replace . WARNING 2013-01-07: This does not apply to Mac OS mv(1) doesn’t call rename(2). mv(1).
• link(oldpath, newpath) Creates a new hard link called newpath pointing to the same inode oldpath And increments the link number by one. It will fail with error code EEXIST If newpath This already exists, making it a useful mechanism for locking a file between threads or processes on a name they can all agree on. newpath. I prefer this technique for entire file locking because the lock is visible. ls(1). link(2).
• symlink(oldpath, newpath) works great link(2) But creates a symbolic link to a new inode instead of a hard link to the same inode. Symbolic links can point to directories, which hard links cannot, making them a perfect analogy. link(2) When locking entire directories. It will fail with error code EEXIST If newpath already exists, which makes it a perfect analogy link(2) This works for directories too. Beware of symbolic links whose target inode has been removed (“dangling” symbolic links) – open(2) will fail with error code ENOENT. It should be mentioned that inodes are a limited resource (this particular machine has 1,245,184 inodes). symlink(2). Added on 2010-01-07
• rename(oldpath, newpath) Provided that, the pathname can be changed atomically. oldpath And newpath Are on the same file system. It will fail with error code ENOENT If oldpath does not exist, enables interprocess locking to a large extent link(oldpath, newpath) Above. I find this technique more natural when the related files are unlinkLater Ed. rename(2).
• open(pathname, O_CREAT | O_EXCL, 0644) Creates and opens a new file. (Don’t forget to set the mode in the third argument!) O_EXCL Causes it to fail with error code EEXIST If pathname Is present. This is a useful way of deciding which process should handle a task: whichever process successfully creates the file. open(2).
• mkdir(dirname, 0755) Creates a new directory but fails with error code EEXIST If dirname Is present. It provides similar mechanism for directories link(2) open(2) with O_EXCL Provides files. mkdir(2). Added on 2010-01-06; Edited 2013-01-07.

operations on file descriptors

• fcntl(fd, F_GETLK, &lock), fcntl(fd, F_SETLK, &lock)And fcntl(fd, F_SETLKW, &lock) Allow collaborative processes to lock areas of a file to serialize their access. lock is of type struct flock and describes the type of lock and the area to be locked. F_SETLKW Particularly useful because it blocks the calling process until the lock is obtained. There is a “mandatory locking” mode but Linux’s implementation is unreliable as it is subject to race conditions. fcntl(2).
• fcntl(fd, F_GETLEASE) And fcntl(fd, F_SETLEASE, lease) Tell the kernel to notify the calling process SIGIO When another process opens or truncateis the file referenced by fd. When that signal comes, the leash must be removed fcntl(fd, F_SETLEASE, F_UNLCK). fcntl(fd, F_NOTIFY, arg) Similar but does not block other processes, so it is not useful for synchronization. fcntl(2).
• mmap(0, length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0) Returns a pointer from which the contents of the file can be read and written by normal memory operations. from repeated use msync(addr, length, MS_INVALIDATE)Data written in this manner can be shared between processes that both map to the same file. mmap(2), msync(2).

operations on virtual memory

• __sync_fetch_and_add, __sync_add_and_fetch, __sync_val_compare_and_swapAnd friends provide a full barrier so that “no memory operand will be moved forward or backward throughout the operation.” These operations are the basis of most (all?) lock-free algorithms. GCC Nuclear Construction.

Anything I should add to my repertoire? Race condition? Let me know at r@rcrowley.org or @rcrowley And I will fix it.