Lines Matching full:memory
27 * Shared memory.
28 * Memory-mapped files.
30 them in shared memory and memory mapped files.
38 dynamically portions of a shared memory or a memory mapped file (in general,
39 to allocate portions of a fixed size memory segment). Using these mechanisms,
41 STL-like containers, in shared memory and memory mapped files:
43 * Dynamic creation of anonymous and named objects in a shared memory or memory
45 * STL-like containers compatible with shared memory/memory-mapped files.
46 * STL-like allocators ready for shared memory/memory-mapped files implementing
47 several memory allocation patterns (like pooling).
87 [section:qg_memory_pool Using shared memory as a pool of unnamed memory blocks]
89 You can just allocate a portion of a shared memory segment, copy the
91 memory to another process, and you are done. Let's see the example:
98 [section:qg_named_interprocess Creating named shared memory objects]
100 You want to create objects in a shared memory segment, giving a string name to them so that
109 [section:qg_offset_ptr Using an offset smart pointer for shared memory]
114 When offset_ptr is placed in a shared memory segment, it
116 memory segment, even if the segment is mapped in
120 in shared memory. For example, if we want to create
121 a linked list in shared memory:
131 [section:qg_interprocess_container Creating vectors in shared memory]
133 [*Boost.Interprocess] allows creating complex objects in shared memory and memory
134 mapped files. For example, we can construct STL-like containers in shared memory.
135 To do this, we just need to create a special (managed) shared memory segment,
136 declare a [*Boost.Interprocess] allocator and construct the vector in shared memory
139 The class that allows this complex structures in shared memory is called
146 The parent process will create an special shared memory class that allows easy construction
148 program with an additional argument so the child process opens the shared memory and uses
153 [section:qg_interprocess_map Creating maps in shared memory]
156 shared memory and memory mapped files. The only difference is that
195 * Two processes can share a [*memory] region. This is the case of classical
196 shared memory or memory mapped files. Once the processes set up the
197 memory region, the processes can read/write the data like any
198 other memory segment without calling the operating system's kernel. This
225 [[Shared memory] [Kernel or Filesystem]]
226 [[Memory mapped file] [Filesystem]]
240 shared memory using memory mapped files and obtain filesystem persistence (for example,
242 for Windows shared memory using native shared memory,
243 or process persistence for POSIX shared memory, so the only portable way is to
250 Some interprocess mechanisms are anonymous objects created in shared memory or
251 memory-mapped files but other interprocess mechanisms need a name or identifier
253 Examples of this are shared memory, named mutexes and named semaphores (for example,
270 Named [*Boost.Interprocess] resources (shared memory, memory mapped files,
286 regarding shared memory and named semaphores:
288 [table Boost.Interprocess-POSIX shared memory
314 shared shared memory, memory mapped files or named synchronization mechanisms
332 shared memory. This approach has two advantages: it's similar to the UNIX philosophy
339 [section:sharedmemorybetweenprocesses Sharing memory between processes]
341 [section:sharedmemory Shared memory]
343 [section:shared_memory_what_is What is shared memory?]
345 Shared memory is the fastest interprocess communication mechanism.
346 The operating system maps a memory segment in the address space of several
347 processes, so that several processes can read and write in that memory segment
349 synchronization between processes that read and write shared memory.
354 * The server must read the file to memory and pass it to the network functions, that
355 copy that memory to the OS's internal memory.
357 * The client uses the network functions to copy the data from the OS's internal memory
358 to its own memory.
360 As we can see, there are two copies, one from memory to the network and another one
361 from the network to memory. And those copies are made using operating system calls
362 that normally are expensive. Shared memory avoids this overhead, but we need to
365 * The server maps a shared memory in its address space and also gets access to a
366 synchronization mechanism. The server obtains exclusive access to the memory using
367 the synchronization mechanism and copies the file to memory.
369 * The client maps the shared memory in its address space. Waits until the server releases
372 Using shared memory, we can avoid two data copies, but we have to synchronize the access
373 to the shared memory segment.
377 [section:shared_memory_steps Creating memory segments that can be shared between processes]
379 To use shared memory, we have to perform 2 basic steps:
381 * Request to the operating system a memory segment that can be shared between
382 processes. The user can create/destroy/open this memory using a [*shared memory object]:
383 ['An object that represents memory that can be mapped concurrently into the
386 * Associate a part of that memory or the whole memory with the address space of the
387 calling process. The operating system looks for a big enough memory address range
390 by other process that also have mapped the same shared memory object.
400 To manage shared memory, you just need to include the following header:
408 [section:shared_memory_creating_shared_memory_segments Creating shared memory segments]
411 and destroy shared memory segments that can be mapped by several processes. We can
412 specify the access mode of that shared memory object (read only or read-write),
415 * Create a shared memory segment. Throws if already created:
426 * To open or create a shared memory segment:
437 * To only open a shared memory segment. Throws if does not exist:
448 When a shared memory object is created, its size is 0.
449 To set the size of the shared memory, the user must use the `truncate` function
450 call, in a shared memory that has been opened with read-write attributes:
456 As shared memory has kernel or filesystem persistence, the user must explicitly
458 false if the shared memory does not exist, the file is open or the file is
459 still memory mapped by other processes:
472 [section:shared_memory_mapping_shared_memory_segments Mapping Shared Memory Segments]
474 Once created or opened, a process just has to map the shared memory object in the process'
475 address space. The user can map the whole shared memory or just part of it. The
477 a memory region that has been mapped from a shared memory or from other devices
487 //Map the second half of the memory
489 ( shm //Memory-mappable object
503 the whole mappable object (in this case, shared memory) is mapped. If the offset
514 Let's see a simple example of shared memory use. A server process creates a
515 shared memory object, maps it and initializes all the bytes to a value. After that,
516 a client process opens the shared memory, maps it, and checks
524 [section:emulation Emulation for systems without shared memory objects]
526 [*Boost.Interprocess] provides portable shared memory in terms of POSIX
527 semantics. Some operating systems don't support shared memory as defined by
530 * Windows operating systems provide shared memory using memory backed by the
533 Native windows shared memory] section for more information).
535 * Some UNIX systems don't fully support POSIX shared memory objects at all.
537 In those platforms, shared memory is emulated with mapped files created
543 For Windows platforms without that registry key and Unix systems, shared memory is
546 Because of this emulation, shared memory has filesystem lifetime in some
551 [section:removing Removing shared memory]
554 provides a static `remove` function to remove a shared memory objects.
556 This function [*can] fail if the shared memory objects does not exist or
561 * The function will remove the name of the shared memory object
564 * If one or more references to the shared memory object exist when
566 removal of the memory object contents will be postponed until all open and
567 map references to the shared memory object have been removed.
572 shared memory object of this name exists (that is, trying to open an object
581 [section:anonymous_shared_memory Anonymous shared memory for UNIX systems]
583 Creating a shared memory segment and mapping it can be a bit tedious when several
585 call in UNIX systems a simpler method is available using anonymous shared memory.
591 function, which returns a `mapped_region` object holding an anonymous shared memory
604 [section:windows_shared_memory Native windows shared memory]
606 Windows operating system also offers shared memory, but the lifetime of this
607 shared memory is very different to kernel or filesystem lifetime. The shared memory
609 process attached to the shared memory is destroyed.
612 persistence using native windows shared memory and [*Boost.Interprocess] emulates
613 shared memory using memory mapped files. This assures portability between POSIX
616 However, accessing native windows shared memory is a common request of
618 to shared memory created with other process that don't use
619 [*Boost.Interprocess]. In order to manage the native windows shared memory
623 Windows shared memory creation is a bit different from portable shared memory
625 can't be specified through `truncate` like with the shared memory object.
626 Take in care that when the last process attached to a shared memory is destroyed
627 [*the shared memory is destroyed] so there is [*no persistency] with native windows
628 shared memory.
630 Sharing memory between services and user applications is also different. To share memory
631 between services and user applications the name of the shared memory must start with the
634 the shared memory in the global namespace. Then a client session can use the "Global\" prefix
635 to open that memory.
637 The creation of a shared memory object in the global namespace from a session other than
640 Let's repeat the same example presented for the portable shared memory object:
642 shared memory object, maps it and initializes all the bytes to a value. After that,
643 a client process opens the shared memory, maps it, and checks
645 the client connects to the shared memory the client connection will fail], because
646 the shared memory segment is destroyed when no proces is attached to the memory.
653 As we can see, native windows shared memory needs synchronization to make sure
654 that the shared memory won't be destroyed before the client is launched.
658 [section:xsi_shared_memory XSI shared memory]
660 In many UNIX systems, the OS offers another shared memory memory mechanism, XSI
661 (X/Open System Interfaces) shared memory segments, also known as "System V" shared memory.
662 This shared memory mechanism is quite popular and portable, and it's not based in file-mapping
665 Unlike POSIX shared memory segments, XSI shared memory segments are not identified by names but
666 by 'keys' usually created with `ftok`. XSI shared memory segments have kernel lifetime and
667 must be explicitly removed. XSI shared memory does not support copy-on-write and partial shared mem…
668 but it supports anonymous shared memory.
672 shared memory classes to ease the use of XSI shared memory. It also wraps key creation with the
675 Let's repeat the same example presented for the portable shared memory object:
676 A server process creates a shared memory object, maps it and initializes all the bytes to a value. …
677 a client process opens the shared memory, maps it, and checks
689 [section:mapped_file Memory Mapped Files]
691 [section:mapped_file_what_is What is a memory mapped file?]
701 the file using pointers, just like with dynamic memory. File mapping has the following
704 * Uniform resource use. Files and memory can be treated using the same functions.
707 * Shared memory between two or more applications.
708 * Allows efficient work with a large files, without mapping the whole file into memory
714 write the file. The user just writes data to the process memory, and the operating
717 When two processes map the same file in memory, the memory that one process writes is
718 seen by another process, so memory mapped files can be used as an interprocess
719 communication mechanism. We can say that memory-mapped files offer the same interprocess
720 communication services as shared memory with the addition of filesystem persistence.
721 However, as the operating system has to synchronize the file contents with the memory
722 contents, memory-mapped files are not as fast as shared memory.
728 To use memory-mapped files, we have to perform 2 basic steps:
735 calling process. The operating system looks for a big enough memory address range
778 [section:mapped_file_mapping_regions Mapping File's Contents In Memory]
780 After creating a file mapping, a process just has to map the shared memory in the
781 process' address space. The user can map the whole shared memory or just part of it.
783 The class represents a memory region that has been mapped from a shared memory or from other
793 ( m_file //Memory-mappable object
811 If several processes map the same file, and a process modifies a memory range
815 is several times slower than writing to memory). If the user wants to make sure
828 //Flush a memory range starting on an offset
842 Let's reproduce the same example described in the shared memory section, using
843 memory mapped files. A server process creates a shared
844 memory segment, maps it and initializes all the bytes to a value. After that,
845 a client process opens the shared memory, maps it, and checks
860 to create `mapped_region` objects. A mapped region created from a shared memory
863 One can, for example, mix in STL containers mapped regions from shared memory
864 and memory mapped files. Libraries that only depend on mapped regions can
865 be used to work with shared memory or memory mapped files without recompiling them.
871 In the example we have seen, the file or shared memory contents are mapped
875 If several processes map the same file/shared memory, the mapping address will be
877 in a different way (allocation of more or less dynamic memory, for example), there is
878 no guarantee that the file/shared memory is going to be mapped in the same address.
881 of pointers in that memory, since the pointer (which is an absolute address) would
884 shared memory segment by one process, [*the address of each object will be different]
887 So the first advice when mapping shared memory and memory mapped files is to avoid
892 can be safely placed in shared memory and that can be used to point to another
893 object placed in the same shared memory / memory mapped file.
900 can succeed mapping the same file or shared memory object in the same address in two
908 mapped_region region ( shm //Map shared memory
923 As mentioned, the user can't map the memory mappable object at any address and it can
938 mapped_region region1( shm //Map shared memory
946 mapped_region region2( shm //Map shared memory
959 //Map one byte of the shared memory object.
960 //A whole memory page will be used for this.
961 mapped_region region ( shm //Map shared memory
975 mapped_region region1( shm //Map shared memory
983 mapped_region region2( shm //Map shared memory
986 , 3*page_size/2 //Map the rest of the shared memory
994 mapped_region region1( shm //Map shared memory
1001 mapped_region region2( shm //Map shared memory
1015 The operating system might also limit the number of mapped memory regions per
1025 can communicate writing and reading that memory. A process could construct a C++ object
1026 in that memory so that the second process can use it. However, a mapped region shared
1058 if the user wants to put an object in shared memory,
1063 base address in all processes sharing a memory segment.
1075 pointer placed in shared memory will be invalid for other processes
1112 When creating shared memory and memory mapped files to communicate two
1113 processes the memory segment can be mapped in a different address in each process:
1123 //Open a shared memory segment
1130 //Map the whole shared memory
1132 ( shm //Memory-mappable object
1244 As mentioned before, the ability to shared memory between processes through memory
1245 mapped files or shared memory objects is not very useful if the access to that
1246 memory can't be effectively synchronized. This is the same problem that happens with
1247 thread-synchronization mechanisms, where heap memory and global variables are
1266 share [*the same object] through shared memory or memory mapped files. This is
1269 memory is shared between threads of the same process, sharing objects between
1271 that map the same mappable resource (for example, shared memory or memory mapped files).
1276 don't have to create a shared memory region and construct the synchronization mechanism there.
1278 * Anonymous utilities can be serialized to disk when using memory mapped objects obtaining
1280 utility in a memory mapped file, reboot the system, map the file again, and use the
1416 anonymous mutex that can be placed in shared memory or memory mapped files.
1423 anonymous mutex that can be placed in shared memory or memory mapped files.
1510 in shared memory. Each process needs to obtain exclusive access to the
1521 This is the process main process. Creates the shared memory, constructs
1527 The second process opens the shared memory, obtains access to the cyclic buffer
1586 An anonymous condition variable that can be placed in shared memory or memory
1594 An anonymous condition variable that can be placed in shared memory or memory
1628 Imagine that a process that writes a trace to a simple shared memory buffer that
1635 The shared memory trace buffer (doc_anonymous_condition_shared_data.hpp):
1640 This is the process main process. Creates the shared memory, places there
1647 The second process opens the shared memory and prints each message
1692 An anonymous semaphore that can be placed in shared memory or memory
1706 We will implement an integer array in shared memory that will be used to transfer data
1718 This is the process main process. Creates the shared memory, places there
1725 The second process opens the shared memory and copies the received integers
2074 anonymous sharable mutex that can be placed in shared memory or memory mapped files.
2090 anonymous upgradable mutex that can be placed in shared memory or memory mapped files.
2581 in a shared memory segment: any process connected to that memory can overwrite the
2904 define the resources (for example the size of the shared memory used to implement
2905 the message queue if shared memory is used).
2983 [section:managed_memory_segments Managed Memory Segments]
2989 As we have seen, [*Boost.Interprocess] offers some basic classes to create shared memory
2992 However, managing those memory segments is not not easy for non-trivial tasks.
2993 A mapped region is a fixed-length memory buffer and creating and destroying objects
2995 a memory management algorithm to allocate portions of that segment.
2996 Many times, we also want to associate names to objects created in shared memory, so
2999 [*Boost.Interprocess] offers 4 managed memory segment classes:
3001 * To manage a shared memory mapped region ([*basic_managed_shared_memory] class).
3002 * To manage a memory mapped file ([*basic_managed_mapped_file]).
3003 * To manage a heap allocated (`operator new`) memory buffer ([*basic_managed_heap_memory] class).
3006 The first two classes manage memory segments that can be shared between processes. The
3008 message queues to other processes. The fourth class can manage any fixed size memory
3012 The most important services of a managed memory segment are:
3014 * Dynamic allocation of portions of a memory the segment.
3015 * Construction of C++ objects in the memory segment. These objects can be anonymous
3018 * Customization of many features: memory allocation algorithm, index types or
3026 [section:managed_memory_segment_int Declaration of managed memory segment classes]
3028 All [*Boost.Interprocess] managed memory segment classes are templatized classes
3047 * *MemoryAlgorithm* is the memory algorithm used to allocate portions of the
3049 memory algorithm also define:
3056 by the memory allocation algorithm or additional helper structures
3058 allocators and containers to be used with this managed memory segment
3060 will define if the managed memory segment can be mapped between
3066 * See [link interprocess.customizing_interprocess.custom_interprocess_alloc Writing a new memory
3067 allocation algorithm] for more details about memory algorithms.
3073 objects in the memory segment, we can plug new shared memory allocation
3080 [section:managed_shared_memory Managed Shared Memory]
3082 [section:managed_memory_common_shm Common Managed Shared Memory Classes]
3085 for the average user, a common, default shared memory named object creation is needed.
3086 Because of this, [*Boost.Interprocess] defines the most common managed shared memory
3091 //!Defines a managed shared memory with c-strings as keys for named objects,
3092 //!the default memory algorithm (with process-shared mutexes,
3093 //!and offset_ptr as internal pointers) as memory allocation algorithm
3095 //!This class allows the shared memory to be mapped in different base
3099 … ,/*Default memory algorithm defining offset_ptr<void> as void_pointer*/
3103 //!Defines a managed shared memory with wide strings as keys for named objects,
3104 //!the default memory algorithm (with process-shared mutexes,
3105 //!and offset_ptr as internal pointers) as memory allocation algorithm
3107 //!This class allows the shared memory to be mapped in different base
3111 … ,/*Default memory algorithm defining offset_ptr<void> as void_pointer*/
3115 `managed_shared_memory` allocates objects in shared memory associated with a c-string and
3116 `wmanaged_shared_memory` allocates objects in shared memory associated with a wchar_t null
3118 used to map the shared memory at different base addresses in different processes.
3120 If the user wants to map the shared memory in the same address in all processes and
3126 //!Defines a managed shared memory with c-strings as keys for named objects,
3127 //!the default memory algorithm (with process-shared mutexes,
3128 //!and offset_ptr as internal pointers) as memory allocation algorithm
3130 //!This class allows the shared memory to be mapped in different base
3134 ,/*Default memory algorithm defining void * as void_pointer*/
3138 //!Defines a managed shared memory with wide strings as keys for named objects,
3139 //!the default memory algorithm (with process-shared mutexes,
3140 //!and offset_ptr as internal pointers) as memory allocation algorithm
3142 //!This class allows the shared memory to be mapped in different base
3146 ,/*Default memory algorithm defining void * as void_pointer*/
3152 [section:constructing_managed_shared_memories Constructing Managed Shared Memory]
3154 Managed shared memory is an advanced class that combines a shared memory object
3155 and a mapped region that covers all the shared memory object. That means that
3156 when we [*create] a new managed shared memory:
3158 * A new shared memory object is created.
3159 * The whole shared memory object is mapped in the process' address space.
3162 managed memory segment features.
3164 When we [*open] a managed shared memory
3166 * A shared memory object is opened.
3167 * The whole shared memory object is mapped in the process' address space.
3169 To use a managed shared memory, you must include the following header:
3178 //1. Creates a new shared memory object
3182 //3. Constructs some objects in shared memory
3187 , "MySharedMemory" //Shared memory object name
3188 , 65536); //Shared memory object size in bytes
3193 //1. Opens a shared memory object
3201 … managed_shared_memory segment (open_only, "MySharedMemory");//Shared memory object name
3212 , "MySharedMemory" //Shared memory object name
3213 , 65536); //Shared memory object size in bytes
3216 When the `managed_shared_memory` object is destroyed, the shared memory
3218 the shared memory object from the system you must use the `shared_memory_object::remove`
3219 function. Shared memory object removing might fail if any
3220 process still has the shared memory object mapped.
3222 The user can also map the managed shared memory in a fixed address. This option is
3228 …hared_memory segment (open_only ,"MyFixedAddressSharedMemory" //Shared memory object name
3233 [section:windows_managed_memory_common_shm Using native windows shared memory]
3235 Windows users might also want to use native windows shared memory instead of
3237 managed memory. This is achieved through the
3247 but uses native windows shared memory. Note that this managed class has the same
3248 lifetime issues as the windows shared memory: when the last process attached to the
3249 windows shared memory is detached from the memory (or ends/crashes) the memory is
3250 destroyed. So there is no persistence support for windows shared memory.
3254 …cess.sharedmemorybetweenprocesses.sharedmemory.windows_shared_memory Native windows shared memory].
3258 [section:xsi_managed_memory_common_shm Using XSI (system V) shared memory]
3262 managed memory. This is achieved through the
3272 but uses XSI shared memory as backend.
3276 For more information about managed XSI shared memory capabilities, see
3286 for the average user, a common, default shared memory named object creation is needed.
3292 //Named object creation managed memory segment
3293 //All objects are constructed in the memory-mapped file
3295 // Default memory management algorithm(rbtree_best_fit with no mutexes)
3303 //Named object creation managed memory segment
3304 //All objects are constructed in the memory-mapped file
3306 // Default memory management algorithm(rbtree_best_fit with no mutexes)
3314 `managed_mapped_file` allocates objects in a memory mapped files associated with a c-string
3315 and `wmanaged_mapped_file` allocates objects in a memory mapped file associated with a wchar_t null
3331 managed memory segment features.
3350 //3. Constructs some objects in the memory mapped
3386 if any process still has the file mapped in memory or the file is open
3401 [section:managed_memory_segment_features Managed Memory Segment Features]
3403 The following features are common to all managed memory segment classes, but
3404 we will use managed shared memory in our examples. We can do the same with
3405 memory mapped files or other managed memory segment classes.
3407 [section:allocate_deallocate Allocating fragments of a managed memory segment]
3409 If a basic raw-byte allocation is needed from a managed memory
3410 segment, (for example, a managed shared memory), to implement
3415 if there is no more memory and the non-throwing version returns 0 pointer.
3425 a managed memory segment and a handle that can be passed using any
3427 address using a managed memory segment that also contains that object.
3429 of a managed memory segment or objects constructed in the managed segment.
3447 When constructing objects in a managed memory segment (managed shared memory,
3505 memory segment. All named object construction functions are available to construct
3526 Sometimes, the user wants to emulate a singleton in a managed memory segment. Obviously,
3527 as the managed memory segment is constructed at run-time, the user must construct and
3529 object of its type in the managed memory segment? This can be emulated using
3534 To solve this, [*Boost.Interprocess] offers a "unique object" creation in a managed memory segment.
3535 Only one instance of a class can be created in a managed memory segment using this
3538 to design pooled, shared memory allocators. The object can be searched using the type
3570 internal `mutex_family` typedef defined of the memory allocation algorithm template
3573 `MemoryAlgorithm::mutex_family::recursive_mutex_type` type. For shared memory,
3574 and memory mapped file based managed segments this recursive mutex is defined
3591 it has to allocate raw memory to construct the new value.
3595 process if that process is inserting elements in a shared memory vector.
3601 As seen, managed memory segments, when creating named objects, store the name/object
3607 memory use, and memory allocation patterns. [*Boost.Interprocess] offers 3 index types
3612 minimum memory use. But the vector must be reallocated when is full, so all data
3616 * [*boost::interprocess::map_index map_index]: Based on boost::interprocess::map, a managed memory…
3623 memory segment just for raw memory buffer allocations and they don't make use
3626 If you try to use named object creation with a managed memory segment using this
3629 As an example, if we want to define new managed shared memory class
3635 //This managed memory segment can allocate objects with:
3638 // as memory allocation algorithm.
3656 All [*Boost.Interprocess] managed memory segment classes construct in their
3657 respective memory segments (shared memory, memory mapped files, heap memory...)
3658 some structures to implement the memory management algorithm, named allocations,
3660 called [*segment manager]. A managed memory mapped file and a managed shared
3661 memory use the same [*segment manager] to implement all managed memory segment
3663 a fixed size memory buffer. Since both shared memory or memory mapped files
3665 memory buffer, a single [*segment manager] class can manage several managed
3666 memory segment types.
3670 memory segment using `get_segment_manager` member:
3722 Note that `atomic_func` does not prevent other processes from allocating raw memory
3733 [section:managed_memory_segment_advanced_features Managed Memory Segment Advanced Features]
3737 These functions are available to obtain information about the managed memory segments:
3739 Obtain the size of the memory segment:
3751 Clear to zero the free memory:
3757 Know if all memory has been deallocated, false otherwise:
3800 Please, remember that [*no process should be modifying the file/shared memory while
3813 performance. (If the index is an ordered vector it can preallocate memory to avoid
3816 The following functions reserve memory to make the subsequent allocation of
3832 Managed memory segments also offer the possibility to iterate through
3837 be concurrently executed (raw memory allocation/deallocations, for example).
3874 [section:allocate_aligned Allocating aligned memory portions]
3876 Sometimes it's interesting to be able to allocate aligned fragments of memory
3878 aligned memory is a feature that can be used to improve several
3879 memory algorithms.
3881 This allocation is similar to the previously shown raw memory allocation but
3886 the size that minimizes the memory waste is a value that's is nearly a multiple
3888 every memory allocation usually needs some additional metadata in the first
3890 and if the first bytes of a free block of memory are used to fulfill the aligned
3893 because lefts the next block of memory unaligned due to the needed metadata.
3895 Once the programmer knows the size of the payload of every memory allocation,
3897 of memory maximizing both the size of the
3899 is stored in the PayloadPerAllocation constant of managed memory segments.
3912 If an application needs to allocate a lot of memory buffers but it needs
3914 calling `allocate()`. Managed memory segments offer an alternative function
3915 to pack several allocations in a single call obtaining memory buffers that:
3917 * are packed contiguously in memory (which improves locality)
3922 must provide a contiguous memory segment big enough to hold all the allocations.
3923 Managed memory segments offer this functionality through `allocate_many()` functions.
3926 * Allocation of N buffers of memory with the same size.
3927 * Allocation of N buffers of memory, each one of different size.
3970 initialization, but it still can deallocate and expand the memory of the variable
3974 of `allocate_many` can increase the effective memory usage,
3975 because it can't reuse existing non-contiguous memory fragments that
3980 [section:managed_memory_segment_expand_in_place Expand in place memory allocation]
3982 When programming some data structures such as vectors, memory reallocation becomes
3983 an important tool to improve performance. Managed memory segments offer an advanced
3994 is moved backwards. The memory between the new end and the old end can be reused
4003 the memory use using `allocation_command`.
4045 will try to reduce the size of the memory block referenced by pointer `reuse_ptr`
4047 If it's not possible, it will try to reduce the size of the memory block as
4053 memory block referenced by pointer reuse moving only the end of the block to the
4055 of the memory block as much as possible as long as this results in
4060 the memory block referenced by pointer `reuse_ptr` only moving the start of the
4067 …additional `boost::interprocess::nothrow_allocation`), the allocator will try to allocate memory f…
4068 `preferred_size` objects. If it's not possible it will try to allocate memory for
4095 * The allocator always writes the size or the expanded/allocated/shrunk memory block
4101 * The allocator is unable to allocate/expand/shrink the memory or there is an
4108 * The address of the allocated memory or the new address of the expanded memory
4113 * The second member of the pair will be false if the memory has been allocated,
4114 true if the memory has been expanded. If the first member is 0, the second member
4137 requests and the memory waste.
4141 [section:copy_on_write_read_only Opening managed shared memory and mapped files with Copy On Write …
4143 When mapping a memory segment based on shared memory or files, there is an option to
4146 and is not translated to the underlying device (shared memory or file).
4148 The underlying shared memory or file is opened as read-only so several processes can
4151 segment will be shared between all those processes, with considerable memory savings.
4153 Opening managed shared memory and mapped files with [*open_read_only] maps the
4154 underlying device in memory with [*read-only] attributes. This means that any attempt
4155 to write that memory, either creating objects or locking any mutex might result in an
4157 the underlying device (shared memory, file...) in read-only mode and
4158 can result in considerable memory savings if several processes just want to process
4159 a managed memory segment without modifying it. Read-only mode operations are limited:
4164 and does not nothing about the mode it's been mapped in memory.
4180 [section:managed_heap_memory_external_buffer Managed Heap Memory And Managed External Buffer]
4182 [*Boost.Interprocess] offers managed shared memory between processes using
4184 the memory mappable resource and read from and write to that object.
4186 Many times, we don't want to use that shared memory approach and we prefer
4196 Applications for [*Boost.Interprocess] services using non-shared memory buffers:
4199 in systems where dynamic memory is not recommendable.
4220 a memory-mapped auxiliary device or any other user buffer.
4224 maps, lists.... [*Boost.Interprocess] offers managed memory segment classes to handle user
4225 provided buffers that allow the same functionality as shared memory classes:
4229 //Named object creation managed memory segment
4238 //Named object creation managed memory segment
4241 // Default memory management algorithm
4250 //Named object creation managed memory segment
4253 // Default memory management algorithm
4278 the used memory to a predefined memory chunk, instead of letting the database
4279 fragment the heap memory.
4283 [section:managed_heap_memory Managed Heap Memory: Boost.Interprocess machinery in heap memory]
4285 The use of heap memory (new/delete) to obtain a buffer where the user wants to store all
4287 classes that work exclusively with heap memory.
4293 //Named object creation managed memory segment
4302 //Named object creation managed memory segment
4305 // Default memory management algorithm
4314 //Named object creation managed memory segment
4317 // Default memory management algorithm
4326 To use a managed heap memory, you must include the following header:
4334 except that memory is created by
4335 the managed memory segment itself using dynamic (new/delete) memory.
4338 tries to resize internal heap memory so that we have room for more objects.
4339 But *be careful*, if memory is reallocated, the old buffer will be copied into
4350 [section:managed_heap_memory_external_buffer_diff Differences between managed memory segments]
4352 All managed memory segments have similar capabilities
4353 (memory allocation inside the memory segment, named object construction...),
4357 * Default specializations of managed shared memory and mapped file use process-shared
4358 mutexes. Heap memory and external buffer have no internal synchronization by default.
4360 memory mapped files could be used just to obtain a persistent object data-base for a
4365 * The first two create a system-global object (a shared memory object or a file) shared
4373 To see the utility of managed heap memory and managed external buffer classes,
4375 database constructed in a memory buffer using [*Boost.Interprocess], send the database
4387 [section:allocators_containers Allocators, containers and memory allocation algorithms]
4391 As seen, [*Boost.Interprocess] offers raw memory allocation and object construction
4392 using managed memory segments (managed shared memory, managed mapped files...) and
4394 To achieve this, [*Boost.Interprocess] makes use of managed memory segment's
4395 memory allocation algorithms to build several memory allocation schemes, including
4402 memory mapped in different base addresses in several processes.
4410 On the other hand, [*Boost.Interprocess] allocators need to allocate memory from a
4411 concrete memory segment and not from a system-wide memory source (like the heap).
4413 configured to tell them where the shared memory or the memory mapped file is.
4417 their constructor receive a pointer to the segment manager of the managed memory
4459 Unfortunately, this approach is not valid with shared memory. Using heap allocators, if
4462 allocator of Group2. But when the user wants to swap two shared memory allocators, each one
4463 placed in a different shared memory segment, this is not possible. As generally shared memory
4465 to any object placed in other shared memory segment, since in each process, the distance between
4466 the segments is different. However, if both shared memory allocators are in the same segment,
4470 swap function that swaps internal pointers. If an allocator placed in a shared memory segment is
4471 swapped with other placed in a different shared memory segment, the result is undefined. But a
4476 [section:allocator allocator: A general purpose allocator for managed memory segments]
4479 uses the managed memory segment's algorithm to allocate and deallocate memory. This is
4480 achieved through the [*segment manager] of the managed memory segment. This allocator
4481 is the equivalent for managed memory segments of the standard `std::allocator`.
4529 Variable size memory algorithms waste
4531 usually for small objects, this is not acceptable. Memory algorithms can
4532 also fragment the managed memory segment under some allocation and
4539 allocators allocate large memory chunks from a general purpose memory
4541 is stored in the nodes to achieve minimal memory waste: free nodes are linked
4542 using a pointer constructed in the memory of the node.
4567 * `std::size_t NodesPerChunk`: The number of nodes that a memory chunk will contain.
4568 This value will define the size of the memory the pool will request to the
4572 traverse all the memory chunks of the pool and will return to the managed memory segment
4573 the free chunks of memory. If this function is not used, deallocating the free chunks does
4574 not happen until the pool is destroyed so the only way to return memory allocated
4582 For heap-memory node allocators (like [*Boost.Pool's] `boost::fast_pool_allocator`
4595 objects built inside a memory segment share a unique memory pool.
4600 This saves a lot of memory but also imposes an synchronization overhead for each
4650 memory usage. However, it needs a unique/named object construction feature
4657 the memory as soon as possible.
4666 instances [*never] compare equal. Memory allocated with one allocator [*can't] be
4703 can impose a unacceptable memory waste for other applications.
4770 when a node is deallocated, it's stored in a free list of nodes but memory is not
4777 that won't be reused wasting memory from the segment.
4781 of nodes to the memory segment, so that they can be used by any other container or managed
4804 * `std::size_t NodesPerChunk`: The number of nodes that a memory chunk will contain.
4805 This value will define the size of the memory the pool will request to the
4812 traverse all the memory chunks of the pool and will return to the managed memory segment
4813 the free chunks of memory. This function is much faster than for segregated storage
4879 instances [*never] compare equal. Memory allocated with one allocator [*can't] be
4977 [section:containers_explained Interprocess and containers in managed memory segments]
4983 they can be used to place STL containers in shared memory, memory mapped files or
4984 in a user defined memory segment.
5002 each one allocating from a different memory pool
5005 STL containers that we want to place in shared memory or memory
5008 * STL containers may not assume that memory allocated with
5011 only if memory allocated with one object can be deallocated
5023 [section:containers STL containers in managed memory segments]
5030 different from T* for pooled/node memory
5037 to be used in managed memory segments like shared memory. To use it include:
5044 to be used in managed memory segments like shared memory. To use it include:
5051 to be used in managed memory segments like shared memory. To use it include:
5058 to be used in managed memory segments like shared memory. To use it include:
5069 to be used in managed memory segments like shared memory. To use them include:
5081 from Loki library, ready for the shared memory. These classes offer the same
5093 to be used in managed memory segments like shared memory.
5107 To place any of these containers in managed memory segments, we must
5109 so that the container allocates the values in the managed memory segment.
5110 To place the container itself in shared memory, we construct it
5111 in the managed memory segment just like any other object with [*Boost.Interprocess]:
5117 an existing container making possible to place it in shared memory.
5123 [*Boost.Interprocess] containers are placed in shared memory/memory mapped files,
5127 functions place a C++ object in the shared memory/memory mapped file. But this
5128 places only the object, but *not* the memory that this object may allocate dynamically.
5130 * Shared memory allocators. These allow allocating shared memory/memory mapped file
5131 portions so that containers can allocate dynamically fragments of memory to store
5135 [*Boost.Interprocess] strings) in shared memory or memory mapped files,
5143 in the managed memory.
5146 you are creating a container placed *only* in your process but that allocates memory
5147 for contained types from shared memory/memory mapped file.
5184 Here we have an example that builds a map in shared memory. Key is a string
5203 hash containers in shared memory and memory mapped files. Here is a small example storing
5204 `unordered_map` in shared memory:
5214 we can construct pretty good databases in shared memory. Constructing databases in shared
5215 memory is a bit tougher than in normal memory, usually because those databases contain strings
5216 and those strings need to be placed in shared memory. Shared memory strings require
5220 Here is an example that shows how to put a multi index container in shared memory:
5227 Programmers can place [*Boost.CircularBuffer] containers in sharecd memory provided
5236 [section:memory_algorithms Memory allocation algorithms]
5238 [section:simple_seq_fit simple_seq_fit: A simple shared memory management algorithm]
5241 linked list of free memory buffers. The algorithm is based
5242 on the article about shared memory titled
5243 [@http://home.earthlink.net/~joshwalker1/writing/SharedMemory.html ['"Taming Shared Memory"] ].
5246 The shared memory is divided in blocks of free shared memory,
5247 each one with some control data and several bytes of memory
5256 simple_seq_fit memory layout:
5269 When a user requests N bytes of memory, the allocator
5272 size as the requested memory, we erase the block from
5285 To ease implementation, the size of the free memory block
5292 the performance of this algorithm suffers when the memory is fragmented. This
5306 portions of the memory segment by size. This allows logarithmic complexity
5307 allocation. Apart from this, a doubly-linked list of all portions of memory
5312 since it's no longer used once the memory is allocated. This maintains the memory
5318 rbtree_best_fit memory layout:
5328 This allocation algorithm is pretty fast and scales well with big shared memory
5329 segments and big number of allocations. To form a block a minimum memory size is needed:
5339 * 24 bytes of memory from the segment are used to form a block.
5342 For really small allocations (<= 8 bytes), this algorithm wastes more memory than the
5344 For allocations bigger than 8 bytes the memory overhead is exactly the same.
5345 This is the default allocation algorithm in [*Boost.Interprocess] managed memory
5354 Shared memory, memory-mapped files and all [*Boost.Interprocess] mechanisms are focused
5355 on efficiency. The reason why shared memory is used is that it's the
5357 shared memory, there is need to format the message. Obviously C++ offers
5360 Some programmers appreciate the iostream safety and design for memory
5395 The problem is even worse if the string is a shared-memory string, because
5396 to extract data, we must copy the data first from shared-memory to a
5397 `std::string` and then to a `std::stringstream`. To encode data in a shared memory
5399 to the shared-memory string.
5401 Because of this overhead, [*Boost.Interprocess] offers a way to format memory-strings
5402 (in shared memory, memory mapped files or any other memory segment) that
5403 can avoid all unneeded string copy and memory allocation/deallocations, while
5414 a shared-memory vector is used, data is extracted/written from/to the shared-memory
5460 //!Preallocates memory from the internal vector.
5462 //!Throws if the internals vector's memory allocation throws.
5494 iostream interface with direct formatting in a fixed size memory buffer with
5554 bufferstream class comes handy to format data to stack, static or shared memory
5567 When building complex shared memory/memory mapped files structures, programmers
5569 Boost and C++ TR1 smart pointers are not ready to be used for shared memory. The cause
5571 something that is not possible if you want to place your data in shared memory.
5606 shared memory we must specify a relative pointer type like
5648 reference-counted objects in managed shared memory or mapped files.
5689 can create objects in shared memory that hold shared pointers pointing
5690 to other objects also in shared memory, obtaining the benefits of
5691 reference counting. Let's see how to create a shared pointer in a managed shared memory:
5783 memory and memory-mapped files.
5819 [*Boost.Interprocess] has chosen kernel or filesystem persistence for shared memory
5820 and named synchronization mechanisms. Process persistence for shared memory is also
5828 why [*Boost.Interprocess] is based on templates and memory algorithms, index types,
5833 can concurrently allocate raw memory when expanding a shared memory vector while another
5842 [*Boost.Interprocess] is built above 3 basic classes: a [*memory algorithm], a
5843 [*segment manager] and a [*managed memory segment]:
5847 [section:architecture_algorithm_to_managed From the memory algorithm to the managed segment]
5849 [section:architecture_memory_algorithm The memory algorithm]
5851 The [*memory algorithm] is an object that is placed in the first bytes of a
5852 shared memory/memory mapped file segment. The [*memory algorithm] can return
5854 portions to the [*memory algorithm] so that the [*memory algorithm] mark them as free
5855 again. There is an exception though: some bytes beyond the end of the memory
5860 To sum up, a [*memory algorithm] has the same mission as malloc/free of
5862 where it is placed. The layout of a memory segment would be:
5866 Layout of the memory segment:
5869 | memory | reserved | The memory algorithm will return portions |
5874 The [*memory algorithm] takes care of memory synchronizations, just like malloc/free
5876 achieved placing a process-shared mutex as a member of the memory algorithm. Take
5877 in care that the memory algorithm knows [*nothing] about the segment (if it is
5878 shared memory, a shared memory file, etc.). For the memory algorithm the segment
5879 is just a fixed size memory buffer.
5881 The [*memory algorithm] is also a configuration point for the rest of the
5892 [*Boost.Interprocess] framework (segment manager, allocators, containers). If the memory
5893 algorithm is ready to be placed in a shared memory/mapped file mapped in different base
5895 pointer. If the [*memory algorithm] will be used just with fixed address mapping,
5898 The rest of the interface of a [*Boost.Interprocess] [*memory algorithm] is described in
5899 [link interprocess.customizing_interprocess.custom_interprocess_alloc Writing a new shared memory a…
5900 section. As memory algorithm examples, you can see the implementations
5909 managed memory segment (shared memory, memory mapped file), that offers more
5910 sophisticated services built above the [*memory algorithm]. How can [*both] the
5911 segment manager and memory algorithm be placed in the beginning of the segment?
5912 That's because the segment manager [*owns] the memory algorithm: The
5913 truth is that the memory algorithm is [*embedded] in the segment manager:
5918 The layout of managed memory segment:
5921 | some | memory | other |<- The memory algorithm considers
5922 |members|algorithm|members| "other members" as reserved memory, so
5926 | segment manager | The memory algorithm will return portions |
5931 The [*segment manager] initializes the memory algorithm and tells the memory
5932 manager that it should not use the memory where the rest of the
5935 (defined by the memory algorithm's [*mutex_family::recursive_mutex] typedef member),
5947 The memory needed to store [name pointer, object information] pairs in the index is
5948 allocated also via the *memory algorithm*, so we can tell that internal indexes
5949 are just like ordinary user objects built in the segment. The rest of the memory
5951 destruction/deallocation is allocated using the *memory algorithm* in a single
5954 As seen, the [*segment manager] knows [*nothing] about shared memory/memory mapped files.
5956 it just asks the *memory algorithm* to allocate the needed memory from the rest
5957 of the segment. The [*segment manager] is a class built above the memory algorithm
5972 to be used to identify named objects, we can specify the memory algorithm that will
5973 control dynamically the portions of the memory segment, and we can specify
5980 [section:architecture_managed_memory Boost.Interprocess managed memory segments]
5982 The [*Boost.Interprocess] managed memory segments that construct the shared memory/memory
5985 is a [*Boost.Interprocess] managed memory segment that works with shared memory.
5986 …process::basic_managed_mapped_file basic_managed_mapped_file] works with memory mapped files, etc.…
5988 Basically, the interface of a [*Boost.Interprocess] managed memory segment is the same as
5990 shared memory/memory-mapped files segments and initialize all needed resources.
5991 Managed memory segment classes are not built in shared memory or memory mapped files, they
5993 in shared memory or memory mapped files).
5995 Apart from this, managed memory segments offer specific functions: `managed_mapped_file`
5996 offers functions to flush memory contents to the file, `managed_heap_memory` offers
5997 functions to expand the memory, etc...
5999 Most of the functions of [*Boost.Interprocess] managed memory segments can be shared
6000 between all managed memory segments, since many times they just forward the functions
6002 in [*Boost.Interprocess] all managed memory segments derive from a common class that
6003 implements memory-independent (shared memory, memory mapped files) functions:
6007 Deriving from this class, [*Boost.Interprocess] implements several managed memory
6008 classes, for different memory backends:
6010 …oost::interprocess::basic_managed_shared_memory basic_managed_shared_memory] (for shared memory).
6011 …::interprocess::basic_managed_mapped_file basic_managed_mapped_file] (for memory mapped files).
6012 …interprocess::basic_managed_heap_memory basic_managed_heap_memory] (for heap allocated memory).
6029 memory allocation to named object creations. [*Boost.Interprocess] allocators always store
6030 a pointer to the segment manager, so that they can obtain memory from the segment or share
6042 memory segment managed by the segment manager, that is, shared memory, memory mapped files,
6051 * The pool allocates chunks of memory using the segment manager's raw memory
6055 * The rest of the memory of the chunk is divided in nodes of the requested size and
6056 no memory is used as payload for each node. Since the memory of a free node
6057 is not used that memory is used to place a pointer to form a singly linked list of
6063 * When the pool is destroyed, the list of chunks is traversed and memory is returned
6077 * Instead of using raw allocation, the pool allocates [*aligned] chunks of memory
6106 * When the pool is destroyed, the list of chunks is traversed and memory is returned
6120 * [*Boost.Interprocess] STL containers don't assume that memory allocated with
6127 allows placing containers in managed memory segments mapped in different base addresses.
6138 [section:performance_allocations Performance of raw memory allocations]
6140 You can have two types of raw memory allocations with [*Boost.Interprocess] classes:
6143 managed_shared_memory/managed_mapped_file... managed memory segments. This call is
6145 will need just the time that the memory algorithm associated with the managed memory segment
6153 If you see that memory allocation is a bottleneck in your application, you have
6167 can save a lot of memory. See
6171 * Write your own memory algorithm. If you have experience with memory allocation algorithms
6173 you can specify it in all [*Boost.Interprocess] managed memory segments. See the section
6174 ….customizing_interprocess.custom_interprocess_alloc Writing a new shared memory allocation algorit…
6193 This can require a call to the memory algorithm allocation function if
6216 * Deallocate the memory buffer containing the name, metadata and the object itself
6239 * Deallocate the memory buffer containing the name, metadata and the object itself
6248 application serves several clients try to build a new managed memory segment
6268 [section:custom_interprocess_alloc Writing a new shared memory allocation algorithm]
6273 the algorithm must be compatible with shared memory, so it shouldn't have any
6291 //!Constructor. "size" is the total size of the managed memory segment,
6299 //!Allocates bytes, returns 0 if there is not more memory
6305 //!Returns the size of the memory segment
6308 //!Increases managed memory in extra_size bytes more
6359 * [*size] indicates the total size of the managed memory segment, and
6361 of the memory segment.
6366 So, [*my_algorithm] will be placed at address XXX of the memory segment, and will
6372 be used to check if the memory segment is big enough to place the algorithm there.
6374 * The [*allocate()] function must return 0 if there is no more available memory.
6375 The memory returned by [*my_algorithm]
6376 must be aligned to the most restrictive memory alignment of the system.
6390 * The [*grow()] function will expand the managed memory by [*my_algorithm] in [*extra_size]
6392 and the new managed memory range will be (if the address where the algorithm is
6396 That's it. Now we can create new managed shared memory that uses our new algorithm:
6400 //Managed memory segment to allocate named (c-string) objects
6401 //using a user-defined memory allocation algorithm
6412 can implement another STL compatible allocator using raw memory allocation
6415 schemes on top of basic shared memory allocation schemes,
6419 When using a managed memory segment, [*get_segment_manager()]
6421 the raw memory allocation and named object construction functions can be
6426 //Create the managed shared memory and initialize resources
6441 //Initialize the custom, managed memory segment compatible
6451 //Construct the vector in shared memory with the allocator as constructor parameter
6455 to all memory management/object construction functions. All [*Boost.Interprocess]' STL
6457 managed memory segments, allocators should define their *pointer* typedef as the same
6461 the container in a managed memory segment, the allocator should be ready for that.
6467 The managed memory segment uses a name/object index to
6469 managed memory segments (`managed_shared_memory` for example),
6552 * The index must provide a memory reservation function, that optimizes the index if the
6594 Defining a new managed memory segment that uses the new index is easy. For
6595 example, a new managed shared memory that uses the new index:
6599 //!Defines a managed shared memory with a c-strings as
6601 //!and offset_ptr pointers) as raw shared memory management algorithm
6636 [section:notes_windows_shm_folder Shared memory emulation folder]
6638 Shared memory (`shared_memory_object`) is implemented in Windows using memory mapped files, placed …
6641 …a startup event (the default implementation), so that each bootup shared memory is created in a new
6642 folder obtaining kernel persistence shared memory.
6646 were directly created in shared documents folder, reverting to filesystem persistence shared memory…
6656 …_PATH` when using the library and that path will be used to place shared memory files. When you ha…
6683 [section:notes_linux_shm_folder Shared memory emulation folder]
6685 On systems without POSIX shared memory support, shared memory objects are implemented as memory map…
6688 …_PATH` when using the library and that path will be used to place shared memory files. When you ha…
6706 The committed address space is the total amount of virtual memory (swap or physical memory/RAM) tha…
6707 if all applications decide to access all of the memory they've requested from the kernel.
6708 …ult, Linux allows processes to commit more virtual memory than available in the system. If that me…
6709 accessed, no physical memory + swap is actually used.
6711 The reason for this behaviour is that Linux tries to optimize memory usage on forked processes; for…
6712 the process space, but with overcommitted memory, in this new forked instance only pages which have…
6713 …cated by the kernel. If applications access more memory than available, then the kernel must free …
6714 the OOM (Out Of Memory)-killer picks some processes to kill in order to recover memory.
6716 …no way to change this behaviour and users might suffer the OOM-killer when accessing shared memory.
6732 * ['kern.ipc.umtx_vnode_persistent]: By default, a shared lock backed by a mapped file in memory is…
6865 …This option derives the unique bootstamp used to name the folder where shared memory is placed fro…
6872 * [@https://svn.boost.org/trac/boost/ticket/12499 Trac #12499 (['"Memory allocation fails"])].
6908 …interprocess/pull/13 GitHub Pull #13 (['"haiku: we don't have XSI shared memory, so don't try to u…
6957 …RPROCESS_SHARED_DIR_PATH` option to define the shared directory used to place shared memory objects
6958 when implemented as memory mapped files.
6971 …t.org/trac/boost/ticket/7156 #7156] (['"interprocess buffer streams leak memory on construction"]]…
7037 ['"The effect of msync() on a shared memory object or a typed memory object is unspecified"] ].
7050 * Shared memory in windows has again kernel persistence: kernel bootstamp
7113 * Shared memory in windows has again filesystem lifetime: kernel bootstamp
7176 * Support for POSIX shared memory in Mac OS.
7184 * Windows shared memory is created in Shared Documents folder so that it can be shared
7201 * Shared memory in windows has now kernel lifetime instead of filesystem lifetime: shared
7202 memory will disappear when the system reboots.
7244 * Added anonymous shared memory for UNIX systems.
7246 * Fixed missing move semantics on managed memory classes.
7247 * Added copy_on_write and open_read_only options for shared memory and mapped file managed classes.
7287 implementation to a class that only depends on the memory algorithm, instead of
7293 * Added `aligned_allocate` and `allocate_many` functions to managed memory segments.
7295 * Improved documentation about managed memory segments.
7302 to managed memory segments.
7316 for shared memory names, leading to errors in some UNIX systems.
7322 * Added aligned memory allocation function to memory algorithms.
7338 * (multi)map/(multi)set now reuse memory from old nodes in the assignment operator.
7345 * Added function to zero free memory in memory algorithms and the segment manager.
7349 * Added support for intrusive index types in managed memory segments.
7350 Intrusive indexes save extra memory allocations to allocate the index
7386 * Added support for native windows shared memory.
7399 * [*Source breaking]: A shared memory object is now used including
7400 `shared_memory_object.hpp` header instead of `shared memory.hpp`.
7402 * [*ABI breaking]: Changed global mutex when initializing managed shared memory
7403 and memory mapped files. This change tries to minimize deadlocks.
7405 * [*Source breaking]: Changed shared memory, memory mapped files and mapped region's
7436 shared memory, allocators and containers used to design [*Boost.Interprocess].
7458 * A framework to put the STL in shared memory: [@http://allocator.sourceforge.net/ ['"A C++ Standar…
7460 …ects in shared memory: [@http://www.cs.ubc.ca/local/reading/proceedings/cascon94/htm/english/abs/h…
7462 * A shared memory allocator and relative pointer: [@http://home.earthlink.net/~joshwalker1/writing/…
7479 implementations use PTHREAD_PROCESS_SHARED attribute to place mutexes in shared memory,
7482 primitives in memory mapped files, so that we can get filesystem persistence just like
7502 [*Boost.Interprocess] does not define security attributes for shared memory and