linux 文件锁flock,lockf,fcntl

1、flock，lockf，fcntl之间区别

　　先上结论：flock是文件锁，锁的粒度是整个文件，就是说如果一个进程对一个文件加了LOCK_EX类型的锁，别的进程是不能对这个文件加锁的。

　　lockf是对fcntl的封装，这两个东西在内核上的实现是一样的。它们的粒度是字节，不同的进程可以对相同的文件不同字节加LOCK_EX类型的锁。

2、linux文件系统

　　在详解锁的实现机制前，我们先来看一下linux文件系统的实现。

 

　　相信大家都看过这样一副图。与进程相关的是文件描述符表，文件表和i-node都是系统级别的。当我们在进程中打开一个文件时，文件描述符里就会产生一个文件描述符表项与之对应，同样的系统内也会有文件句柄和相应的i-node,我们需要注意的是多个文件表项（同一个进程或不同进程）可以指向同一个文件句柄。

2、 flock锁的实现机制

　　flock在实现上关联到的是文件描述符（上图中文件描述符部分），这就意味着如果我们在进程中复制了一个文件描述符，那么使用flock对这个描述符加的锁也会在新复制出的描述符中继续引用。我们可以写如下代码测试：

#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/file.h>
#include <wait.h>
#define PATH "/tmp/lock"
int main()
{
    int fd;
    pid_t pid;
    fd = open(PATH, O_RDWR | O_CREAT | O_TRUNC, 0644);
    flock(fd, LOCK_EX);
    printf("%d: locked!\n", getpid());
    pid = fork();
    if (pid == 0) {
        // fd = open(PATH, O_RDWR|O_CREAT|O_TRUNC, 0644);
        flock(fd, LOCK_EX);
        printf("%d: locked!\n", getpid());
        exit(0);
    }
    wait(NULL);
    unlink(PATH);
    exit(0);
}

输出结果：

Sangfor:aCMP/acmp-fefcfe3a1674 ~/test o ./a.out 
118333: locked!
118334: locked!

由结果可见，父进程已经持有互斥锁的情况下，子进程应该对文件加锁失败才符合我们的预期。但是子进程确加锁成功。原因就在于flock的实现是关联文件描述符。

子进程由父进程创建，子进程的文件描述符表和父进程的一模一样，在fork()子进程后，子进程本身就持有该文件的互斥锁。同样的道理，对文件描述符dup(), dup2()都会有这样的问题。怎么解决这个问题呢？

1、重新open这个文件，使用新的文件描述符

fd = open(PATH, O_RDWR|O_CREAT|O_TRUNC, 0644);

我们将上述注释掉的代码打开，重新编译执行，输出结果如下：

Sangfor:aCMP/acmp-fefcfe3a1674 ~/test o ./a.out 
172199: locked!

这次子进程没有能上锁，重新open这个文件会创建一个新的文件描述符与父进程进程而来的描述符是不相关的，所以就符合我们预期的效果。

另外要注意：除非文件描述符被标记了close-on-exec标记，flock锁和lockf锁都可以穿越exec，在当前进程变成另一个执行镜像之后仍然保留。

3、lockf的实现机制

　　lockf的实现是关联到内核i-node的（上图内核部分），每次加锁都会在i-node节点上挂一个flock的结构：

  struct flock 
  {
      short l_type;/*F_RDLCK, F_WRLCK, or F_UNLCK*/
      off_t l_start;/*相对于l_whence的偏移值，字节为单位*/
      short l_whence;/*从哪里开始：SEEK_SET, SEEK_CUR, or SEEK_END*/
      off_t l_len;/*长度, 字节为单位; 0 意味着缩到文件结尾*/
      pid_t l_pid;/*returned with F_GETLK*/
  };

　　对LOCK_EX类型的锁来说，内核中最多只有一份这样的数据，所以即使文件描述符是从父进程进程过来或dup()产生的，对同一个节点加锁都会失败。我们写如下代码测试一下：

#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/file.h>
#include <wait.h>
#define PATH "/tmp/lock"

int main()
{
    int fd;
    pid_t pid;
    fd = open(PATH, O_RDWR | O_CREAT | O_TRUNC, 0644);
    lockf(fd, F_LOCK, 0);
    printf("%d: locked!\n", getpid());

    pid = fork();
    if (pid == 0) {
        lockf(fd, F_LOCK, 0);
        printf("%d: locked!\n", getpid());
        exit(0);
    }
    wait(NULL);
    unlink(PATH);
    exit(0);
}

执行结果：

Sangfor:aCMP/acmp-fefcfe3a1674 ~/test o ./a1.out 
47087: locked!

这次我们没有对文件重新open，子进程就一直等在那里。完全符合我们的预期。这也印证了lockf的实现是内核中i-node相关的。

 

此外有一篇文章介绍建议性锁和强制性锁，这篇文章是以flock为例说明的，flock和lockf的加锁规则是一致的。需要了解加锁规则请参看：

强制性锁和建议锁