如果lockf与0偏移一起使用,那么在独占模式下使用flock和之间有什么区别lockf？
我问,因为我正在阅读基于平台有条件地编译这两个函数中的任何一个的代码,我想了解可能的原因.
Nom*_*mal 40
flock()和之间的实际区别在于lockf()语义(关闭和传递的行为),对NFS和其他共享文件系统的适用性,以及使用fcntl()锁是否对其他进程可见的咨询锁.
您正在使用的库只具有逻辑,可以根据当前平台选择所需的语义.
如果语义(描述符传递,分叉等行为)是可接受的,你应该更喜欢lockf()/ fcntl()锁定flock()Linux中的锁,因为前者适用于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挂载上工作(显然,只有当NFS客户端和服务器都配置为支持记录锁定时才会这样做,这在例如Web托管环境中非常罕见;一些Web(框架)开发人员头痛的一个巨大原因) ).
POSIX没有明确指定lockf()/ flock()/ fcntl()lock应该如何交互,并且过去存在差异.现在,情况已经平静下来,人们可以大致说出来
fcntl() 锁是最可靠的
在整个架构中,他们最有可能在共享文件系统上工作 - 例如,NFS和CIFS安装.
大多数情况下,lockf()实施为"速记"fcntl()
另一种选择,作为"速记" flock(),是可能的,但现在很少见.
fcntl()并且flock()有不同的语义.继承和自动释放
fcntl()锁被保留在一个exec(),但不是跨越一个fork().当拥有进程关闭引用同一文件的任何描述符时,将释放锁.
在Linux,FreeBSD和MAc OS X中,flock()锁与开放文件描述符耦合:传递描述符也会传递锁.(手册页指出"锁定在文件上,而不是在文件描述符上".这不是一个矛盾.它只是意味着锁应用于文件.它仍然以这种方式耦合到描述符复制描述符也会传递相同的锁.)因此,如果多个进程flock()在flock()调用后从发起方获取描述符,则可能同时对同一文件具有相同的独占建议锁.
文件锁定是一个非常复杂的问题.通过坚持fcntl()锁定,我个人获得了最好的结果.语义学.fcntl()锁是最容易使用的,在某些情况下可能是坦率的真气; 只是我发现它能够产生最好 - 最可靠,最便携,最不令人惊讶的结果.