Editing Mmap (section)

== Memory visibility ==
If the mapping is ''shared'' (the <code>MAP_SHARED</code> flag is set), then it is preserved when a process is forked (using a [[fork (system call)|<code>fork(2)</code>]] system call). Therefore, writes to a mapped area in one process are immediately visible in all related (parent, child or sibling) processes. If the mapping is ''shared'' and backed by a file (not <code>MAP_ANONYMOUS</code>) the underlying file medium is only guaranteed to be written after it is passed to the <code>msync(2)</code> system call. In contrast, if the mapping is ''private'' (the <code>MAP_PRIVATE</code> flag is set), the changes will neither be seen by other processes nor written to the file.

A process reading from, or writing to, the underlying file will not always see the same data as a different process that has mapped the file, since segments of the file are copied into RAM and only periodically flushed to disk. Synchronization can be forced with a call to <code>msync(2)</code>.

Using mmap on files can significantly reduce memory overhead for applications accessing the same file; they can share the memory area the file encompasses, instead of loading the file for each application that wants access to it. This means that mmap(2) is sometimes used for [[Interprocess Communication]] (IPC). On modern [[operating system]]s, mmap(2) is typically preferred to the [[System V]] IPC [[Shared memory (interprocess communication)|Shared Memory]] facility.<ref name="Kerrisk 2010 p. 1116">{{cite book | last=Kerrisk | first=Michael | title=The Linux programming interface : a Linux and UNIX system programming handbook | publisher=No Starch Press | publication-place=San Francisco | year=2010 | isbn=978-1-59327-291-3 | oclc=728672600 | page=1116}}</ref>

The main difference between System V shared memory (shmem) and memory mapped I/O (mmap) is that System V shared memory is persistent: unless explicitly removed by a process, it is kept in memory and remains available until the system is shut down. mmap'd memory is not persistent between application executions (unless it is backed by a file).