Mmap
In computing, codice_1 is a POSIX-compliant Unix system call that maps files or devices into memory. It is a method of memory-mapped file I/O. It implements demand paging because file contents are not read from disk directly and initially do not use physical RAM at all. The actual reads from disk are performed in a "lazy" manner, after a specific location is accessed. After the memory is no longer needed, it is important to codice_2 the pointers to it. Protection information can be managed using codice_3, and special treatment can be enforced using codice_4. In Linux , macOS and the BSDs, codice_5 can create several types of mappings. Other operating systems may only support a subset of these; for example, shared mappings may not be practical in an operating system without a global VFS or I/O cache. History. The original design of memory mapped files came from the TOPS-20 operating system. codice_5 and associated systems calls were designed as part of the Berkeley Software Distribution (BSD) version of Unix. Their API was already described in the 4.2BSD System Manual, even though it was neither implemented in that release, nor in 4.3BSD. Sun Microsystems had implemented this  very API, though, in their SunOS operating system. The BSD developers at U.C. Berkeley requested Sun to donate its implementation, but these talks never led to any transfer of code; 4.3BSD-Reno was shipped instead with an implementation based on the virtual memory system of Mach. File-backed and anonymous. "File-backed mapping" maps an area of the process's virtual memory to files; i.e. reading those areas of memory causes the file to be read. It is the default mapping type. "Anonymous mapping" maps an area of the process's virtual memory not backed by any file. The contents  are initialized to zero. In this respect an anonymous mapping is similar to codice_7, and is used in some codice_8 implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all operating systems by the codice_9 and codice_10 flags. Memory visibility. If the mapping is "shared" (the codice_11 flag is set), then it is preserved across a fork(2) system call. This means that 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 codice_9) the underlying file medium is only guaranteed to be written after it is msync(2)'ed. If the mapping is "private" (the codice_13 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 process that has mapped the file, since the segment of the file is copied into RAM and periodically flushed to disk. Synchronization can be forced with the codice_14 system call. mmap(2)ing 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 systems, mmap(2) is typically preferred to the System V IPC Shared Memory facility. 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). Example of usage under the C programming language. /* This example shows how an mmap of /dev/zero is equivalent to /* Does not work on OS X or macOS, where you can't mmap over /dev/zero */ int main(void) sample output: