的fcntl，提供lockf，这是更好地使用文件锁定？ [英] fcntl, lockf, which is better to use for file locking?
问题描述
寻找信息，关于两者的优点和劣势 的fcntl 的和的了lockf 的作为文件锁定。例如这是更好地使用便携性？我目前编码一个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.
既然是依赖于实现，确保始终使用相同的约定。因此，要么总是从两个您的流程使用了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操作系统锁定默认情况下的咨询，这意味着其他进程并不需要遵循设置加锁规则。所以，问题不在于你锁定哪种方式，只要您共同操作流程也使用相同的约定。
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命令挂载文件系统并设置文件属性G-X，G + S，使强制性锁，然后使用的fcntl或提供lockf。有关强制锁的工作原理在这里看到 更多信息。
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。这意味着，2名指向同一文件数据将共享相同的锁定状态。
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的错误code。
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屋！
