3 ms·

The amusing thing, apart from the fact that we are still discussing the unexpected interactions of locks and NFS after 35 years, is that recommending not using

by JdeBP 3y ago

The amusing thing, apart from the fact that we are still discussing the unexpected interactions of locks and NFS after 35 years, is that recommending not using flock() is the reverse of the manual pages and widespread existing practice. The Linux manual calls the lockf()/fcntl(F_SETLK) mechanism "unfortunate". The BSD manual, across all flavours, is not so restrained and calls them "completely stupid semantics of System V". The BSD manual calls the flock() mechanism "much more rational" and "recommended". The Linux manual likewise recommends using its per-open-file-description mechanism of fcntl(F_OFD_SETLK) as "a Linux-specific alternative with better semantics". Thus we are in the unenviable situation that the Linux NFS client/server implementation breaks flock(), by translating into POSIX locks under the covers some of the time; but the non-POSIX flock() is the "better", "rational", mechanism that is widely recommended, and that has been long used by the BSD lockf(1) utility and the Bernstein setlock(1) utility and the Pape chpst(8) utility.

wahern 3y ago
For all the dangerous qualities of classic POSIX/SysV locks, they're in service of one key characteristic[1]: only a single process can hold a lock, which means you can easily identify and communicate with the lock-holding process, such as by querying for and sending a signal to the PID (ignoring NFS, which came along later). With BSD descriptor locks, multiple processes can and often invariably do hold the lock, by holding dup'd references to the same open file table entry. [1] Maybe this could have been achieved with better semantics, but my guess is the semantics follow from a very straight-forward implementation given the classic 3-level Unix file model of per-process descriptor tables, global open file table, and global open inode table, where you just hang the lock index off of the global open inode table, without any back referencing to the higher-level tables, notwithstanding recording of the lock owner PID. SysV mandatory locking perhaps also figured into this design and the semantics.
- Joker_vD 3y ago
  IIRC the initial implementation of what became POSIX locks was cobbled together in a weekend just so that the author could submit something to the POSIX group but then apparently nobody else did, or bothered to read/argue, so it got standardized as-is, with all of its unfortunate implications.
- JdeBP 3y ago
  That's certainly the implementation, v_filocks. But I'd be wary of saying that the implementation drove the design. Remember that people have historically disagreed about synchronization mechanisms and which ones are the good ones. It's quite possible that the design was simply intentionally that way, not following from any implementation considerations. For example: Dave Cutler architect of Windows NT called the OS/2 mutex mechanism a "mutant" because xe thought the semantics were bad. But the semantics that xe didn't like were designed so that a locking thread was told whenever the preceding mutex owner lost the lock because it ABENDed, and that thus whatever the mutex was guarding was probably not in a consistent unlocked state. One has only to cast one's mind back to how file sharing flags worked, or just didn't work, on MS/PC/DR-DOS when they first came along (Hands up if you remember compatibility mode sharing, or Netware's added spin to the whole thing.) to be reminded that sometimes design was just odd, by today's standards. (-: By the way: NFS began in 1984 and was available for AT&T Unix System 5 Release 2. File locking with lockf()/fcntl() dates from AT&T Unix System 5 Release 3 which was actually later, not earlier. Also remember that System 5 Release 3 at the same time introduced RFS, which did do locking and statefully maintained open file descriptions on the server, so the idea of the PID being accessible is a bit of a red herring.
JdeBP 3y ago
I thought that I was done when I augmented https://jdebp.uk/Softwares/nosh/guide/commands/setlock.xml https://jdebp.uk/Softwares/nosh/guide/commands/setlock.xml to discuss this in more detail than it previously did. Then along came Joseph Holsten, author of another flock(1) utility, contacting me to throw the cat amongst the pigeons. (See https://mstdn.social/@josephholsten/110343362815736310 https://mstdn.social/@josephholsten/110343362815736310 .)

by JdeBP 3y ago

wahern 3y ago

For all the dangerous qualities of classic POSIX/SysV locks, they're in service of one key characteristic[1]: only a single process can hold a lock, which means you can easily identify and communicate with the lock-holding process, such as by querying for and sending a signal to the PID (ignoring NFS, which came along later). With BSD descriptor locks, multiple processes can and often invariably do hold the lock, by holding dup'd references to the same open file table entry. [1] Maybe this could have been achieved with better semantics, but my guess is the semantics follow from a very straight-forward implementation given the classic 3-level Unix file model of per-process descriptor tables, global open file table, and global open inode table, where you just hang the lock index off of the global open inode table, without any back referencing to the higher-level tables, notwithstanding recording of the lock owner PID. SysV mandatory locking perhaps also figured into this design and the semantics.

Joker_vD 3y ago
IIRC the initial implementation of what became POSIX locks was cobbled together in a weekend just so that the author could submit something to the POSIX group but then apparently nobody else did, or bothered to read/argue, so it got standardized as-is, with all of its unfortunate implications.
JdeBP 3y ago
That's certainly the implementation, v_filocks. But I'd be wary of saying that the implementation drove the design. Remember that people have historically disagreed about synchronization mechanisms and which ones are the good ones. It's quite possible that the design was simply intentionally that way, not following from any implementation considerations. For example: Dave Cutler architect of Windows NT called the OS/2 mutex mechanism a "mutant" because xe thought the semantics were bad. But the semantics that xe didn't like were designed so that a locking thread was told whenever the preceding mutex owner lost the lock because it ABENDed, and that thus whatever the mutex was guarding was probably not in a consistent unlocked state. One has only to cast one's mind back to how file sharing flags worked, or just didn't work, on MS/PC/DR-DOS when they first came along (Hands up if you remember compatibility mode sharing, or Netware's added spin to the whole thing.) to be reminded that sometimes design was just odd, by today's standards. (-: By the way: NFS began in 1984 and was available for AT&T Unix System 5 Release 2. File locking with lockf()/fcntl() dates from AT&T Unix System 5 Release 3 which was actually later, not earlier. Also remember that System 5 Release 3 at the same time introduced RFS, which did do locking and statefully maintained open file descriptions on the server, so the idea of the PID being accessible is a bit of a red herring.

JdeBP 3y ago

I thought that I was done when I augmented https://jdebp.uk/Softwares/nosh/guide/commands/setlock.xml https://jdebp.uk/Softwares/nosh/guide/commands/setlock.xml to discuss this in more detail than it previously did. Then along came Joseph Holsten, author of another flock(1) utility, contacting me to throw the cat amongst the pigeons. (See https://mstdn.social/@josephholsten/110343362815736310 https://mstdn.social/@josephholsten/110343362815736310 .)