Linux下fcntl/flock文件锁获取呈现FIFO特性问题咨询

你观察到的排他文件锁按FIFO顺序分配的现象不是代码问题，是Linux内核的默认实现特性，具体说明如下：

• POSIX标准本身确实没有对文件锁的唤醒顺序做强制规定，你最初认为标准未明确、分配顺序随机的认知是符合规范定义的，该行为属于操作系统的实现定义范畴。
• Linux内核从2.6版本开始，对flock文件锁和fcntl实现的POSIX记录锁的等待队列都默认采用FIFO调度策略：普通非实时进程请求排他锁时，会严格按照进入等待队列的先后顺序被唤醒获取锁，只有当进程设置了不同的调度优先级（比如实时调度策略、调整nice值）时，才可能打破FIFO顺序。
• 你提供的测试代码逻辑是正确的：

#include <sys/file.h>
#include <fcntl.h>
#include <string.h>
#include "tlpi_hdr.h"

char *currTime(const char *format);

int main(int argc, char *argv[])
{
    int fd;
    struct flock fl;

    fd = open("./file", O_RDWR); /* Open file to be locked */
    if (fd == -1)
        errExit("open");

    fl.l_len = 0;
    fl.l_start = 0;
    fl.l_whence = SEEK_SET;
    fl.l_type = F_WRLCK;

    if (fcntl(fd, F_SETLKW, &fl) == -1)
    {
        if (errno == EAGAIN || errno == EACCES)
            printf("already locked");
        else if (errno == EDEADLK)
            printf("dead lock");
        else
            errExit("fcntl");
    }
    else
        printf("PID %ld: have got write lock at %s\n", (long)getpid(), currTime("%T"));

    sleep(atoi(argv[1]));

    exit(EXIT_SUCCESS); // close fd and this cause unlock flock's lock
}

你测试的场景都是排他写锁请求，没有读写锁混合的情况，因此完全匹配Linux内核的FIFO调度逻辑，多次测试结果一致是正常现象。

• 额外说明：仅在存在混合读写锁请求的场景下，部分旧版本内核可能存在读锁优先的策略，会打破纯FIFO顺序，但你当前的纯写锁测试场景不会触发该逻辑。

你测试过程中观察到的现象参考图：

内容的提问来源于stack exchange，提问作者february