所有这些都是为了引用Linux,内核版本3.13,如果它很重要,以防Posixen之间存在不同的行为 – 尽管如果有人知道其他变体的情况,那将会很有趣.

我目前的理解是：

> Posix read(2)和write(2)调用相互之间是原子的(这是Posix标准规定的).如果我在该位置同时读取()一些字节与write(),我将看到全部或全部.编辑：请参阅注释,对于许多文件系统,它只是逐页原子.
> write(2)调用是关于mmap的原子 – 如果我写()到某些字节,并同时通过mmap读取缓冲区,我将看到所有的写或没有(我相信这不是由Posix严格强制执行) ,但它是Linux和许多其他操作系统管理页面缓存的方式的工件,并且仅适用于打到一页的写入).
> Mmap写入不保证对任何事物都是原子的 – 其他读者可能会看到部分写入,同一部分中的其他编写者可能会混合.实际上,可能存在最小的原子尺寸,但我不知道这是什么或如何保证它.有没有人对此有任何见解？
>如果我在mmap缓冲区中的内存位置上执行CPU CAS,那么就实际拥有CAS语义而言,它将“按照我的意愿行事”,并且任何成功的写入都将保证原子可见/不可见其他读者(无论是通过mmap还是read()),只要我保持CPU规定的对齐限制.

我是否直截了当,是否有我可以查看的实现或文档以更深入地了解这些交互？

解决方法:

根据POSIX理由：

I/O is intended to be atomic to ordinary files and pipes and FIFOs. (…) The behavior for other device types is also left unspecified, but the wording is intended to imply that future standards might choose to specify atomicity (or not).

因此,特殊文件上的POSIX似乎无法保证原子性,例如,mmaping / dev / zero.

Applications need to know how large a write request can be expected to be performed atomically. This maximum is called {PIPE_BUF}.

即使在常规文件上,如果写入小于PIPE_BUF字节,则只能由POSIX保证原子写入.

来自linux手册页：

However, on Linux before version 3.14, this was not the case: if two processes that share an open file descriptor (see open(2)) perform a write() (or writev(2)) at the same time, then the I/O operations were not atomic with respect updating the file offset, with the result that the blocks of data output by the two processes might (incorrectly) overlap. This problem was fixed in Linux 3.14.

顺便提一下,对于read()也是如此.

我找不到任何确认2). POSIX不需要这个：

The application must ensure correct synchronization when using mmap() in conjunction with any other file access method, such as read() and write(), standard input/output, and shmat().

POSIX对于3)这样说是有意义的,因为在写入内存位置时需要知道对象大小.

如果你进行原子比较和交换,那么单个单词将被原子更新,这并不意味着整个写入都是原子的,除非你使用CAS操作来构建更复杂的操作,如锁或事务内存.

http://man7.org/linux/man-pages/man2/write.2.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html