by 0xbadcafebee
1 subcomments
- You can use `ln` atomicity for a simple, portable(ish) locking system: https://gist.github.com/pwillis-els/b01b22f1b967a228c31db3cf...
- Missing (probably because of the date of the article): `mv --exchange` aka renameat2+RENAME_EXCHANGE. It atomically swaps 2 file paths.
- Unless they can be guaranteed by the POSIX specification, they are implementation specific and should not be relied upon for portable code.
- I use several of these to implement alternative SQLite locking protocols.
POSIX file locking semantics really are broken beyond repair: https://news.ycombinator.com/item?id=46542247
- The mmap/msync one is incorrect I believe? (Correct me if I am wrong).
msync() sync content in memory back to _disk_. But multiple processes mapping the same file always see the same content (barring memory consistency, caching, etc.) already. Unless the file is mapped with MAP_PRIVATE.
- >fcntl(fd, F_GETLK, &lock), fcntl(fd, F_SETLK, &lock), and fcntl(fd, F_SETLKW, &lock)
There's also `flock`, the CLI utility in util-linux, that allows using flocks in shell scripts.
by KevinChasse
0 subcomment
- Nice catalog. One subtle thing I’ve found in building deterministic, stateless systems is that atomic filesystem and memory operations are the only way to safely compute or persist secrets without locks. Combining rename/link/O_EXCL patterns with ephemeral in-memory buffers ensures that sensitive data is never partially written to disk, which reduces race conditions and side-channel exposure in multi-process workflows.
- rename() is certainly the easiest to use for any sort of file-system based synchronization.
by zzo38computer
3 subcomments
- Even though it can do some things atomically, it only does with one file at a time, and race conditions are still possible because it only does one operation at a time (even if you are only need one file). Some of these are helpful anyways, such as O_EXCL, but it is still only one thing at a time which can cause problems in some cases.
What else it does not do is a transaction with multiple objects. That is why, I would design a operating system, that you can do a transaction with multiple objects.
- Not much apparently, although I didn't know about changing symlinks, that could be very useful.
- I wonder why the author left out atomic writes with O_APPEND.
by andrewstuart
0 subcomment
- Anywhere there is atomic capability you can build a queuing application.
- Not technically related to atomicity, but I was looking for a way to do arbitrary filesystem operations based on some condition (like adding a file to a directory, and having some operation be performed on it). The usual recommendation for this is to use inotify/watchman, but something about it seems clunky to me. I want to write a virtual filesystem, where you pass it a trigger condition and a function, and it applies the function to all files based on the trigger condition. Does something like this exist?
by maximgeorge
0 subcomment
- [dead]
- This document being from 2010 is, of course, missing the C11/C++11 atomics that replaced the need for compiler intrinsics or non portable inline asm when "operating on virtual memory".
With that said, at least for C and C++, the behavior of (std::)atomic when dealing with interprocess interactions is slightly outside the scope of the standard, but in practice (and at least recommended by the C++ standard) (atomic_)is_lock_free() atomics are generally usable between processes.
- Sorry, there is zero chance I will ever deploy new code by changing a symlink to point to the new directory.
Hacker News