4

I have been reading about memory mapped files which allows file to be shared across multiple processes.

Every process (32 bit to be specific) has 4GB of private address space which is divided into 2GB of user mode address space and 2GB reserved for kernel as described here by Eric Lippert. User mode address space is private to each process and can't be modified by other process.

So, does that mean MMF's are mapped into kernel mode address space since it's shared across all processes?

I have searched a lot about MMF where it gets mapped but could not locate any resource stating that. So, posting question here if my assumption is right or I am missing something here? Any resource to MSDN would be good as well.

Community
  • 1
  • 1
Rohit Vats
  • 79,502
  • 12
  • 161
  • 185
  • It's a bit more complicated than that. No part of the address space is directly accessible to other processes. However, you can explicitly share parts of your address space with other processes, and given the right process permissions, a foreign process *can* access your process' memory (that's basically what the debugger does, for example) – jalf May 11 '14 at 15:27
  • @jalf - By private I meant, user mode of one address space can't be written into by some other process. – Rohit Vats May 11 '14 at 15:59
  • When a process writes to a pointer, that's a virtual pointer. The operating system decides what actual memory it writes to. If you've instructed the operating system that two different virtual pointers in two different processes happen to both map to the same backing store then one process can write memory and another process can see that change. – Eric Lippert May 11 '14 at 16:04
  • Think about it this way: do you believe that one process can write a file, and another process can read that file, and the write made by one process is visible by the other process? **Memory is disk files**, so whatever you believe is possible using files you should believe is also possible using memory. – Eric Lippert May 11 '14 at 16:06

2 Answers2

3

A process does not have access to kernel address space. To a process the upper 2GB are just inaccessible for a reason unknown to it.

Memory mappings go into the user-mode portion of the address space.

Thanks to virtual memory hardware, physical pages can be present in multiple processes.

Private memory is not shared although all of it sits in the user-mode address range. Memory mappings are treated specially by the kernel. it instructs the hardware to make the physical pages available to multiple processes. Private memory is really a special case where the pages just happen to be mapped into one process only. The hardware doesn't care. In fact, you can have the same page mapped multiple times into the same process if you want.

Rohit Vats
  • 79,502
  • 12
  • 161
  • 185
usr
  • 168,620
  • 35
  • 240
  • 369
  • If it's true that all memory mapping go in user mode address space. Then, all memory mappings should have been shared across multiple processes. Why just only MMF? I might be wrong so want to understand that properly. – Rohit Vats May 11 '14 at 15:57
  • Private memory is not shared although all of it sits in the user-mode address range. Memory mappings are treted specially by the kernel. it instructs the hardware to make the physical pages available to multiple processes. Private memory is really a special case where the pages just happen to be mapped into one process only. The hardware doesn't care. In fact, you can have the same page mapped multiple times into the same process if you want. – usr May 11 '14 at 16:01
  • @RohitVats: Suppose two processes both load foo.dll. Consider a 4K page of foo.dll containing code that is running in two different processes. The code page is mapped into two different processes; it is not loaded into memory once for each process that uses the DLL! There could be hundreds of such processes! – Eric Lippert May 11 '14 at 16:02
  • @usr - +1 for you. You are right as well. But i was looking for actual reason which differentiate between private code and MMF's which Eric provided in his answer. Thanks for your help mate. :) – Rohit Vats May 11 '14 at 16:18
  • The page file has nothing to do with this, contrary to what the article suggests. You can disable the page file and everything still works. How could it still work if the page file were essential? You can also have non-file based memory mappings shared between processes, btw. – usr May 11 '14 at 16:22
3

Memory mapped files are mapped into user-mode address space.

Think about it this way. Suppose you have a 4K file that is memory-mapped into two processes. This simply means that the one storage page on disk is associated with a particular page of virtual address space in each of two processes.

Diagram 3 on this page might help:

http://msdn.microsoft.com/en-us/library/ms810613.aspx

Rohit Vats
  • 79,502
  • 12
  • 161
  • 185
Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • Thanks Eric. Figure 3 clears a lot to me. `Executable Image` and `System page file` is what differentiate between code and MMF's. – Rohit Vats May 11 '14 at 16:12
  • I have one query though. If MMF's are also mapped to user mode address space. So size of file will account in calculation of 2GB max limit of process. Please correct if i am wrong. If i allocate continuously memory of say 16MB on LOH, application crashes with OOM after some time but if I allocate memory in MMF, application doesn't crash with OOM. (I hold onto MMF file i.e. not call dispose on it so that it doesn't get GC'ed). Second case should have been failed too with OOM. Doesn't it or i am wrong in this understanding? – Rohit Vats May 11 '14 at 16:26
  • @RohitVats: You don't have to map the *entire* file into address space; you could map it in 4K at a time if you really want. – Eric Lippert May 11 '14 at 16:28