Linux上的flock vs lockf答案

【问题标题】：flock vs lockf on LinuxLinux上的flock vs lockf
【发布时间】：2014-03-14 15:48:08
【问题描述】：

如果lockf 与0 偏移一起使用，flock 和lockf 在独占模式下有什么区别（如果有）？

我之所以问，是因为我正在阅读基于平台有条件地在这两个函数中的任何一个中编译的代码，我想了解可能的原因。

【问题讨论】：

【解决方案1】：

flock() 和 lockf() 之间的实际区别在于语义（关于关闭和传递的行为）、对 NFS 和其他共享文件系统的适用性以及使用 fcntl() 的其他进程是否可以看到咨询锁锁与否。

您使用的库仅具有根据当前平台选择所需语义的逻辑。

如果语义（描述符传递、分叉等的行为）是可以接受的，你应该更喜欢lockf()/fcntl() 锁定而不是flock() 锁定，因为前者适用于 NFS 等文件系统，而后者没有。（在 BSD 和 Mac OS X 上，我认为您需要明确使用 fcntl()。）

在 Linux 中，lockf() 只是 fcntl() 的包装，而 flock() 锁是独立的（并且仅适用于本地文件系统，而不适用于例如 2.6.12 之前的内核上的 NFS 挂载）。也就是说，一个进程可以在文件上拥有咨询排他性flock() 锁定，而另一个进程在同一文件上拥有咨询排他性fcntl() 锁定。两者都是咨询锁，但它们不交互。

在Mac OS X 和FreeBSD 上，lockf()/flock()/fcntl() 锁定所有交互，但建议开发人员在应用程序中仅使用其中一个接口。然而，只有fcntl() 锁在NFS mounts 上有效（而且，显然，只有当 NFS 客户端和服务器都已配置为支持记录锁时，这在例如 web 托管环境中非常罕见；对于某些 web 来说，这是一个令人头疼的巨大原因（框架）开发人员）。

POSIX 没有明确指定lockf()/flock()/fcntl() 锁应该如何交互，过去也存在差异。现在，局势已经缓和了一些，可以大概这么说

fcntl()锁是最可靠的

跨架构，他们最有可能在例如共享文件系统——例如 NFS 和 CIFS 挂载。
大多数情况下，lockf() 被实现为fcntl() 的“简写”

另一种选择，作为flock() 的“简写”，是可能的，但现在很少见。
fcntl() 和 flock() 具有不同的语义。继承和自动发布

fcntl() 锁在exec() 中保留，但不会在fork() 中继承。当拥有进程关闭引用同一文件的任何描述符时，锁将被释放。

在 Linux、FreeBSD 和 MAC OS X 中，flock() 锁与打开的文件描述符相结合：传递描述符也会传递锁。（手册页声明 “锁在文件上，而不是在文件描述符上”。这并不矛盾。它只是意味着锁 应用于文件。它仍然与描述符耦合，这样复制描述符也传递相同的锁。）因此，可能多个进程在同一文件上具有相同的独占通知flock()锁同时，如果他们在flock()调用之后从发起者那里获得了描述符。

文件锁定是一个非常复杂的问题。通过简单地坚持fcntl() 锁定，我个人获得了最好的结果。语义wrt。 fcntl() 锁并不是最容易使用的，而且在某些情况下可能会让人生气；只是我发现它可以产生最好的——最可靠、最便携、最不令人惊讶的——结果。

【讨论】：

上述评论的附录：Linux 2.6.12 于 2005 年 6 月 18 日发布，因此即使在回答时，flock() 确实在 NFS 上工作。
@Akilan：哪一部分？不要将flock() 与lockf() 混淆；在没有指出具体问题的情况下发表这样的评论是很可怕的。这就像说你犯了一个错误，却没有指出错误。这不仅没有帮助，而且使语气非常自鸣得意和不友好。我相信您自己只是混淆了 NOTES 部分中的lockf() 和flock()。至于 2.6.12 之前的内核上的 NFS 和 flock()，是的，这确实值得一提，谢谢。
很抱歉不是很清楚。我确实在谈论 NFS。
@Akilan：不，这很清楚。您说“答案不再正确”，但没有指出如何，或哪个部分。如果没有更多细节，我肯定不同意，因为除了提到内核版本之外，我根本看不出我的答案与手册页有何不同。

【解决方案2】：

条件编译最可能的原因是这两个函数都不是在每个平台上都可用。

【讨论】：

这是我最初的想法，检查显示它们都在平台上受支持。不过历史上可能并非如此，所以这似乎是领先者。