文件锁定与信号量

Question

只是出于好奇，在 Linux 上实现进程间同步的首选方法是什么？ sem*(2) 系列系统调用似乎有一个非常笨重且过时的界面，而锁定文件的方法有三种 - fcntl()、flock() 和lockf()。

内部差异是什么（如果有）以及您如何证明每个差异的使用合理性？

Answer 1

两者都不。 pthread_* 的实际版本（例如 phtread_mutex_t）都允许将变量放置在通过 shm_open 创建的共享段中。您只需在 init 调用中添加一些额外的参数即可。

如果没有必要，请不要使用信号量 (sem_t)，它们的级别太低并且会被 IO 等中断。

不要滥用文件锁定来进行进程间控制。它不是为此而设计的。特别是，您无法刷新文件元数据（例如锁），因此您永远不知道锁/解锁何时对第二个进程可见。

Answer 2

正如《DarkDust》指出的那样，你正在经历来自丰富历史的大量选择。对于它的价值，我的决策树是这样的：

当一次只有一个进程/线程可以访问时使用互斥体。

当两个或多个（但仍然有限）进程/线程可以使用资源时使用信号量。

使用 POSIX 信号量，除非您确实需要 SYSV 信号量所具有的功能 - 例如 UNDO、上次操作的 PID 等。

对文件使用文件锁定，或者如果上述内容在某些方面不符合您的要求。

Answer 3

不同的锁定/信号量实现都在不同的系统上实现。在 System V Unix 上，您有 semget/semop，POSIX 使用 sem_init、sem_wait 和 定义了不同的实现>sem_post。据我所知，flock 起源于 4.2BSD。

由于它们都具有一定的重要性，Linux 现在都支持它们以便于移植。此外，flock 是互斥体（锁定或解锁），但 sem* 函数（SysV 和 POSIX）是信号量：它们允许应用程序授予多个并发进程访问，例如，您可以允许 4 个进程使用信号量同时访问资源。您可以使用信号量实现互斥锁，但反之则不然。我记得在 Marc J. Rochkind 的优秀《高级 UNIX 编程》中，他演示了如何通过信号量在进程之间传输数据（非常低效，他这样做只是为了证明可以做到）。但我找不到任何关于效率的可靠信息。

我想这更像是“使用你想要的”。

Answer 4

一个潜在的显着差异可能是资源分配的公平性。我不知道 semget/semop 系列的实现细节，但我怀疑就调度而言，它通常是作为“传统”信号量实现的。一般来说，我认为释放的线程是在 FIFO 的基础上处理的（第一个等待信号量的线程首先被释放）。我认为文件锁定不会发生这种情况，因为我怀疑（再次只是猜测）处理不是在内核级别执行的。

我有现有代码来测试用于 IPC 目的的信号量，因此我比较了两种情况（一种使用 semop，一种使用 lockf）。我做了一个穷人的测试，只是运行到应用程序的实例。共享信号量用于同步启动。运行 semop 测试时，两个进程几乎同步完成了 300 万次循环。另一方面，lockf 循环则不太公平。一个进程通常会完成，而另一个进程只完成一半的循环。

semop 测试的循环如下所示。 semwait 和 semsignal 函数只是 semop 调用的包装器。

   ct = myclock();
   for ( i = 0; i < loops; i++ )
      {
      ret = semwait( "test", semid, 0 );
      if ( ret < 0 ) { perror( "semwait" ); break; }

      if (( i & 0x7f ) == 0x7f )
         printf( "\r%d%%", (int)(i * 100.0 / loops ));

      ret = semsignal( semid, 0 );
      if ( ret < 0 ) { perror( "semsignal" ); break; }
      }
   printf( "\nsemop time: %d ms\n", myclock() - ct );

两种方法的总运行时间大致相同，尽管有时由于调度的不公平，lockf 版本实际上总体上更快。第一个进程完成后，另一个进程将获得约 150 万次迭代的无竞争访问权限，并且运行速度极快。

当无竞争运行时（单个进程获取和释放锁），semop 版本速度更快。 100 万次迭代大约需要 2 秒，而 lockf 版本大约需要 3 秒。

这是在以下版本上运行的：

[]$ uname -r
2.6.11-1.1369_FC4smp