Win32 может “переместить” память типа "куча"?
У меня есть приложение C++.NET/собственного компонента. В настоящее время код C++ выделяет память на "куче" по умолчанию, которая сохраняется для срока действия приложения. В основном функции/команды выполняются в C++, который приводит к выделению/модификации текущей постоянной памяти. Я исследую подход для отмены одной из этих функций/команд середина выполнения. У нас есть сотни этих команд, и многие - очень сложный код (прежней версии).
Метод решения "в лоб", которого я стараюсь избегать, изменяет каждую команду/функцию, чтобы проверить на отмену и сделать всю соответствующую очистку (освобождающий память "кучи"). Я исследую многопоточный подход, в котором дополнительный поток получает запрос отмены и завершает поток выполнения команды. Я хотел бы, чтобы вся динамическая память была выделена на "частной "куче"" использование HeapCreate() (Win32). Таким образом, частная "куча" могла быть уничтожена потоком, обрабатывающим запрос отмены. Однако, если команда работает к завершению, мне нужна динамическая память для сохранения. В этом случае я хотел бы сделать логический эквивалент "перемещения" частной памяти "кучи" к "куче" значения по умолчанию/процесса, не подвергаясь стоимости фактической копии. Это любым возможным путем? Это даже имеет смысл?
С другой стороны, я распознаю, что у меня могла просто быть новая частная "куча" для каждого выполнения команды/функции (каждый будет новым потоком). Частная "куча" могла быть уничтожена, если бы команда отменяется, или она выжила бы, если команда завершается. Есть ли какая-либо проблема с количеством "кучи", растущей неограниченно долго? Я знаю, что существуют немного служебные связаны с каждой "кучей". С какими ограничениями я мог бы столкнуться?
Я работаю на Windows 7, 64-разрядном с 8 ГБ RAM (считайте это целевой платформой). Приложение, с которым я работаю, является приблизительно 1 миллионом SLOC (половина C++, половина C#). Я ищу любой опыт/предложения с частным управлением "кучей" или просто альтернативы моему решению.
4 ответа
Куча - это своего рода большая часть памяти. Это менеджер памяти уровня пользователя. Куча создается вызовыми звонками системы более низкого уровня (E.G., SBRK в Linux и VirtualAlloc в Windows). В куче, тогда вы можете запросить или вернуть небольшой кусок памяти Malloc / New / Free / Delete. По умолчанию процесс имеет одну кучу (в отличие от стека, все потоки имеют кучу). Но у вас может быть много кучей.
Можно ли объединить две кучи без копирования? Куча - это, по сути, является структурой данных, которая поддерживает список используемых и освобожденных кусочков памяти. Таким образом, куча должна иметь свой вид бухгалтерских данных, называемых метаданными. Конечно, эта метадана имеет кучу. Afaik, No Heap Manager не поддерживает операцию слияния двух кучей. Я рассмотрел весь исходный код реализации Malloc в Linux Glibc ( Реализация Дага Ли ), но нет такого операции. Функции Windows Heap * также реализованы аналогичным образом. Итак, в настоящее время невозможно переместить или объединить две отдельные кучи.
Можно ли иметь много кучей? Я не думаю, что должна быть большая проблема, чтобы иметь много кучей. Как я уже говорил, куча - это просто структура данных, которая продолжает использовать / освобождать куски памяти. Итак, должно быть некоторое количество накладных расходов. Но, это не так сурово. Когда вы смотрите на один из реализации Malloc , есть
malloc_state, что является основной структурой данных для каждой кучи. Например, вы можете создать другую кучуCreate_Mspace(в Windows, он являетсяHeapcreate), то вы получите новое состояние Malloc. Это не так большой. Итак, если этот студент (некоторые куча наверху против реализации легкость) в порядке, то вы можете продолжать.
Если бы я был тобой, я попробую, как вы описываете. Это имеет смысл для меня. Наличие много кучи объектов не сделает большой накладной.
Кроме того, следует отметить, что технически движущиеся регионы памяти невозможно. Указатели, которые указали на перемещенной области памяти, приведут к болтающим указателям.
P.S. Ваша проблема кажется транзакциями, особенно программной транзакционной памятью. Типичная реализация буферов STM в ожидании памяти пишет, а затем совершает реальную системную память, она не имела конфликта.
от функций MSDN PAGE PAGE : «Память, выделенная HeaPalloc, не является подвижным. Адрес, возвращаемый Heapalloc, до тех пор, пока блок памяти не будет освобожден или перераспределен; блок памяти не должен быть заблокирован».
Можете ли вы повторно связать наследующую наследующую MALLOC () Реализация? Если это так, вы должны уметь управлять без изменения остальной части кода. Ваша пользовательская библиотека MALLOC может отслеживать выделенные блоки по ветру и иметь функцию «FreealLythredid (), которую вы вызываете после убийства потока функции устаревшего. Вы могли бы использовать частные кучи в библиотеке.
Альтернатива частным кучам может быть Собственное распределение от memorated файлов. См. « Создание именованной общей памяти .« Вы создаете общую память при инициализации библиотеки ALLOC для устаревшей нити. На успех сопоставьте его в основной поток, чтобы ваш C # доступа к нему; о прекращении, закройте его и его выпущено в систему.
Возможно, вам может быть лучше с отдельными процессами вместо отдельных потоков:
- используйте файлы смягчания памяти (т.е. не файл вообще - просто перекрестная общая совмещенная память)
- Убийство процесса «очистить», чем убийство Нить
- I Думаю Подумайте Вы можете иметь общую память «выжить» убийство без хода - вы отобразите / unmak вместо перемещения
, хотя вам может потребоваться выполнить некоторое управление памятью Отказ
Во всяком случае, стоит поискать. Я смотрел на использование межпроцессной памяти для нескольких других вещей, и у него были некоторые необычные свойства (могут вспомнить все это ясно, это было некоторое время назад), и вы сможете воспользоваться этим.
Просто идея!