有没有大神了解 Linux 中创建文件当做锁有什么特点

[blueberryman]

我今天看到一种写法，创建了一个文件当做锁。这种写法相比管道，信号有什么优缺点呢？为啥我们自己写，包括面试官面试从没有遇到过这种答案啊～谢谢各位大佬了～～～

[tabris17]

@blueberryman 那就是用来当作开关配置了，偷懒罢了

[wd]

@blueberryman #17 不是互斥 比如程序 1 中间会产出一些数据 程序 2 运行到一定程度会需要 那这两个程序要么串行运行 肯定能保证程序 2 依赖的数据都有 要么通过这样的文件来通知程序 2 数据好了

[zjqzxc]

如果见过有人拿文件做 RPC 的话，就淡定了

[momocraft]

pid file 僅僅提供 (基於君子協定的) 互斥, 以及聲明創建者的 pid (如果使用者正確地把 pid 寫入文件).

功能顯然不能和管道信號量比較, 更多是個習慣用法. 但是簡單可移植.

[feather12315]

推荐一篇文章： https://gavv.github.io/articles/file-locks/

[blueberryman]

@momocraft 那管道也是个文件，移植效果会差很多吗？

[blueberryman]

@FrankHB 多谢大佬，不过我们关心的只是是否有这个文件，linux 下管道也是个文件，这个文件是 open 创建的还是管道创建的有影响吗？我的意思是管道的移植性会很差吗？

[swulling]

file lock 对多进程生效呗，单机其他的方法都挺麻烦的

[codeyung]

文件锁 单机 比如你定时多进程跑相同的东西 加个判断上锁了别的进程就自己关闭 保证进程的顺序执行

[momocraft]

> #27
不知道, 我沒有像你說的那樣用過管道文件, 不知道你這樣做是否正確.
"簡單可移植" 的意思是說 pid file 這個做法僅需要相當於 open + O_CREAT + O_EXCL 的 api. 我甚至不知道其他 os 有沒有管道.

[dusu]

flock 真的能用做锁？我试过网上 n 多 flock 当锁的示例代码，多进程跑的时候几乎没一个能用的。当然，也有可能我用法和理解有误，也建议楼主深度测试下；

如果能用的话，除了没法分布式的致命弱点外，小项目还是可以考虑一下的。

P.S. 早上 redis 早真香

[jinliming2]

flock 就是不关心文件内容的吧？只要一个空文件然后独占打开就行了。
pid file 是用来跟踪进程 ID 的吧，貌似跟锁没太大关系，可能用于防止多开。

[dangyuluo]

flock 这个东西只能当作简单的锁，比如禁止两次 nightly 备份同时进行。真要做多线程锁的话，flock 缺乏`test_and_set`这个重要的原子操作。

[blueberryman]

@dusu 好哒，lz 这两天双系统一直丢引导，过几天好了就测～

[maxbon]

我知道楼主说的写法是什么样子的，下面这种对吧，
```shell
[ -f /tmp/lock.file ] && exit
echo $$ > /tmp/lock.file
sleep 1
[ "x$(cat /tmp/lock.file)" == "x"$$ ] || exit
echo OK
rm -f /tmp/lock.file
```

[FrankHB]

@blueberryman 可移植性是相对而言，POSIX 环境你要折腾基本上不用考虑区别，但没 POSIX 原生支持就可能有问题。像 Windows 下没直接对应管道文件的东西，Windows 的管道不共享 Win32 文件系统命名空间（一般应用没事也不会折腾 NT 命名空间），自然可移植性就差。
如果是普通的文件，直接标准 C 的 API 可能都够用——创建文件有 C11 的 'x' mode 支持下 fopen 都够了。虽然 stdio 的缓冲是多余的，但考虑应用都能容忍 shell 的性能的场景这个不是什么大问题——只不过实际情况是，就 Windows 对 C 的支持，还不如直接 open 了。当然，微软默认还不想让你用 open （没 deprecated 的是 _open ），这个另说。
实际的主要问题是，既然说白了只是想要在 VFS 里有个占位符，没需求非得用特殊文件，干嘛那么麻烦特意用管道文件？