вопросы по пулу памяти

В сценарии, где вы всегда выделяете блоки фиксированного размера, у вас либо достаточно места для еще одного блока, либо его нет. Если у вас есть, блок помещается в доступное пространство, потому что все свободные или используемые места имеют одинаковый размер. Фрагментация не проблема.

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

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

На изображении (отсюда) показана ситуация, в которой A, B и C выделяет куски памяти, куски переменного размера.

В какой-то момент B освобождает все свои куски памяти, и внезапно возникает фрагментация. Например, если бы C нужно было выделить большой кусок памяти, который по-прежнему помещался бы в доступную память, это было бы невозможно, потому что доступная память разделена на два блока.

Теперь, если вы подумаете о случае, когда каждый блок памяти был бы одинакового размера, такой ситуации явно бы не возникло.

У пулов памяти, конечно, есть свои недостатки, как вы сами указываете. Так что не стоит думать, что пул памяти — это палочка-выручалочка. Это имеет свою стоимость, и ее имеет смысл платить при определенных обстоятельствах (например, встроенная система с ограниченным объемом памяти, ограничениями в реальном времени и т. д.).

Что касается того, какой пул памяти хорош в С++, я бы сказал, что это зависит. Я использовал один в VxWorks, который был предоставлен ОС; в некотором смысле хороший пул памяти эффективен, когда он тесно интегрирован с ОС. На самом деле, я думаю, каждая RTOS предлагает реализацию пулов памяти.

Если вам нужна общая реализация пула памяти, посмотрите это.

РЕДАКТИРОВАТЬ:

Из вашего последнего комментария мне кажется, что, возможно, вы думаете о пулах памяти как о «решении проблемы фрагментации». К сожалению, это не тот случай. Если хотите, фрагментация есть проявление энтропии на уровне памяти, т. е. она неизбежна. С другой стороны, пулы памяти — это способ управления памятью таким образом, чтобы эффективно уменьшить влияние фрагментации (как я уже сказал и как упоминалось в Википедии, в основном на конкретных системах, таких как системы реального времени). Это обходится дорого, поскольку пул памяти может быть менее эффективным, чем «обычный» метод распределения памяти, поскольку у вас есть минимальный размер блока. Другими словами, энтропия снова появляется под маской.

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

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

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

Для переменного размера это может вызвать проблемы, поскольку может не оказаться свободного фрагмента, достаточно большого для определенного запрошенного размера.

С другой стороны, для пулов фиксированного размера это не проблема, поскольку можно запрашивать только части предварительно определенного размера. Если есть свободное место, оно гарантированно будет достаточно большим для (кратного) одной порции.

Если вы используете систему жесткого реального времени, вам может понадобиться заранее знать, что вы можете выделить память в течение максимально допустимого времени. Это можно «решить» с помощью пулов памяти фиксированного размера.

Однажды я работал над военной системой, где нам нужно было рассчитать максимально возможное количество блоков памяти каждого размера, которое система могла бы когда-либо использовать. Затем эти числа были добавлены к общей сумме, и система была настроена на этот объем памяти.

Безумно дорогой, но работал на оборону.

Когда у вас есть несколько пулов фиксированного размера, вы можете получить вторичную фрагментацию, когда в вашем пуле нет блоков, даже если в каком-то другом пуле достаточно места. Как вы это разделяете?

С пулом памяти операции могут работать следующим образом:

1. Сохраните глобальную переменную, представляющую собой список доступных объектов (изначально пустых).
2. Чтобы получить новый объект, попробуйте вернуть его из глобального списка доступных. Если его нет, вызовите оператор new, чтобы выделить новый объект в куче. Выделение происходит очень быстро, что важно для некоторых приложений, которые в настоящее время могут тратить много процессорного времени на выделение памяти.
3. Чтобы освободить объект, просто добавьте его в глобальный список доступных объектов. Вы можете установить ограничение на количество элементов, разрешенных в глобальном списке; если предел достигнут, то объект будет освобожден, а не возвращен в список. Шапка предотвращает появление массовой утечки памяти.

Обратите внимание, что это всегда делается для одного типа данных одного и того же размера; это не работает для больших, и тогда вам, вероятно, нужно использовать кучу, как обычно.

Это очень легко реализовать; мы используем эту стратегию в нашем приложении. Это вызывает кучу выделений памяти в начале программы, но больше не происходит освобождения/выделения памяти, что влечет за собой значительные накладные расходы.