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. 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 a file behind the shared memory, the kernel occasionally syncs changed pages from RAM to the file.
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. When multiple processes are using the same shared memory region, their individual virtual addresses will be pointing to the same physical address. It depends on how the memory region was created. Shared memory can be backed by a regular file, a block device, or swap. Memory between the communicating processes (Figure 9.23). The memory-mapped file serves as the region of shared Under this scenario, processes can communicate using shared memoryīy having the communicating processes memory-map the same file into their Quite often, shared memory is in fact implemented by memory mapping Memory between the communicating processes" seems to mean that it resides in main memory. It also introduces shared memory in the following.ĭo multiple processes share a memory region by sharing a memory-mapped file?ĭoes 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 Physical memory-the page that holds a copy of the disk block. The virtual memory map of each sharing process points to the same page of How the sharing of memory-mapped sections of memory is implemented: Given our earlier discussions of virtual memory, it should be clear Virtual memory and can be seen by all others that map the same section of Writes by any of the processes modify the data in Multiple processes may be allowed to map the same file concurrently, Operating System Concepts introduces sharing a memory-mapped file in the following.ĭo the multiple processes share the same file by sharing the same physical memory region holding the content of the file? It just makes it harder to reason about safety.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. But this in and of itself doesn't make them inaccessible to you. The main problem in Rust land with memory maps is that they don't fit into Rust's safety story in an obvious way. You'd have the same problems if you read a file into heap memory. And when you use `unsafe`, you want to be sure that it's justified. With that said, this technique is not common in Rust because it requires `unsafe` to do it.
The most obvious thing that is problematic for mmap structures like this that is otherwise easy to do is pointer indirection. That is, you need to build your data structures to be mmap friendly. But when you memory map stuff like this, you need to take at least all the same precautions as you would in C. You can tag your types with `repr(C)` to get a consistent memory layout equivalent to whatever C does. You should be able to do in Rust whatever you would do in C. > My argument was more about structured data (created using the type system), which is a level higher than raw bytes. The docs of the crate give links to papers if you want to drill down.
Memory mapped file code#
So your code operates directly on a block of raw bytes? I can see how that can work with mmap without much problems.Ĭorrect.
0 kommentar(er)
