Посоветуйте готовый менеджер памяти Опции

[pernatui]

Может быть существуют в открытом коде менеджеры памяти для ARM. Памяти 64к.

Заранее спасибо!

[Rst7]

Написан на С, ставится на любую систему в течение получаса

Если есть алгоритм, пофиг, на чем писано. Так что это не достоинства, а так, пеар

и отличается высоким быстродействием и эффективностью.

Скажем так, O(1) (а именно такое у него быстродействие) куплено ценой перерасхода ОЗУ. Велик он (перерасход) или нет - зависит от основного кода, как он работает с кучей.

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

Обычные менеджеры требуют довольно длительной блокировки кучи как ресурса - на то время, пока собственно и выполняются действия по занятию/освобождению кусочка. Это часто не позволяет применять прямую работу с кучей в различных реалтаймовых процедурах - вполне возможно, что из-за блокировки кучи как ресурса, будет занято слишком много времени. Стандартный выход - аллоцирование кусочков (обычно фиксированной длинны) для таких задач из заранее заготовленных пулов с соответствующей узкозаточенностью. Пример (хотя и аппаратный) - очереди кусочков в MAC'ах LPC, SAM7, и т.д. Но хотелось бы иметь универсальный алгоритм (и один malloc/free на весь софт).

Я сейчас большей универсальности добиваюсь следующим способом:

1. Размер аллоцируемых кусочков округляется до некоторой логарифмической сетки (этим уменьшается общее количество различных размеров, но и растет перерасход по памяти).
2. Для каждого размера заранее создается связанный список уже заготовленных кусочков (аллоцированных из большой кучи). Начальное количество в каждой цепочке выбирается исходя из тестовых прогонов софта.
3. Аллоцирование кусочка представляет из себя:
а) табличное округление желаемого размера до выбранной сетки (в большую сторону, конечно),
б) получение начального адреса связанного списка, соответствующего округленному размеру,
в) извлечение из односвязного списка первого элемента.
4. Деаллоцирование - простой возврат кусочка в необходимый список (тоже выполняется в начало списка).
5. В отдельном низкоприоритетном процессе запас кусочков в связанных списках поддерживается на каком-то выбранном уровне (задается по результатам тестовых прогонов). Естественно, это происходит возвратом кусочков из списков в большую кучу (если кусочков слишком много) и занятием новых кусочков и добавлением в список (если кусочков слишком мало).
6. В пункте 3 есть аварийный режим (ежели нужный список пуст) - большая блокировка на занятии кусочка из большой кучи. При правильно выбранных коэффициентах в пункте 5 этот пункт никогда не случается

Только пункт 3в (и аналогичный код в возврате кусочка) требует блокировки ресурсов. Причем, т.к. код, выполняемый в состоянии блокировки минимален (не в смысле О(1), а в самом прямом смысле - не более десятка команд процессора), то оказывается вполне возможным производить блокировку не поднятием больших примитивов синхронизации на уровне ОС, а банальным запрещением прерываний.