Как освободить память, полученную с помощью sbrk ()?

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

Есть ли функция, эквивалентная free () для malloc ()?

или мне нужно использовать brk (), чтобы установить конец сегмента данных?


c memory-management unix sbrk
person user238707    schedule 12.01.2010    source источник

Ответы (2)


arrow_upward
27
arrow_downward

Вам нужно снова использовать brk или sbrk для сжатия.

В конце концов, единственный способ изменить объем памяти (кроме mmap, такого как системные вызовы) - это увеличить или уменьшить кучу, поэтому вы перемещаете ее вверх с помощью sbrk или brk и перемещаете вниз с помощью brk или sbrk с помощью отрицательное приращение.

person Arkaitz Jimenez    schedule 12.01.2010
comment
-1, вы можете уменьшить с помощью sbrk, просто передайте ему отрицательное значение. - person avakar; 12.01.2010
comment
Вы правы, я его отредактирую. Никогда не использовал sbrk таким образом, круто. - person Arkaitz Jimenez; 12.01.2010
comment
Единственное, о чем следует беспокоиться, - это то, есть ли у чего-то другого, кроме вашего кода, с именем 'sbrk ()' и что ваша корректировка вниз делает недействительной память, которую все еще использует что-то еще. - person Jonathan Leffler; 13.01.2010
comment
@JonathanLeffler: вот почему распределение памяти централизовано (с помощью malloc в типичном времени выполнения C или времени выполнения C ++). И из-за этой централизации все доступы заблокированы. glibc даже обнаруживает конфликты потоков и на лету создает пулы кучи для конкретных потоков. Но все вызовы sbrk фильтруются этим слоем CRT, поэтому им хорошо управлять. Если вы используете sbrk самостоятельно, вам нужно синхронизировать себя с другими пользователями или знать / убедиться, что других пользователей нет. - person v.oddou; 16.06.2014
comment
@ v.oddou: Поскольку вопрос касается специального распределителя (не заявленного как замена malloc() и др.), ваши комментарии не имеют прямого отношения к проблеме. Очевидно, что в этом контексте распределение памяти не централизуется библиотекой времени выполнения. - person Jonathan Leffler; 16.06.2014
comment
@JonathanLeffler: Ну, я вообще не сказал, что ваш комментарий был не на крючке. Я просто добавил к нему нюанс (который действительно идет в вашу сторону). Теперь о вопросе OP, он ничего не говорит, это правда. Поэтому я предположил противоположное тому, что вы предполагали, что он знает, с чем он борется! - person v.oddou; 16.06.2014

arrow_upward
1
arrow_downward

Не используйте brk и sbrk. Практически невозможно узнать, какие библиотечные функции могут вызывать malloc и могут измениться со временем, поэтому даже если ваша программа работает сейчас, она может сломаться, когда кто-то обновит libc. Они были исключены из POSIX по очень уважительной причине.

person R.. GitHub STOP HELPING ICE    schedule 26.07.2010
comment
Кто сказал, что его распределитель - это не единственное, что используется для выделения из кучи в его процессе / приложении? это могло быть совершенно законно. Пожалуйста, воздержитесь от простых заявлений о том, что нужно и что нельзя, если бы вы знали лучше для всех в каждом конкретном случае. Ваше объяснение идеально, но в нем также говорится, почему вы ошибаетесь (если он не использует malloc). - person v.oddou; 16.06.2014
comment
@ v.oddou: Откуда он знает, что printf не использует malloc? (Во многих реальных системах это так!) Или любую другую стандартную библиотечную функцию? В этом весь смысл моего ответа. Я не использую malloc - это недостаточное условие для безопасного использования brk или sbrk. На самом деле не существует достаточных условий для их безопасности. - person R.. GitHub STOP HELPING ICE; 16.06.2014
comment
очень хороший момент. это послужит неким посредником для пользователей sbrk. А что, если вообще не использовать stdlib? или лучше, настраиваемый stdlib, который специально не использует malloc. ИЛИ ДАЖЕ, обработанная среда выполнения, которая взламывает функцию malloc, выполняя перенаправление таблицы виртуальных символов в пользовательскую функцию? - person v.oddou; 16.06.2014
comment
@ v.oddou: Все это действительно выходит за рамки использования языка C и входит в объем (пере) написания части или всей реализации, и в этом случае может быть способ безопасно использовать sbrk. На самом деле, я бы предположил, что единственная причина, по которой sbrk по-прежнему предлагается во многих современных системах, - это инструмент для написания пользовательских версий malloc, и если это поддерживается вашей системой, это, вероятно, единственный вариант использования, в котором sbrk является безопасным (поскольку вы не может сражаться с malloc, если вы предоставляете malloc). - person R.. GitHub STOP HELPING ICE; 16.06.2014
comment
очень хорошо, так что кажется, что в конце концов мы полностью согласны. Кто сказал, что OP не пишет свой распределитель, а предоставляет его в самом malloc? что, как вы говорите, законно. Итак, вы видите, что не использовать brk в исходном заявлении - это слишком сильно. - person v.oddou; 16.06.2014
comment
@ v.oddou: Из вопроса неясно, означает ли пользовательский распределитель замену реализации malloc или что-то, что используется вместо malloc, но с другим именем и другим API. В первом случае, наверное, нормально; в последнем - определенно нет. - person R.. GitHub STOP HELPING ICE; 16.06.2014