Эффективное использование STL — страница 17 из 63

) работает слишком медленно, напрасно расходует или фрагментирует память, и вы лучше справитесь с этой задачей. А может быть, allocator обеспечивает безопасность в многопоточной модели, но вы планируете использовать только однопоточную модель и не желаете расходовать ресурсы на синхронизацию, которая вам не нужна. Или вы знаете, что объекты некоторых контейнеров обычно используются вместе, и хотите расположить их рядом друг с другом в специальной куче, чтобы по возможности локализовать ссылки. Или вы хотите выделить блок общей памяти и разместить в нем свои контейнеры, чтобы они могли использоваться другими процессами. Превосходно! В каждом из этих сценариев уместно воспользоваться нестандартным распределителем памяти.

Предположим, у вас имеются специальные функции для управления блоком общей памяти, написанные по образцу malloc и free:

void* mallocShared(size_t bytesNeeded);
void freeShared(void *ptr);

Требуется, чтобы память для содержимого контейнеров STL выделялась в общем блоке. Никаких проблем:

template
class SharedMemoryAllocator{
public:
...
	pointer allocate(size_type numObjects, const void* localityHint=0)
	{
	   return static_cast(mal1ocShared(numObjects *szeof(T)));
	}
	void deallocate(pointer ptrToMemory, size_type numObjects) {
	   freeShared(ptrToMemory);
	}
}:

За информацией о типе pointer, а также о преобразовании типа и умножении при вызове allocate обращайтесь к совету 10. Пример использования SharedMemoryAllocator:

// Вспомогательное определение типа

typedef
vectorSharedMemoryAllocator> 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 с явным размещением», описанной в любом учебнике по С++.

Рассмотрим другой пример использования распределителей памяти. Предположим, у нас имеются две кучи, представленные классами 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 и Неар2 при управлении памятью:

template
SpecificHeapAllocator{ 
public:
...
pointer allocate(size_type numObjects,const void *localityHint=0) {
	return static_cast (Heap::alloc(numObjects*sizeof(T), localityHint)):
}
void deallocate(pointer ptrToMemory,size_type numObjects) {
	Heap::dealloc(ptrToMemory);
}
...
};

Затем SpecialHeapAllocator группирует элементы контейнеров:

vector> v; // Разместить элементы
set> s: // v и s в Heapl

list
SpecificHeapAllocator> L; // Разместить элементы
map,// L и m в Heap2
SpecificHeapAllocator. Heap2>> m;

В приведенном примере очень важно, чтобы Heap1 и Неар2 были типами, а не объектами. В STL предусмотрен синтаксис инициализации разных контейнеров STL разными объектами распределителей одного типа, но я не буду его приводить. Дело в том, что если бы Heap1 и Неар2 были бы объектами вместо типов, это привело бы к нарушению ограничения эквивалентности, подробно описанного в совете 10.

Как показывают приведенные примеры, распределители приносят пользу во многих ситуациях. При соблюдении ограничения об эквивалентности однотипных распределителей у вас не будет проблем с применением нестандартных распределителей для управления памятью, группировки, а также использования общей памяти и других специализированных пулов.

Совет 12. Разумно оценивайте потоковую безопасность контейнеров STL

Мир стандартного С++ выглядит старомодным и не подверженным веяниям времени. В этом мире все исполняемые файлы компонуются статически, в нем нет ни файлов, отображаемых на память, ни общей памяти. В нем нет графических оконных систем, сетей и баз данных, нет и других процессов. Вероятно, не стоит удивляться тому, что в Стандарте не сказано ни слова о программных потоках. О потоковой безопасности в STL можно уверенно сказать только одно: что она полностью зависит от реализации.

Конечно, многопоточные программы распространены весьма широко, поэтому большинство разработчиков STL стремится к тому, чтобы их реализации хорошо работали в многопоточных условиях. Но даже если они хорошо справятся со своей задачей, основное бремя остается на ваших плечах. Возможности разработчиков STL в этой области ограничены, и вы должны хорошо понимать, где проходят эти границы.

«Золотой стандарт» поддержки многопоточности в контейнерах STL (которым руководствуется большинство разработчиков) был определен компанией SGI и опубликован на ее web-сайте, посвященном STL [21]. Фактически в нем сказано, что в лучшем случае можно надеяться на следующее:

•безопасность параллельного чтения. Несколько потоков могут одновременно читать содержимое контейнера, и это не помешает его правильной работе. Естественно, запись в контейнер при этом не допускается;

•безопасность записи в разные контейнеры. Несколько потоков могут одновременно производить запись в разные контейнеры.

Обращаю ваше внимание: это то, на что вы можете надеяться, но не рассчитывать.