3 ms·

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

by 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.

by wahern 3y ago

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.