BDE 4.14.0 Production release
|
Functions | |
void * | operator new (bsl::size_t size, BloombergLP::bdlma::ConcurrentFixedPool &pool) |
void | operator delete (void *address, BloombergLP::bdlma::ConcurrentFixedPool &pool) |
Provide thread-safe pool of limited # of blocks of uniform size.
This component implements a fully thread-safe memory pool that allocates and manages a limited number (specified at construction) of memory blocks of some uniform size (also specified at construction). A bdlma::ConcurrentFixedPool
constructed to manage up to N
blocks also provides an association between the address of each block and an index in the range [ 0 .. N - 1 ]
.
Other than this mapping between block and index, and the associated limit on the maximum number of blocks that may be simultaneously allocated, this component's semantics are identical to bdlma::ConcurrentPool
. In particular, this component overloads global operator new
in the same manner, and the behaviors of release
and reserveCapacity
are equivalent to the corresponding methods in bdlma::ConcurrentPool
.
Like bdlma::ConcurrentPool
, this component is intended to be used to implement out-of-place container classes that hold elements of uniform size.
This section illustrates intended use of this component.
bdlma::ConcurrentFixedPool
is intended to implement out-of-place container classes that hold up to a fixed number of elements, all of uniform size. Suppose we wish to implement a simple thread pool. We want the equivalent of a bsl::deque<bsl::function<void(void)> >
. However, to minimize the time spent performing operations on this deque - which must be carried out under a lock - we instead store just pointers in the deque, and manage memory efficiently using bdlma::ConcurrentFixedPool
. bdlma::ConcurrentFixedPool
is fully thread-safe and does not require any additional synchronization.
The example below is just for the container portion of our simple thread pool. The implementation of the worker thread, and the requisite synchronization, are omitted for clarity.
Note that in the destructor, there is no need to deallocate the individual job objects - the destructor of bdlma::ConcurrentFixedPool
will release any remaining allocated memory. However, it is necessary to invoke the destructors of all these objects, as the destructor of bdlma::ConcurrentFixedPool
will not do so.
|
inline |
Use the specified pool
to deallocate the memory at the specified address
. The behavior is undefined unless address
was allocated using pool
and has not already been deallocated. This operator is supplied solely to allow the compiler to arrange for it to be called in case of an exception. Client code should not call it; use bdlma::ConcurrentFixedPool::deleteObject()
instead.
|
inline |
Allocate memory of the specified size
bytes from the specified pool
, and return the address of the allocated memory. The behavior is undefined unless size
is the same as the objectSize
with which pool
was constructed. Note that an object may allocate additional memory internally within its constructor, requiring the allocator to be passed in as a constructor argument:
Note also that the analogous version of operator delete
should not be called directly. Instead, this component provides a template member function bdlma::ConcurrentFixedPool::deleteObject
parameterized by TYPE
that performs the equivalent of the following: