Are sharing a memory-mapped file and sharing a memory region implemented based on each other?

Question

Are sharing a memory-mapped file and sharing a memory region implemented based on each other? The following two quotes seem to say so, and seem a chicken-egg problem to me.

Operating System Concepts introduces sharing a memory-mapped file in the following. Do the multiple processes share the same file by sharing the same physical memory region holding the content of the file?

Multiple processes may be allowed to map the same file concurrently, to allow sharing of data. Writes by any of the processes modify the data in virtual memory and can be seen by all others that map the same section of the file. Given our earlier discussions of virtual memory, it should be clear how the sharing of memory-mapped sections of memory is implemented: the virtual memory map of each sharing process points to the same page of physical memory—the page that holds a copy of the disk block. This memory sharing is illustrated in Figure 9.22.

It also introduces shared memory in the following.

• Do multiple processes share a memory region by sharing a memory-mapped file?

• Does a "memory-mapped file" reside on disk or main memory? I think it is on the disk, but "The memory-mapped file serves as the region of shared memory between the communicating processes" seems to mean that it resides in main memory.

Quite often, shared memory is in fact implemented by memory mapping files. Under this scenario, processes can communicate using shared memory by having the communicating processes memory-map the same file into their virtual address spaces. The memory-mapped file serves as the region of shared memory between the communicating processes (Figure 9.23).

Thanks.

Solution 1

Shared memory can be backed by a regular file, a block device, or swap. It depends on how the memory region was created.

When multiple processes are using the same shared memory region, their individual virtual addresses will be pointing to the same physical address. Writes by one process become visible to others directly, without needing to pass through the disk file (if any) that the memory is attached to.

If there is a file behind the shared memory, the kernel occasionally syncs changed pages from RAM to the file. The processes using the memory normally don't need to know when this happens, but if necessary, they can call msync to make it happen sooner.

If there is no file behind the shared memory, the kernel may move pages to swap when it needs to free some RAM, just like it does with non-shared process memory. When they're swapped back in, they get a new physical address which is immediately available to all processes that have mapped the shared memory.

There's one more thing that confused me the first time I looked at it: if you map a file with mmap, you have to use MAP_SHARED if you want to make changes and have them saved back to the file, even if there's only one process involved. At first I thought MAP_SHARED was the wrong name for this functionality, but on further reflection, you're "sharing" your modifications with other processes that access the file with read, or processes that will come along later and mmap it. So it makes sense, kind of.

Solution 2

Are sharing a memory-mapped file and sharing a memory region implemented based on each other?

Pretty much, at the end of the day /dev/shm is just a ramdisk.

Does a "memory-mapped file" reside on disk or main memory?

Yes!

The portions of the file that are accessed are copied (by the swapper) into buffers - which is RAM.

Any writes to that memory will be immediately visible in the file, but will not be written to physical disk until the buffer is synced or flushed.

Comments

[Jasen]

The Linux Programmers Guide has a good discussion of this and some demonstration code

[Tim]

Thanks. (1) how do you understand this example of the chicken egg paradox? (2) "Any writes to that memory will be immediately visible in the file," do you mean visible to other process?