As in GNU C Library documentation
fcntl(F_OFD_SETLK)
locks on an open file table entry, (usually obtained by open()
). Easy to understand.
But in the next example in same documentation:
In the example process, each thread calls open()
, so each file descriptor should point to a different open file table entry.
If the lock acquired from fcntl(fd, F_OFD_SETLKW, &lck) in each thread is associated with a new open file table entry, then each thread is getting a lock on this new open file table entry returned by open() in each thread.
Then how could the locks on different file table entries provide exclusive write access?
What am I missing?
Original POSIX file locks where per-process locks. As a result, if two threads opened the same file, resulting in different file descriptors, they both could obtain exclusive locks at the same time (because the process was considered the lock owner). These semantics (combined with the
close
behavior) are fairly useless, but could not be changed for backwards compatibility reasons.Hence the need for the separate OFD lock
fcntl
operations, which behave as if then files were opened in separate processes using traditional POSIX locks. In both cases, the kernel has to determine the underlying file object/inode and lock on that; locking on a file descriptor or file description is insufficient. Or put differently, the difference between POSIX and OFD locks is that POSIX locks can piggyback on a lock which has already been acquired by the process (a bit similar to recursive mutexes, but not quite), while for OFD locks, the calling thread is the lock owner. But the actual locks is always performed on the file.