fcntl，lockf，哪个更好用于文件锁定？ [英] fcntl, lockf, which is better to use for file locking?
问题描述
寻找有关 用于文件锁定。例如哪个更好地用于可移植性？我正在编写一个linux守护进程，想知道哪个更适合用于强制互斥。
Looking for information regarding the advantages and disadvantages of both fcntl and lockf for file locking. For example which is better to use for portability? I am currently coding a linux daemon and wondering which is better suited to use for enforcing mutual exclusion.
推荐答案
lockf和fcntl之间的区别：
在许多系统上， lockf（）库例程是只是围绕 fcntl（）的包装器。也就是说 lockf 提供 fcntl 的功能的一部分。
On many systems, the lockf() library routine is just a wrapper around fcntl(). That is to say lockf offers a subset of the functionality that fcntl does.
但是在某些系统上， fcntl 和 lockf 独立。
But on some systems, fcntl and lockf locks are completely independent.
Source
由于依赖于实现，请务必始终使用相同的约定。所以要么总是使用lockf从两个进程或总是使用fcntl。有很好的机会，它们是可以互换的，但使用相同的更安全。
Since it is implementation dependent, make sure to always use the same convention. So either always use lockf from both your processes or always use fcntl. There is a good chance that they will be interchangeable, but it's safer to use the same one.
你选择哪一件都不重要。
Which one you chose doesn't matter.
有关强制性vs咨询锁的注意事项：
默认情况下，锁定unix / linux advice ，这意味着其他进程不需要遵循设置的锁定规则。所以你锁定的方式并不重要，只要您的合作过程也使用相同的约定。
Locking in unix/linux is by default advisory, meaning other processes don't need to follow the locking rules that are set. So it doesn't matter which way you lock, as long as your co-operating processes also use the same convention.
Linux确实支持强制性锁定，但只有当您的文件系统安装了选项，并且设置了文件特殊属性。您可以使用 mount -o mand 挂载文件系统，并设置文件属性 gx，g + s 以启用强制锁，然后使用 fcntl 或 lockf 。有关强制锁如何工作的更多信息，请参阅 here 。
Linux does support mandatory locking, but only if your file system is mounted with the option on and the file special attributes set. You can use mount -o mand to mount the file system and set the file attributes g-x,g+s to enable mandatory locks, then use fcntl or lockf. For more information on how mandatory locks work see here.
请注意，锁不适用于单个文件，而是应用于inode。这意味着指向相同文件数据的两个文件名将共享相同的锁定状态。
Note that locks are applied not to the individual file, but to the inode. This means that 2 filenames that point to the same file data will share the same lock status.
另一方面，在Windows中，您可以主动专门打开一个文件，这将阻止其他进程完全打开。即使他们想要。即，锁是强制性的。 Windows和文件锁也是如此。具有适当访问权限的打开文件句柄的任何进程都可以锁定文件的一部分，而其他进程将无法访问该部分。
In Windows on the other hand, you can actively exclusively open a file, and that will block other processes from opening it completely. Even if they want to. I.e., the locks are mandatory. The same goes for Windows and file locks. Any process with an open file handle with appropriate access can lock a portion of the file and no other process will be able to access that portion.
Linux中强制性的锁如何工作：
关于强制性锁定，如果进程使用读取锁定文件的区域，则允许其他进程读取但不写入该区域。如果进程使用写入锁定文件的区域，则不允许其他进程读取或写入该文件。当进程不允许访问文件的一部分时会发生什么，这取决于您是否指定了 O_NONBLOCK 。如果设置了阻塞，它将等待执行该操作。如果没有设置阻塞，您将收到错误代码 EAGAIN 。
Concerning mandatory locks, if a process locks a region of a file with a read lock, then other processes are permitted to read but not write to that region. If a process locks a region of a file with a write lock, then other processes are not permitted to read nor write to the file. What happens when a process is not permitted to access the part of the file depends on if you specified O_NONBLOCK or not. If blocking is set it will wait to perform the operation. If no blocking is set you will get an error code of EAGAIN.
NFS警告：
如果您在NFS挂载上使用锁定命令，请小心。行为是未定义的，并且实现方式广泛变化，不管是仅使用本地锁还是支持远程锁定。
Be careful if you are using locking commands on an NFS mount. The behavior is undefined and the implementation widely varies whether to use a local lock only or to support remote locking.
这篇关于fcntl，lockf，哪个更好用于文件锁定？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
