glibc中flock()和fcntl()语义的比较

3

相关:一个两个

有人说,flock()(BSD-locks)和fcntl()(POSIX record-level locks)给用户提供了不兼容的语义,特别是在锁释放方面。

然而,在glibc中,flock()是基于POSIX fcntl()实现的。(我在官方git repo上检查了这一点,这里只是可查看的链接)

https://code.woboq.org/userspace/glibc/sysdeps/posix/flock.c.html#18

/* This file implements the flock' function in terms of the POSIX.1fcntl' locking mechanism. In 4BSD, these are two incompatible locking mechanisms, perhaps with different semantics? */

如何理解这些事实呢?

2个回答

3
在Linux上,flock是一个系统调用flock锁和fcntl锁是独立的,在本地文件系统上不会互相干扰。 sysdeps/posix/flock.c这个glibc源文件实际上在Linux上并没有使用。真正的实现是从sysdeps/unix/sysv/linux/syscalls.list中生成的系统调用包装器。
flock             -       flock           i:ii    __flock         flock

OFD锁是另一种锁,但它们与POSIX记录锁交互。然而,它们在多线程方面具有更合理的行为,并且关闭一个描述符不会释放由同一进程持有的相同底层文件的所有锁(这使得在多线程进程中使用POSIX记录锁非常困难)。


0

注意。这是完全错误的,参见已接受的答案。仍然保持活跃,因为它有一些有用的链接

好吧,这很乏味 - fcntl使用相同的flock结构作为参数,并基于l_pid字段值区分打开文件锁定(在上面我的符号中为BSD锁定)和进程关联的文件锁定(在上面我的符号中为POSIX记录级锁定)。

{{link1:glibc文档关于打开文件描述符锁定}}

打开文件描述符锁使用与进程相关锁相同的结构体flock作为参数(请参阅文件锁),并且命令值的宏也在头文件fcntl.h中声明。要使用它们,必须在包含任何头文件之前定义宏_GNU_SOURCE。
与进程相关锁不同,用作打开文件描述符锁命令参数的任何struct flock都必须将l_pid值设置为0。此外,在F_GETLK或F_OFD_GETLK请求中返回有关打开文件描述符锁的信息时,struct flock中的l_pid字段将设置为-1,以指示该锁未与进程关联。
另请参见glibc文档中有关进程相关文件锁的glibc doc on process-associated file locks

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接