fcntl、lockf，哪个更适合用于文件锁定？

问题描述：

寻找有关fcntl和lockf在文件锁定方面的优缺点的信息。例如，哪个更适合于可移植性？我目前正在编写一个 Linux 守护进程，想知道哪个更适合用于强制互斥。

解决方案 1：

lockf 和 fcntl 有什么区别：

在许多系统上，lockf()库例程只是 的包装器fcntl()。也就是说，lockf它只提供了 的部分功能fcntl。

来源

但在某些系统上，fcntl锁lockf是完全独立的。

来源

由于它依赖于实现，因此请确保始终使用相同的约定。因此，要么始终在两个进程中使用 lockf，要么始终使用 fcntl。它们很有可能可以互换，但使用同一个更安全。

选择哪一个并不重要。

关于强制锁和咨询锁的一些注释：

unix/linux 中的锁定默认为建议性的，这意味着其他进程不需要遵循设置的锁定规则。因此，只要您的协作进程也使用相同的约定，您以哪种方式锁定都没有关系。

Linux 确实支持强制锁定，但前提是您的文件系统在安装时启用了选项并且设置了文件特殊属性。您可以使用mount -o mand来安装文件系统并设置文件属性g-x,g+s以启用强制锁定，然后使用fcntl或lockf。有关强制锁定如何工作的更多信息，请参阅此处。

请注意，锁定不是应用于单个文件，而是应用于 inode。这意味着指向相同文件数据的两个文件名将共享相同的锁定状态。

另一方面，在 Windows 中，您可以主动以独占方式打开文件，这将阻止其他进程完全打开它。即使他们想这样做。也就是说，锁定是强制性的。Windows 和文件锁定也是如此。任何具有打开文件句柄并具有适当访问权限的进程都可以锁定文件的一部分，并且其他任何进程都无法访问该部分。

强制锁在 Linux 中的工作原理：

关于强制锁，如果一个进程用读锁锁定了文件的某个区域，那么其他进程可以读取但不能写入该区域。如果一个进程用写锁锁定了文件的某个区域，那么其他进程则不能读取或写入该文件。当进程不被允许访问文件的一部分时会发生什么取决于您是否指定O_NONBLOCK。如果设置了阻塞，它将等待执行操作。如果没有设置阻塞，您将收到错误代码EAGAIN。

NFS 警告：

如果您在 NFS 挂载上使用锁定命令，请务必小心。该行为尚未定义，并且实现方式存在很大差异，是仅使用本地锁定还是支持远程锁定。

解决方案 2：

这两种接口都是 POSIX 标准的一部分，如今大多数系统上都提供这两种接口（我刚刚检查了 Linux、FreeBSD、Mac OS X 和 Solaris）。因此，选择更适合您要求的那个并使用它。

需要注意的是：当一个进程使用 fcntl 锁定文件而另一个进程使用 lockf 锁定文件时，具体会发生什么情况尚不明确。在大多数系统中，这些操作是等效的（实际上，在 Linux 下 lockf 是在 fcntl 之上实现的），但 POSIX 表示它们的交互方式尚不明确。因此，如果您要与使用这两个接口之一的另一个进程进行交互，请选择同一个接口。

其他人写道，锁定只是建议性的：您有责任检查某个区域是否被锁定。另外，如果您希望使用锁定功能，请不要使用 stdio 函数。

解决方案 3：

在这种情况下（即“编写 Linux 守护进程并想知道哪个更适合用于强制互斥”），您主要关心的应该是：

1. 锁定的文件是本地的还是可以在 NFS 上？

* 例如，用户是否可以诱骗您在 NFS 上创建并锁定守护进程的 pid 文件？

1. fork当守护进程以极端不利的方式终止时，锁将如何表现kill -9？

flock在两种情况下，和命令fcntl的行为有所不同。

我的建议是使用fcntl。您可以参考 Wikipedia 上的文件锁定文章，深入讨论这两种解决方案所涉及的问题：

flock 和 fcntl 都有一些怪癖，有时会让其他操作系统的程序员感到困惑。flock 锁是否适用于网络文件系统（如 NFS），取决于实现。在 BSD 系统上，flock 调用是成功的无操作。在 Linux 2.6.12 之前的版本中，对 NFS 文件的 flock 调用只会在本地执行。内核 2.6.12 及更高版本使用 POSIX 字节范围锁实现对 NFS 文件的 flock 调用。这些锁对于实现 fcntl()/POSIX 锁的其他 NFS 客户端可见。1锁升级和降级在应用新锁之前释放旧锁。如果应用程序将独占锁降级为共享锁，而另一个应用程序被阻止等待独占锁，则后一个应用程序将获得独占锁，而第一个应用程序将被锁定。当给定进程关闭该文件的任何文件描述符时，与该文件相关联的所有 fcntl 锁都将被删除，即使从未为该文件描述符请求锁。此外，子进程不会继承 fcntl 锁。对于调用可能访问文件的子程序库的应用程序来说，fcntl close 语义尤其麻烦。

解决方案 4：

我最近在使用 fcntl 和 flock 时遇到了一个问题，我觉得我应该在这里报告，因为搜索任何一个术语都会在两者的顶部附近显示此页面。

请注意，如上所述，BSD 锁是建议性的。对于那些不知道 OSX（darwin）是 BSD 的人来说。打开要写入的文件时必须记住这一点。

要使用 fcntl/flock，您必须先打开文件并获取其 ID。但是，如果您使用“w”打开文件，则文件将立即清零。如果您的进程随后无法获取锁定，因为文件正在其他地方使用，则它很可能会返回，使文件保留为 0kb。拥有锁定的进程现在会发现文件已从其下方消失，通常会导致灾难性后果。

为了解决这种情况，使用文件锁定时，切勿打开文件“w”，而是打开“a”进行追加。然后，如果成功获取锁定，则可以像“w”一样安全地清除文件，即：

fseek(fileHandle, 0, SEEK_SET);//移动到开始处

ftruncate(fileno((FILE *) fileHandle), 0);//清除它

这对我来说是一次不愉快的教训。

解决方案 5：

由于您仅编写了一个使用它来互斥的守护进程，所以它们是等效的，毕竟您的应用程序只需要与自身兼容。

文件锁定机制的诀窍是保持一致 - 使用一种机制并坚持使用。改变机制不是一个好主意。

我在这里假设文件系统将是本地的 - 如果不是，那么所有的赌注都是无效的，NFS /其他网络文件系统以不同程度的有效性处理锁定（在某些情况下没有）