stat() 相对于文件系统是原子的答案

【问题标题】：Is stat() atomic with respect to the file systemstat() 相对于文件系统是原子的
【发布时间】：2019-07-27 08:23:08
【问题描述】：

我有一组可执行文件，每隔几分钟 24/7 定期更新一组文件。我正在考虑编写一个监控程序，它将不断检查所有这些文件的最后写入时间（使用函数stat()），以便如果最近没有足够的更新，它可以发出警报。不过，我担心的是，调用 stat() 的行为可能会导致尝试写入该文件的程序失败。我需要担心吗？...如果是，是否有其他方法可以实现我的目标？

【问题讨论】：

所有系统调用都是原子的，stat()对写入文件的程序没有任何影响，但这两个事实之间没有任何联系。 stat() 是 C 库的一部分，而不是 winapi：但如果您担心 及时性 和 Windows，您需要知道目录条目不是每次写入都会更新：例如 size 和 last-modified 字段。很困惑的问题。
文件系统听起来像是解决整个问题的错误工具。
@user207421：我不知道你怎么能声称没有连接。例如，如果 stat() 不是原子的，那么一个程序调用 stat() 的进程可能会导致 fopen() 在另一个程序中失败。
@Mick 'atomic' 不仅与这个问题无关，它实际上是这个问题的解决方案。您对读取目录的系统调用莫名其妙地担心会以某种方式神奇地干扰对该目录中文件的写入，这不可能是真正的问题。如果这不起作用，那么什么都不会起作用。以您的示例为例，stat() 不是 '忙于文件'，它正忙于目录，但无论如何只要stat() 和open() 是 atomic 它们不可能相互干扰。 这就是原子的意思。
@curiousguy 是的，系统调用的原子性是一个重要目标，而且通常可以实现。见What means “atomic” system call? 和Is every system call an atomic operation?。

标签： c++ c winapi

【解决方案1】：

是的，stat 调用可以被认为是原子的，因为它返回的所有信息都保证是一致的。如果您在同一时刻调用stat，则其他进程正在写入文件，则应该不可能，例如，其他进程的写入反映在st_mtime 而不是st_size。

在任何情况下，当然不可能在其他进程正在写入文件的同时调用stat 可能导致其他进程失败。（这将是操作系统中一个严重且非常不可接受的错误——操作系统的主要工作之一是确保不相关的进程不会以这种方式意外地相互交互。这种缺乏干扰的特性是不过，通常不是我们所说的“原子”。）

话虽如此，但监控进程的常用方法是通过其进程 ID。并且可能有很多预先编写的软件包可以帮助您管理一个或多个应该连续运行的进程，为您提供干净的启动/停止和监控功能。（以s6 为例。我对这个包一无所知，也不推荐它；它只是我在网络搜索中遇到的第一个。）

如果您在进程之间设置了任何类型的IPC 机制，另一种可能性是设置每个进程发布的周期性@987654323@，以便某个地方的watchdog timer 可以检测到进程死亡。

但是，如果您想通过他们编写的文件的及时性来持续监控您的流程，这听起来也是一种非常好的技术。

【讨论】：