文件系统如何处理并发读/写？
用户A要求系统读取文件foo，同时用户B想要将他或她的数据保存到同一个文件中。在文件系统级别如何处理这种情况？
User A asks the system to read file foo and at the same time user B wants to save his or her data onto the same file. How is this situation handled on the filesystem level?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
大多数文件系统（但不是全部）使用锁定来保护对同一文件的并发访问。锁可以是独占的，因此第一个获得锁的用户可以获得访问权限 - 后续用户会收到“访问被拒绝”错误。在您的示例场景中，用户 A 将能够读取文件并获取文件锁，但用户 B 在用户 A 读取时将无法写入。
某些文件系统（例如 NTFS）允许指定锁定级别，以允许并发读取，但不允许写入。字节范围锁也是可能的。
与数据库不同，文件系统通常不是事务性的，不是原子性的，并且来自不同用户的更改不是隔离的（如果甚至可以看到更改 - 锁定可能会禁止这样做。）
使用整个文件锁是一种粗粒度的方法，但它可以防止不一致更新。并非所有文件系统都支持整个文件锁定，因此通常的做法是使用锁定文件 - 一个通常为空的文件，其存在表明其关联的文件正在使用中。 （在大多数文件系统上创建文件是一项原子操作。）
Most filesystems (but not all) use locking to guard concurrent access to the same file. The lock can be exclusive, so the first user to get the lock gets access - subsequent users get a "access denied" error. In your example scenario, user A will be able to read the file and gets the file lock, but user B will not be able to write while user A is reading.
Some filesystems (e.g. NTFS) allow the level of locking to be specified, to allow for example concurrent readers, but no writers. Byte-range locks are also possible.
Unlike databases, filesystems typically are not transactional, not atomic and changes from different users are not isolated (if changes can even be seen - locking may prohibit this.)
Using whole-file locks is a coarse grained approach, but it will guard against inconsistent updates. Not all filesystems support whole-file locks, and so it is common practice to use a lock file - a typically empty file whose presence indicates that its associated file is in use. (Creating a file is an atomic operation on most file systems.)
对于 Linux，简短的答案是，如果存在并发写入器，您可能会从文件中获取一些奇怪的信息。内核确实在内部使用锁定来串行运行每个read()和write()操作。 （不过，我忘记了整个文件是否被锁定，或者是否在每页粒度上。）但是，如果应用程序使用多个 write() 调用将信息写入文件，则 read() 可能发生在任何这些调用之间，因此它可能会看到不一致的数据。这是操作系统中的原子性违规。
正如 mdma 所提到的，您可以使用文件锁定来确保只有一名读者和一名作者一次。听起来 NTFS 使用强制锁定，如果一个程序锁定文件，则所有其他程序在尝试访问该文件时都会收到错误消息。
Unix 程序通常根本不使用锁定，当使用锁定时，锁定通常是建议性的。咨询锁仅防止其他进程获得同一文件的咨询锁；它实际上并没有阻止读取或写入。 （也就是说，它只为那些检查锁定的人锁定文件。）
For Linux, the short answer is you could get some strange information back from a file if there is a concurrent writer. The kernel does use locking internally to run each read() and write() operation serially. (Although, I forget whether the whole file is locked or if it's on a per-page granularity.) But if the application uses multiple write() calls to write information to the file, a read() could happen between any of those calls, so it could see inconsistent data. This is an atomicity violation in the operating system.
As mdma has mentioned, you could use file locking to make sure there is only one reader and one writer at a time. It sounds like NTFS uses mandatory locking, where if one program locks the file, all other programs get error messages when they try to access it.
Unix programs generally don't use locking at all, and when they do, the lock is usually advisory. An advisory lock only prevents other processes from getting an advisory lock on the same file; it doesn't actually prevent the read or write. (That is, it only locks the file for those who check the lock.)