谈谈linux中各式锁

接触kubernetes两年有余，从18年初加入kubernetes社区来算，已经一年半，或许是时候写点什么。简单文章如何写好，难点文章如何写透，或许是一种学问，打算推一个系列：《Kubernetes GO》算是对这两年的一个总结。

首先flock和fcntl是系统调用，而lockf是库函数。lockf实际上是fcntl的封装，所以lockf和fcntl的底层实现是一样的，对文件加锁的效果也是一样的。后面分析不同点时大多数情况是将fcntl和lockf放在一起的。下面首先看每个函数的使用，从使用的方式和效果来看各个函数的区别。

---

1、flock

函数原型

int flock(int fd, int operation);  // Apply or remove an advisory lock on the open file specified by fd，只是建议性锁

其中fd是系统调用open返回的文件描述符，operation的选项有：

1. LOCK_SH ：共享锁
2. LOCK_EX ：排他锁或者独占锁
3. LOCK_UN : 解锁。
4. LOCK_NB：非阻塞（与以上三种操作一起使用）

关于flock函数，首先要知道flock函数只能对整个文件上锁，而不能对文件的某一部分上锁，这是于fcntl/lockf的第一个重要区别，后者可以对文件的某个区域上锁。其次，flock只能产生劝告性锁。我们知道，linux存在强制锁（mandatory lock）和劝告锁（advisory lock）。所谓强制锁，比较好理解，就是你家大门上的那把锁，最要命的是只有一把钥匙，只有一个进程可以操作。所谓劝告锁，本质是一种协议，你访问文件前，先检查锁，这时候锁才其作用，如果你不那么kind，不管三七二十一，就要读写，那么劝告锁没有任何的作用。而遵守协议，读写前先检查锁的那些进程，叫做合作进程。再次，flock和fcntl/lockf的区别主要在fork和dup。

(1)、flock创建的锁是和文件打开表项（struct file）相关联的，而不是fd。这就意味着复制文件fd（通过fork或者dup）后，那么通过这两个fd都可以操作这把锁（例如通过一个fd加锁，通过另一个fd可以释放锁），也就是说子进程继承父进程的锁。但是上锁过程中关闭其中一个fd，锁并不会释放（因为file结构并没有释放），只有关闭所有复制出的fd，锁才会释放。对fd1上锁，并不影响程序通过fd2上锁。子进程持有锁，并不影响父进程通过相同的fd获取锁，反之亦然。


(2)、使用open两次打开同一个文件，得到的两个fd是独立的（因为底层对应两个file对象），通过其中一个加锁，通过另一个无法解锁，并且在前一个解锁前也无法上锁。通过fd1获取锁后，无法再通过fd2获取锁。


(3)、使用exec后，文件锁的状态不变。


(4)、flock不能再NFS文件系统上使用，如果要在NFS使用文件锁，请使用fcntl。


(5)、flock锁可递归，即通过dup或者或者fork产生的两个fd，都可以加锁而不会产生死锁。

2、lockf与fcntl

函数原型

int lockf(int fd, int cmd, off_t len);  // fd为通过open返回的打开文件描述符。

cmd的取值为：

1. F_LOCK：给文件互斥加锁，若文件以被加锁，则会一直阻塞到锁被释放。
2. F_TLOCK：同F_LOCK，但若文件已被加锁，不会阻塞，而回返回错误。
3. F_ULOCK：解锁。
4. F_TEST：测试文件是否被上锁，若文件没被上锁则返回0，否则返回-1。
5. len：为从文件当前位置的起始要锁住的长度。

通过函数参数的功能，可以看出lockf只支持排他锁，不支持共享锁。

文件记录加锁相关的cmd 分三种：

1. F_SETLK：申请锁（读锁F_RDLCK，写锁F_WRLCK）或者释放所（F_UNLCK），但是如果kernel无法将锁授予本进程（被其他进程抢了先，占了锁），不傻等，返回error。
2. F_SETLKW：和F_SETLK几乎一样，唯一的区别，这厮是个死心眼的主儿，申请不到，就傻等。
3. F_GETLK：这个接口是获取锁的相关信息： 这个接口会修改我们传入的struct flock。

通过函数参数功能可以看出fcntl是功能最强大的，它既支持共享锁又支持排他锁，即可以锁住整个文件，又能只锁文件的某一部分。

fcntl/lockf特性

(1) 上锁可递归，如果一个进程对一个文件区间已经有一把锁，后来进程又企图在同一区间再加一把锁，则新锁将替换老锁。


(2) 加读锁（共享锁）文件必须是读打开的，加写锁（排他锁）文件必须是写打开。


(3) 进程不能使用F_GETLK命令来测试它自己是否再文件的某一部分持有一把锁。F_GETLK命令定义说明，返回信息指示是否现存的锁阻止调用进程设置它自己的锁。因为，F_SETLK和F_SETLKW命令总是替换进程的现有锁，所以调用进程绝不会阻塞再自己持有的锁上，于是F_GETLK命令绝不会报告调用进程自己持有的锁。


(4) 进程终止时，他所建立的所有文件锁都会被释放，队医flock也是一样的。


(5) 任何时候关闭一个描述符时，则该进程通过这一描述符可以引用的文件上的任何一把锁都被释放（这些锁都是该进程设置的），这一点与flock不同。


(6) 由fork产生的子进程不继承父进程所设置的锁，这点与flock也不同。


(8) 支持强制性锁：对一个特定文件打开其设置组ID位(S_ISGID)，并关闭其组执行位(S_IXGRP)，则对该文件开启了强制性锁机制。再Linux中如果要使用强制性锁，则要在文件系统mount时，使用_omand打开该机制。

fcntl/lockf关联

flock和lockf/fcntl所上的锁有什么关系呢？答案时互不影响。测试程序如下：

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/file.h>
int main(int argc, char **argv)
{
  int fd, ret;
  int pid;
  fd = open("./tmp.txt", O_RDWR);
  ret = flock(fd, LOCK_EX);
  printf("flock return ret : %dn", ret);
  ret = lockf(fd, F_LOCK, 0);
  printf("lockf return ret: %dn", ret);
  sleep(100);
  return 0;
}

测试结果如下：

$./a.out
flock return ret : 0
lockf return ret: 0

可见flock的加锁，并不影响lockf的加锁。另外我们可以通过/proc/locks查看进程获取锁的状态。

$ps aux | grep a.out | grep -v grep
123751   18849  0.0  0.0  11904   440 pts/5    S+   01:09   0:00 ./a.out
$sudo cat /proc/locks | grep 18849
1: POSIX  ADVISORY  WRITE 18849 08:02:852674 0 EOF
2: FLOCK  ADVISORY  WRITE 18849 08:02:852674 0 EOF

我们可以看到/proc/locks下面有锁的信息：我现在分别叙述下含义：

(1) POSIX FLOCK 这个比较明确，就是哪个类型的锁。flock系统调用产生的是FLOCK，fcntl调用F_SETLK，F_SETLKW或者lockf产生的是POSIX类型，有次可见两种调用产生的锁的类型是不同的；


(2) ADVISORY表明是劝告锁；


(3) WRITE顾名思义，是写锁，还有读锁；


(4) 18849是持有锁的进程ID。当然对于flock这种类型的锁，会出现进程已经退出的状况。


(5) 08:02:852674表示的对应磁盘文件的所在设备的主设备好，次设备号，还有文件对应的inode number。


(6) 0表示的是所的其实位置


(7) EOF表示的是结束位置。 这两个字段对fcntl类型比较有用，对flock来是总是0 和EOF。

---

后续

该文为kubelet相关内容的铺垫，涉及到kubelet对于锁的使用。

---

参考资料

• 锁相关概念