Книга: Эффективное использование STL
Совет 11. Учитывайте область применения пользовательских распределителей памяти
Совет 11. Учитывайте область применения пользовательских распределителей памяти
Итак, в результате хронометража, профилирования и всевозможных экспериментов вы пришли к выводу, что стандартный распределитель памяти STL (то есть allocator<T>
) работает слишком медленно, напрасно расходует или фрагментирует память, и вы лучше справитесь с этой задачей. А может быть, allocator<T>
обеспечивает безопасность в многопоточной модели, но вы планируете использовать только однопоточную модель и не желаете расходовать ресурсы на синхронизацию, которая вам не нужна. Или вы знаете, что объекты некоторых контейнеров обычно используются вместе, и хотите расположить их рядом друг с другом в специальной куче, чтобы по возможности локализовать ссылки. Или вы хотите выделить блок общей памяти и разместить в нем свои контейнеры, чтобы они могли использоваться другими процессами. Превосходно! В каждом из этих сценариев уместно воспользоваться нестандартным распределителем памяти.
Предположим, у вас имеются специальные функции для управления блоком общей памяти, написанные по образцу malloc
и free
:
void* mallocShared(size_t bytesNeeded);
void freeShared(void *ptr);
Требуется, чтобы память для содержимого контейнеров STL выделялась в общем блоке. Никаких проблем:
template<typename T>
class SharedMemoryAllocator {
public:
…
pointer allocate(size_type numObjects, const void* localityHint=0) {
return static_cast<pointer>(mal1ocShared(numObjects *szeof(T)));
}
void deallocate(pointer ptrToMemory, size_type numObjects) {
freeShared(ptrToMemory);
}
…
};
За информацией о типе pointer, а также о преобразовании типа и умножении при вызове allocate обращайтесь к совету 10. Пример использования SharedMemoryAllocator
:
// Вспомогательное определение типа
typedef
vector<double, SharedMemoryAllocator<double> > SharedDoubleVec;
…
{ // Начало блока
SharedDoubleVec v;// Создать вектор, элементы которого
… // находятся в общей памяти
} // Конец блока
Обратите особое внимание на формулировку комментария рядом с определением v
. Вектор v
использует SharedMemoryAllocator
, потому память для хранения элементов v
будет выделяться из общей памяти, однако сам вектор v
(вместе со всеми переменными класса) почти наверняка не будет находиться в общей памяти. Вектор v
— обычный стековый объект, поэтому он будет находиться в памяти, в которой исполнительная система хранит все обычные стековые объекты. Такая память почти никогда не является общей. Чтобы разместить в общей памяти как содержимое v
, так и сам объект v
, следует поступить примерно так:
void *pVectorMemory = // Выделить блок общей памяти,
mallocShared(sizeof(SharedOoubleVec)); // обьем которой достаточен
// для хранения объекта SharedDoubleVec
SharedDoubleVec *pv = // Использовать "new с явным
new (pVectorMemory) SharedDoubleVec; // размещением" для создания
// объекта SharedDoubleVec:
// см. далее.
… // Использование объекта (через pv)
pv->~SharedDoubleVec(); // Уничтожить объект в общей памяти
freeShared(pVectorMemory); // Освободить исходный блок
// общей памяти
Надеюсь, смысл происходящего достаточно ясен из комментариев. В общих чертах происходит следующее: мы выделяем бок общей памяти и конструируем в ней vector
, использующий общую память для своих внутренних операций. После завершения работы с вектором мы вызываем его деструктор и освобождаем память, занимаемую вектором. Код не так уж сложен, но все-таки он не сводится к простому объявлению локальной переменной, как прежде. Если у вас нет веских причин для того, чтобы в общей памяти находился сам контейнер (а не его элементы), я рекомендую избегать четырехшагового процесса «выделение/конструирование/уничтожение/освобождение».
Несомненно, вы заметили: в приведенном фрагменте проигнорирована возможность того, что mallocShared
может вернуть null
. Разумеется, в окончательной версии следовало бы учесть такую возможность. Кроме того, конструирование vector в общей памяти производится конструкцией «new
с явным размещением», описанной в любом учебнике по C++.
Рассмотрим другой пример использования распределителей памяти. Предположим, у нас имеются две кучи, представленные классами Heap1
и Неар2
. Каждый из этих классов содержит статические функции для выделения и освобождения памяти:
class Heap1 {
public:
…
static void* alloc(size t numBytes, const void* memoryBlockToBeNear);
static void dealloc(void *ptr);
…
};
class Heap2 {…}; // Тот же интерфейс alloc/dealloc
Далее предположим, что вы хотите разместить содержимое контейнеров STL в заданных кучах. Сначала следует написать распределитель, способный использовать классы Heap1
и Heap2
при управлении памятью:
template<typename T, typename Heap>
SpecificHeapAllocator{
public:
…
pointer allocate(size_type numObjects,const void *localityHint=0) {
return static_cast<pointer>(Heap::alloc(numObjects*sizeof(T), localityHint));
}
void deallocate(pointer ptrToMemory, size_type numObjects) {
Heap::dealloc(ptrToMemory);
}
…
};
Затем SpecialHeapAllocator
группирует элементы контейнеров:
vector<int, SpecificHeapAllocator<int, Heap1> > v; // Разместить элементы
set<int, SpecificHeapAllocator<int, Heap1> > s; // v и s в Heapl
list<Widget,
SpecificHeapAllocator<Widget, Heap2> > L; // Разместить элементы
map<int, string, less<int>, // L и m в Heap2
SpecificHeapAllocator<pair<const int, string>, Heap2> > m;
В приведенном примере очень важно, чтобы Heap1
и Неар2
были типами, а не объектами. В STL предусмотрен синтаксис инициализации разных контейнеров STL разными объектами распределителей одного типа, но я не буду его приводить. Дело в том, что если бы Heap1
и Неар2
были бы объектами вместо типов, это привело бы к нарушению ограничения эквивалентности, подробно описанного в совете 10.
Как показывают приведенные примеры, распределители приносят пользу во многих ситуациях. При соблюдении ограничения об эквивалентности однотипных распределителей у вас не будет проблем с применением нестандартных распределителей для управления памятью, группировки, а также использования общей памяти и других специализированных пулов.
- Совет 1. Внимательно подходите к выбору контейнера
- Совет 2. Остерегайтесь иллюзий контейнерно-независимого кода
- Совет 3. Реализуйте быстрое и корректное копирование объектов в контейнерах
- Совет 4. Вызывайте empty вместо сравнения size() с нулем
- Совет 5. Используйте интервальные функции вместо одноэлементных
- Совет 6. Остерегайтесь странностей лексического разбора C++
- Совет 7. При использовании контейнеров указателей, для которых вызывался оператор new, не забудьте вызвать delete для указателей перед уничтожением контейнера
- Совет 8. Никогда не создавайте контейнеры, содержащие auto_ptr
- Совет 9. Тщательно выбирайте операцию удаления
- Совет 10. Помните о правилах и ограничениях распределителей памяти
- Совет 11. Учитывайте область применения пользовательских распределителей памяти
- Совет 12. Разумно оценивайте потоковую безопасность контейнеров STL
- Расширенные возможности указания пользовательских планов
- Пример применения метода «пять почему»
- 3.2.1.2. Начальное выделение памяти: malloc()
- 4.1 Сферы применения технологии Fibre Channel
- Еще о создании пользовательских меню
- Добавление цели в рабочую область для собраний
- Добавление повестки в рабочую область для собраний
- Добавление участников в рабочую область
- Неисправности оперативной памяти
- Как работает модуль оперативной памяти
- Описание типов модулей оперативной памяти
- Извлечение и установка модулей памяти