python lockf和flock行为

Question

关于flock/lockf/fcntl 之间的区别，我已经阅读了足够多关于stackoverflow 的帖子，但我无法回答以下观察：

>>> import fcntl
>>> a = open('/tmp/locktest', 'w')
>>> b = open('/tmp/locktest', 'w')
>>> fcntl.lockf(a, fcntl.LOCK_EX | fcntl.LOCK_NB)
>>> fcntl.lockf(a, fcntl.LOCK_EX | fcntl.LOCK_NB)
>>> fcntl.lockf(b, fcntl.LOCK_EX | fcntl.LOCK_NB)
>>>
>>> a.close()
>>> b.close()

>>> a = open('/tmp/locktest', 'w')
>>> b = open('/tmp/locktest', 'w')
>>> fcntl.flock(a, fcntl.LOCK_EX | fcntl.LOCK_NB)
>>> fcntl.flock(a, fcntl.LOCK_EX | fcntl.LOCK_NB)
>>> fcntl.flock(b, fcntl.LOCK_EX | fcntl.LOCK_NB)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 35] Resource temporarily unavailable

为什么这两种情况的行为不同？我知道显而易见的答案是，这是两种不同的锁定机制。我正在寻找：

1. 实际上lockf() 或flock() 对文件 (inode/fd) 做了什么？
2. 根据演示，我们是否允许递归获取相同的锁？

我了解fds 的基础知识和其他内容，因此我希望获得对操作系统级别细节有更多见解的技术答案。

OSX 10.9.3，Python：2.7.5

Answer 1

一篇关于这个的好文章： On the Brokenness of File Locking

简而言之：

• POSIX 锁：

  lockf() 大多数时候只是作为 fcntl() 的一个接口实现

  fcntl() 锁绑定到进程，而不是文件描述符。 如果一个进程对特定文件有多个打开的文件描述符，则这些用于获取锁定的文件描述符中的任何一个都将RESET锁定。

• BSD 锁：

  flock() 锁绑定到文件描述符，而不是进程。

此外

一个很好的测试分析： Advisory File Locking – My take on POSIX and BSD locks

摘要摘录：

• fcntl 和flock 样式锁彼此完全正交。任何同时提供两者的系统（Linux 提供）都将独立处理通过它们中的每一个获得的锁。
• 当进程退出或中止时，POSIX 和 BSD 锁都会自动释放。
• POSIX 和 BSD 锁在 execve 调用中都会保留，除非进程设置了 FD_CLOEXEC 标志，强制关闭文件描述符，并且不被新进程继承。