并发读取场景下文件删除的最佳实现及Linux文件系统适配问询

首先明确：Linux文件系统并不原生支持你描述的逻辑，需要借助用户态的并发安全数据结构来实现需求。

为什么Linux原生不支持？ #

Linux的文件系统遵循“打开的文件描述符独立于目录项”的语义：

• 当调用unlink()删除文件时，只是移除了文件的目录条目，但文件的实际数据会保留，直到所有打开该文件的文件描述符（fd）都被关闭。
• 也就是说，即使执行了删除操作，已经打开的fd依然可以正常调用read()/pread()读取文件内容，完全无法阻止后续的读操作——这和你要求的“delete后新读操作返回错误”完全不符。

实现方案：借助原子变量实现并发控制 #

因为你的read API会被频繁调用，需要用低开销的并发数据结构，原子布尔变量是最优选择，它能保证无锁的线程安全访问。具体实现思路如下：

1. 类内维护原子状态标记
   在你的类中添加一个原子布尔变量，比如std::atomic<bool> is_file_deleted{false}（C++）或atomic_t is_file_deleted = ATOMIC_INIT(0)（Linux C），用于标记文件是否已被删除。

2. 实现read_file_with_offset方法

   • 首先原子读取is_file_deleted的值：如果标记为已删除，直接返回“不可访问”对应的错误码（比如自定义的-EINVAL或-EACCES）。
   • 如果标记未删除，调用pread(fd, buf, count, offset)执行实际读取（用pread而非read，因为它直接指定偏移量，不需要修改文件指针，更适合并发场景），返回读取结果。

3. 实现delete_file方法

   • 原子地将is_file_deleted设置为true，确保后续所有新的读操作都能立即看到这个状态。
   • 可选调用unlink()删除文件的目录条目（文件实体会在所有fd关闭后自动回收）。
   • 注意：不要在delete_file中直接关闭fd，否则会打断正在执行的读操作，违反“调用delete前的读操作需正常完成”的要求。

这种方案的优势是：

• 原子操作的开销极低，完全适配read频繁调用的场景。
• 天然保证了并发安全性：已进入读操作的线程会正常完成，后续新的读操作会被拦截返回错误。

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