NET 4 in memory-mapped files

Original link: http://blogs.msdn.com/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx

Pre-Knowledge: This article requires you to have a certain understanding of OS memory management.

I want to explore some of the new features in the upcoming. NET 4, rather than the dynamic types, covariance, and contravariance that have been known to the public. For the love of performance enhancement, Next I will post several new features.

Memory-mapped files for a managed world developer, it seems like a Martian stranger (voiceover: A temper star, a dangerous beep on the earth). But it does work for years, and it's not polite to say that its position in the OS is very important. In fact, any communication model that wants to share data will be used behind the scenes.

So what exactly is a memory-mapped file? The memory-mapped file allows you to keep a block of address space and then commit the physical storage to this space (well, does that sound like virtual memory?) )。 The main difference between the two is that the physical storage comes from the files that are already on the disk, not the memory manager. There are two major intentions to do this:

1. Accessing data on disk files does not require file I/O operations and cache file contents. When you access very large file data, the effect is particularly significant. 2. You can use memory-mapped files to allow multiple processes running on the same machine to share data with each other.

The Windows operating system itself uses memory maps to execute DLLs and mount and execute EXE files.

Memory-mapped files are the most efficient way to communicate data between multiple processes in a single machine. In addition, if you refer to other IPC methods, you will see the schema as shown:

Woo ..., now you have a general idea of the power of the technology (under the System.IO namespace, it can even completely replace the P/invoke technology).

Now, let me explain quickly how it works. We have two types of memory-mapped file models. One is to use a custom file. It can be any file that the application wants to access. The other is the paging file. We'll share it with the memory manager (this is the most common technology model).

Let's introduce the customization file model. The first thing we need to do is create a FileStream for the file we want to use, which can be an existing file or a new file (remember, you should open the file in a shared way, otherwise the other process won't be able to access it). Once you have created the appropriate stream, you can now create a memory-mapped file. As shown below:

1:using system.io.memorymappedfiles;1:memorymappedfile memorymappedfile = Memorymappedfile.createfromfile (2:new FileStream (@ "E:\Temp\Map.mp", FileMode.Create),//any Stream would do it3: "Mymemorymappedfile",//name4:1024 * 1024x768,//si Ze in bytes5:MemoryMappedFileAccess.ReadWrite); Access type

Here, I used a very simple constructor for the MemoryMappedFile class. We define the stream to use, and then give the memory-mapped file a name. In addition, we need to know the size of the memory-mapped file (in bytes) and the type of access. In this way, we create a memory-mapped file. But before we start using it, we also need a mapping view. Next, we'll create it:

Memorymappedviewaccessor Filemapview = Memorymappedfile.createviewaccessor ();

This mapping overwrites the entire file. If we are going to read or write information from a memory-mapped file now, we just need to call the map view method with the correct offset.

int number = 1234; Filemapview.write (0, number); Filemapview.write<container> (4, ref Container);

We can write data to any previous built-in type or custom type with a generic constraint. A good feature of a memory-mapped file is persistence. Before you close it, the contents will accumulate on the disk. This is useful for sharing cache information between applications.

Well, how does the other process read the contents of the memory-mapped file? , let's create a memory-mapped file first. But we're using a different constructor to open the existing memory-mapped file. If it doesn't exist, it's not too late to create it. The code example in the original is wrong.

MemoryMappedFile memorymapped = Memorymappedfile.createoropen ("Mymemorymappedfile", 1024 * 1024, Memorymappedfileaccess.readwrite);

Next, create the mapping view to read the information as follows:

using (Memorymappedviewaccessor Filemap = Memorymappedfile.createviewaccessor ()) {Container Newcontainer = new Container (); Filemap.read<container> (4, Outnewcontainer);}

See, isn't it simple? But there is a small drawback to this approach, which is related to the size of the memory-mapped file. If you don't know the size beforehand, you might construct a super-large file just in case. But this wastes a lot of address space. After all, the address you keep is much larger than the physical space you submit, isn't it?

In order to solve this problem, we can use the paging file. This is very useful for submitting data in a busy schedule. But it also introduces a new problem: You don't have your own files, and the mappings persist until the last handle is destroyed. But think about it, it's a pretty sensible plan.

Now we re-construct the previous example. This time, I'm going to use the constructor of the most complete parameter, which can also introduce some other features. Of course, these features also apply to custom files.

Memorymappedfilesecurity customsecurity = new memorymappedfilesecurity (); MemoryMappedFile pagedmemorymapped = memorymappedfile.createnew (@ "Salvador",//name1024*1024,// Sizememorymappedfileaccess.readwrite,//access typememorymappedfileoptions.delayallocatepages,//Pseudo reserve/ Commitcustomsecurity,//you can customize the securityhandleinheritability.inheritable//inherit to child process);

The Memorymappedfilesecurity class allows you to customize which process can access resources. This feature is useful when you want to protect sensitive information, or if you don't want other processes to change this memory-mapped file. You can see all the different settings that you want to change for this object. Here you can get more detailed information. If we want to explore the memory-mapped file structure, we don't need to construct a stream, just find the name of the resource. This links the map name and the file size-based area. So many processes know how to access the file. Note that when you use the Delayallocatepages property, the address space is reserved/submitted only when necessary. The last interesting parameter is the handle inheritance model. It allows the child process to share resources when necessary.

How to access the file is the same as the example described earlier. Remember, if you close the memory-mapped file, it will not be accessible. This problem has plagued many developers.

Finally, let's take a look at another interesting area: creating multiple mapping views. They work at the same time to access different areas of the same memory-mapped file. At this point you have to properly protect content and synchronize access.

We can define different offsets and lengths to create our own mapping views. As shown below:

Memorymappedviewaccessor Writemapview = memorymappedfile.createviewaccessor (0, 1024, Memorymappedfileaccess.readwrite); Memorymappedviewaccessor Readmapview = memorymappedfile.createviewaccessor (1025, 1024,memorymappedfileaccess.read) ;

Now you can enjoy the power of the high performance data sharing model that is brought by. NET 4.0. Note that this article is based on the. NET 4.0 BETA1 Authoring.

UNIX does not use a mapping file for memory sharing, it has an explicit memory-sharing API function. These functions are Shmget, Shmctl, Shmat, SHMDT, and Mmap, Munmap. The last two functions are somewhat similar to the one described in this article, but they do not have a mapped object.

NET 4 in memory-mapped files