interprocess.qbk

来自「Boost provides free peer-reviewed portab」· QBK 代码 · 共 1,625 行 · 第 1/5 页

File mapping is the association of a file's contents with a portion of the address space 
of a process. The system creates a file mapping to associate the file and the address 
space of the process. A mapped region is the portion of address space that the process 
uses to access the file's contents. A single file mapping can have several mapped regions, 
so that the user can associate parts of the file with the address space of the process 
without mapping the entire file in the address space, since the file can be bigger
than the whole address space of the process (a 9GB DVD image file in a usual 32
bit systems). Processes read from and write to 
the file using pointers, just like with dynamic memory. File mapping has the following 
advantages: 

* Uniform resource use. Files and memory can be treated using the same functions. 
* Automatic file data synchronization and cache from the OS. 
* Reuse of C++ utilities (STL containers, algorithms) in files. 
* Shared memory between two or more applications. 
* Allows efficient work with a large files, without mapping the whole file into memory 
* If several processes use the same file mapping to create mapped regions of a file, each 
  process' views contain identical copies of the file on disk.

File mapping is not only used for interprocess communication, it can be used also to
simplify file usage, so the user does not need to use file-management functions to
write the file. The user just writes data to the process memory, and the operating
systems dumps the data to the file.

When two processes map the same file in memory, the memory that one process writes is
seen by another process, so memory mapped files can be used as an interprocess
communication mechanism. We can say that memory-mapped files offer the same interprocess
communication services as shared memory with the addition of filesystem persistence.
However, as the operating system has to synchronize the file contents with the memory
contents, memory-mapped files are not as fast as shared memory.

[endsect]

[section:mapped_file_steps Using mapped files]

To use memory-mapped files, we have to perform 2 basic steps:

* Create a mappable object that represent an already created file of the
  filesystem. This object will be used to create multiple mapped regions of the
  the file.

* Associate the whole file or parts of the file with the address space of the
  calling process. The operating system looks for a big enough memory address range
  in the calling process' address space and marks that address range as an
  special range. Changes in that address range are automatically seen
  by other process that also have mapped the same file and those changes
  are also transferred to the disk automatically.

Once the two steps have been successfully completed, the process can start writing to
and reading from the address space to send to and receive data from other processes
and synchronize the file's contents with the changes made to the mapped region.
Now, let's see how can we do this using [*Boost.Interprocess]:

[endsect]

[section:mapped_file_header Header]

To manage mapped files, you just need to include the following header:

[c++]

   #include <boost/interprocess/file_mapping.hpp>

[endsect]

[section:mapped_file_creating_file Creating a file mapping]

First, we have to link a file's contents with the process' address space. To do
this, we have to create a mappable object that represents that file. This is
achieved in [*Boost.Interprocess] creating a `file_mapping` object:

[c++]

      using boost::interprocess;
      file_mapping m_file
         ("/usr/home/file"       //filename
         ,read_write             //read-write mode
         );

Now we can use the newly created object to create mapped regions. For more details
regarding this class see the 
[classref boost::interprocess::file_mapping] class reference.

[endsect]

[section:mapped_file_mapping_regions Mapping File's Contents In Memory]

After creating a file mapping, a process just has to map the shared memory in the
process' address space. The user can map the whole shared memory or just part of it.
The mapping process is done using the `mapped_region` class. as we have said before
The class represents a memory region that has been mapped from a shared memory or from other
devices that have also mapping capabilities: 

[c++]

      using boost::interprocess;
      std::size_t FileSize = ...

      //Map the second half of the file
      mapped_region region
         ( m_file                   //Memory-mappable object
         , read_write               //Access mode
         , FileSize/2               //Offset from the beginning of shm
         , FileSize-FileSize/2      //Length of the region
         );
      
      //Get the address of the region
      region.get_address();

      //Get the size of the region
      region.get_size();


The user can specify the offset from the file where the mapped region
should start and the size of the mapped region. If no offset or size is specified,
the whole file is mapped. If the offset is specified, but not the size, 
the mapped region covers from the offset until the end of the file.

If several processes map the same file, and a process modifies a memory range
from a mapped region that is also mapped by other process, the changes are
inmedially visible to other processes. However, the file contents on disk are
not updated immediately, since that would hurt performance (writing to disk
is several times slower than writing to memory). If the user wants to make sure
that file's contents have been updated, it can flush a range from the view to disk.
When the function returns, the data should have been written to disk:

[c++]

      //Flush the whole region
      region.flush();

      //Flush from an offset until the end of the region
      region.flush(offset);

      //Flush a memory range starting on an offset
      region.flush(offset, size);

Remember that the offset is [*not] an offset on the file, but an offset in the
mapped region. If a region covers the second half of a file and flushes the
whole region, only the half of the file is guaranteed to have been flushed.

For more details regarding `mapped_region` see the 
[classref boost::interprocess::mapped_region] class reference.

[endsect]

[section:mapped_file_a_simple_example A Simple Example]

Let's reproduce the same example described in the shared memory section, using
memory mapped files. A server process creates a shared
memory segment, maps it and initializes all the bytes to a value. After that, 
a client process opens the shared memory, maps it, and checks
that the data is correctly initialized. This is the server process:

[import ../example/doc_file_mapping.cpp]
[doc_file_mapping]

Now the client process:

[import ../example/doc_file_mapping2.cpp]
[doc_file_mapping2]

[endsect]

[endsect]

[section:mapped_region More About Mapped Regions]

[section:mapped_region_one_class One Class To Rule Them All]

As we have seen, both `shared_memory_object` and `file_mapping` objects can be used
to create `mapped_region` objects. A mapped region created from a shared memory
object or a file mapping are the same class and this has many advantages.

One can, for example, mix in STL containers mapped regions from shared memory
and memory mapped files. The libraries that only depend on mapped regions can
be used to work with shared memory or memory mapped files without recompiling them.

[endsect]

[section:mapped_region_address_mapping Mapping Address In Several Processes]

In the example we have seen, the file or shared memory contents are mapped
to the address space of the process, but the address was chosen by the operating
system.

If several processes map the same file/shared memory, the mapping address will be
surely different in each process. Since each process might have used its address space
in a different way (allocation of more or less dynamic memory, for example), there is
no guarantee that the file/shared memory is going to be mapped in the same address.

If two processes map the same object in different addresses, this invalids the use
of pointers in that memory, since the pointer (which is an absolute address) would 
only make sense for the process that wrote it. The solution for this is to use offsets 
(distance) between objects instead of pointers: If two objects are placed in the same
shared memory segment by one process, [*the address of each object will be different]
in another process but [*the distance between them (in bytes) will be the same].

So the first advice when mapping shared memory and memory mapped files is to avoid
using raw pointers, unless you know what you are doing. Use offsets between data or
relative pointers to obtain pointer functionality when an object placed in a mapped
region wants to point to an object placed in the same mapped region. [*Boost.Interprocess]
offers a smart pointer called [classref boost::interprocess::offset_ptr] that
can be safely placed in shared memory and that can be used to point to another
object placed in the same shared memory / memory mapped file.

[endsect]

[section:mapped_region_fixed_address_mapping Fixed Address Mapping]

The use of relative pointers is less efficient than using raw pointers, so if a user
can succeed mapping the same file or shared memory object in the same address in two
processes, using raw pointers can be a good idea.

To map an object in a fixed address, the user can specify that address in the
`mapped region`'s constructor:

[c++]

   mapped_region region ( shm                         //Map shared memory
                        , read_write                  //Map it as read-write
                        , 0                           //Map from offset 0
                        , 0                           //Map until the end
                        , (void*)0x3F000000           //Map it exactly there
                        );

However, the user can't map the region in any address, even if the address is not
being used. The offset parameter that marks the start of the mapping region 
is also limited. These limitations are explained in the next section.

[endsect]

[section:mapped_region_mapping_problems Mapping Offset And Address Limitations]

As mentioned, the user can't map the memory mappable object at any address and it can
specify the offset of the mappable object that is equivalent to the start of the mapping
region to an arbitrary value.
Most operating systems limit the mapping address and the offset of the mappable object
to a multiple of a value called [*page size]. This is due to the fact that the 
[*operating system performs mapping operations over whole pages].

If fixed mapping address is used, ['offset] and ['address] 
parameters should be multiples of that value.
This value is, typically, 4KB or 8KB for 32 bit operating systems.

[c++]

   //These might fail because the offset is not a multiple of the page size
   //and we are using fixed address mapping
   mapped_region region1( shm                   //Map shared memory
                        , read_write            //Map it as read-write
                        , 1                     //Map from offset 1
                        , 1                     //Map 1 byte
                        , (void*)0x3F000000     //Aligned mapping address
                        );

   //These might fail because the address is not a multiple of the page size
   mapped_region region2( shm                   //Map shared memory
                        , read_write            //Map it as read-write
                        , 0                     //Map from offset 0
                        , 1                     //Map 1 byte
                        , (void*)0x3F000001     //Not aligned mapping address
                        );

Since the operating system performs mapping operations over whole pages, specifying
a mapping ['size] or ['offset] that are not multiple of the page size will waste
more resources than necessary. If the user specifies the following 1 byte mapping:

[c++]

   //Map one byte of the shared memory object.
   //A whole memory page will be used for this.
   mapped_region region ( shm                    //Map shared memory
                        , read_write             //Map it as read-write
                        , 0                      //Map from offset 0
                        , 1                      //Map 1 byte
                        );

The operating system will reserve a whole page that will not be reused by any
other mapping so we are going to waste [*(page size - 1)] bytes. If we want
to use efficiently operating system resources, we should create regions whose size
is a multiple of [*page size] bytes. If the user specifies the following two
mapped regions for a file with which has `2*page_size` bytes:

   //Map the first quarter of the file
   //This will use a whole page
   mapped_region region1( shm                //Map shared memory
                        , read_write         //Map it as read-write
                        , 0                  //Map from offset 0
                        , page_size/2        //Map page_size/2 bytes
                        );

   //Map the rest of the file
   //This will use a 2 pages
   mapped_region region2( shm                //Map shared memory
                        , read_write         //Map it as read-write
                        , page_size/2        //Map from offset 0
                        , 3*page_size/2      //Map the rest of the shared memory
                        );

In this example, a half of the page is wasted in the first mapping and another
half is wasted in the second because the offset is not a multiple of the
page size. The mapping with the minimum resource usage would be to map whole pages:

   //Map the whole first half: uses 1 page
   mapped_region region1( shm                //Map shared memory
                        , read_write         //Map it as read-write
                        , 0                  //Map from offset 0
                        , page_size          //Map a full page_size
                        );

   //Map the second half: uses 1 page
   mapped_region region2( shm                //Map shared memory
                        , read_write         //Map it as read-write
                        , page_size          //Map from offset 0
                        , page_size          //Map the rest
                        );

How can we obtain the [*page size]? The `mapped_region` class has a static
function that returns that value:

[c++]

   //Obtain the page size of the system