Boost: pool of fixed-length memory pool

The memory pool can effectively reduce the number of dynamic memory requests, reduce interaction with the kernel state, improve system performance, reduce memory fragments, increase memory space usage, and avoid Memory leakage, there is no reason not to use this technology in the system for so many advantages.

Memory Pool category:

1. Unlimited memory pool. Typical implementations include apr_pool and obstack. The advantage is that you do not need to create different memory pools for different data types. The disadvantage is that the allocated memory cannot be recycled to the pool. This is because this scheme uses session as the granularity and the hierarchy of business processing as the basis for design.

2. fixed-length memory pool. Typical implementations include Loki and boost. The feature is to create memory pools for different types of data structures, and apply for memory from the corresponding memory pool when the memory is required. The advantage is that the memory can be immediately returned to the pool after use, more fine-grained control of memory blocks.
This type of memory pool is more common than variable length. On the other hand, it will waste a lot of memory for a large number of different data types. However, the main data structures of the system are generally not much, and they are repeatedly applied for release. In this case, the small disadvantage of the fixed-length memory pool can be ignored.

 

The boost library Pool provides a memory pool distributor for managing dynamic memory allocations in an independent and large allocation space. The boost library pool is mainly used to quickly allocate memory blocks of the same size, especially when the same size of memory blocks are repeatedly allocated and released. The pool memory pool has the following advantages:

1. It can effectively manage the allocation and release of many small objects, avoiding the memory fragmentation and inefficiency problems arising from managing the memory.

2. Do not worry about program memory leakage. The pool library automatically manages the memory internally, avoiding the memory leakage caused by a programmer's carelessness.

The pool Library provides four memory pool interfaces: pool, object_pool, singleton_pool, and pool_allocator/fast_pool_allocator.

1) Pool

Basic fixed-length memory pool

 

# Include <boost/pool. HPP>

Typedef struct student_st

{

Char name [10];

Int age;

} Cstudent;

Int main ()

{

Boost: pool <> student_pool (sizeof (cstudent ));

Cstudent * const OBJ = (cstudent *) student_pool.malloc ();

Student_pool.free (OBJ );

Return 0;

}

The pool template parameter has only one allocation subtype. Boost provides two types of default_user_allocator_new_delete/release, specifying whether to use new/delete or malloc/free when applying for memory release. The default value is default_user_allocator_new_delete. The constructor has two parameters: nrequested_size and nnext_size. Nrequested_size is the block size (because void * stores the serial number, boost has the built-in minimum block value, and nrequested_size is the built-in value if it is too small). When nnext_size is simple_segregated_storage, number of blocks applied. The default value is 32. The most comprehensive instantiation pool is like this: boost: pool <boost: default_user_allocator_malloc_free> student_pool (sizeof (cstudent), 255 );

The following functions are provided by the pool:

Malloc/free is implemented based on add_block/malloc/free, efficient

 

Ordered_malloc/ordered_free is implemented based on add_ordered_block/malloc/ordered_free. It has no meaning in the pool. Do not use it.

 

Release_memory/purge_memory: the former releases unused memory in the pool, and the latter releases all memory in the pool. Memory is also released by the other pool destructor.

 

 

2) object_pool

Object Memory Pool, which is the most failed memory pool design.

 

# Include <boost/pool/object_pool.hpp>

 

Class {

Public:

A (): Data _ (0 ){}

PRIVATE:

Int data _;

};

Int main ()

{

Boost: object_pool <A> obj_pool;

A * const Pa = obj_pool.construct ();

Obj_pool.destroy (PA );

Return 0;

}

 

Object_pool inherits to pool. There are two template parameters. The first is the object type, and the second is the allocation subtype. The default value is default_user_allocator_new_delete in the same pool. The constructor parameter only has nnext_size, which indicates that the default value is the same as that of the pool. The most comprehensive instantiation of object_pool is similar to the following: boost: pool <A, boost: default_user_allocator_malloc_free> obj_pool (255 );

Object_pool provides the following functions: malloc/free, and add_ordered_block/malloc/ordered_free In the malloc/free rewrite pool.

Construct/destroy is based on the malloc/free implementation of this class and calls the default constructor and default destructor.

~ In this case, if an object is not destroy during the analysis, you can detect that the destroy operation is performed on the object before the memory is released.

Why is the boost: object_pool designed like this? Calling constructor and destructor is obviously not the starting point of the boost: object_pool class design, because constructor can only execute default constructor (the first published error: Any constructor can be called, see the code file: boost/pool/detail/pool_construct.inc and boost/pool/detail/pool_construct_simple.inc. Thanks to exile). It is similar to none and focuses on cleaning during memory release, the default destructor is enough for this job. You can register the memory cleanup function in the apr_pool memory pool to disable the file descriptor and socket when the memory is released. Boost: object_pool also wants to implement the same function. Therefore, the destroy function is designed to prevent users from missing this call, in addition, detection and recovery are performed during memory pool structure analysis. For this purpose, the time complexity of object_pool is O (n square). Boost: object_pool has paid a heavy price to execute the sorting function at each destoy, time complexity O (n), and finally the time complexity of the analysis structure is O (n). For this purpose, add_ordered_block/ordered_free is added from simple_segregated_storage, the pool adds redundant functions such as ordered_malloc/ordered_free.

Based on the reasons discussed above, boost: object_pool is designed as a chicken rib. Class designers seem to have forgotten the original intention of using the memory pool, and have forgotten the high frequency of applying to release the memory in the memory pool, which is far greater than the analysis structure of the memory pool object. If you still want to use the memory cleanup function similar to this, you can modify it on boost: object_pool without re-writing malloc/free. Rewrite the object_pool destructor and simply release the memory, therefore, do not forget to call destroy before the Destructor object_pool. This is also the default rule followed by placement new, or maintain the previous destructor to sacrifice the performance of the destructor. Placement new is used to call the constructor for the applied memory. The process is (1) applying for memory Buf (2) Calling placement New: New (BUF) construtor () (3) call the Destructor destructor () (4) to release the memory Buf. # Include <New> you can use placement new.

3) singleton_pool

Pool lock version.

 

# Include <boost/pool/singleton_pool.hpp>

Typedef struct student_st

{

Char name [10];

Int age;

} Cstudent;

Typedef struct singleton_pool_tag {} singleton_pool_tag;

Int main ()

{

Typedef boost: singleton_pool <singleton_pool_tag, sizeof (cstudent)> global;

Cstudent * const df = (cstudent *) Global: malloc ();

Global: Free (DF );

Return 0;

}

Singleton_pool is a singleton class and is a lock encapsulation for the pool. It is applicable to multi-threaded environments. All functions are static. There are five template parameters, Tag: tag, meaningless; requestedsize: block length; userallocator: allocate sub-accounts. The default value is default_user_allocator_new_delete; mutex: Lock Mechanism, the default value depends on the system environment. In Linux, It is pthread_mutex, which encapsulates pthread_mutex_t. nextsize: The number of blocks applied for when the memory is insufficient. The default value is 32. The most comprehensive use of singleton_pool is similar to this: typedef boost: singleton_pool <singleton_pool_tag, sizeof (cstudent), default_user_allocator_new_delete, details: pool: default_mutex;

It exposes the same function as the pool.

4) pool_allocator/fast_pool_allocator

STL: Allocator replacement scheme. Both are implemented based on singleton_pool and implement the interface specifications required by STL: allocator. The use of the two is the same. The difference is that the internal implementation of pool_allocator calls ordered_malloc and ordered_free, which can meet the allocation requests for a large number of continuous memory blocks. The internal implementation of fast_pool_allocator calls malloc and free, which is suitable for a single large memory block request, but also for general allocation, but has some performance disadvantages. Therefore, the latter is recommended.

 

# Include <boost/pool/pool_alloc.hpp>

# Include <vector>

Typedef struct student_st

{

Char name [10];

Int age;

} Cstudent;

 

Int main ()

{

STD: vector <cstudent *, boost: fast_pool_allocator <cstudent *> V (8 );

Cstudent * pobj = new cstudent ();

V [1] = pobj;

Boost: singleton_pool <boost: fast_pool_allocator_tag, sizeof (cstudent *) >:: purge_memory ();

Return 0;

}

There are four template parameters for fast_pool_allocator: type, Allocation Sub-, lock type, and number of blocks applied when the memory is insufficient. The default values of the last three parameters are available. The tag used by singleton_pool is boost: fast_pool_allocator_tag.

Conclusion: boost: The pool is small and efficient, and is widely used. Boost: singleton_pool is used in multi-threaded environments. Do not use the ordered_malloc/ordered_free functions of the two. Boost: object_pool is not recommended. It can be used after transformation. The latter is recommended for pool_allocator/fast_pool_allocator.

 

References:

Boost Official Website: http://www.boost.org/

Boost: pool of fixed-length memory pool