Beginning 0 Posted June 19, 2012 · Report post Проще говоря вы используете malloc и т.п. из библиотеки или свои? Я вот FreeRTOS изучаю. Решил досконально изучить исходники (heap_2). Честно говоря это треш какой то. Конечно как кому, но для меня такой стиль писания... Все эти x,px и и т.д. километровые имена. Принцип бритвы Оккамы походу не известен разработчикам. Пока всю эту дибилистику не убрал постоянно терялся на середине алгоритма. Как там, мозг не может запомнить одновременно более 7 переменных величин. Но да ладно не об этом. Вобщем мне не понравилась такая реализация - нету дефрагментации кучи. Взял стандартные библиотечные (KEIL RVDS). Но их тоже оказывается 2 реализации http://www.keil.com/support/man/docs/armli...ib_Cihfiabf.htm Как они толком работают, не поймешь - исходников я не нашёл. Вобщем кто какой реализацией пользуется? Может кто исходниками поделится. Камень Cortex. Quote Ответить с цитированием Share this post Link to post Share on other sites
shmur 0 Posted June 19, 2012 · Report post Пользуемся tlsf, пока всем устраивает. Quote Ответить с цитированием Share this post Link to post Share on other sites
Сергей Борщ 0 Posted June 19, 2012 · Report post Имени zltigo. И на Cortex и на ARM7 Quote Ответить с цитированием Share this post Link to post Share on other sites
Beginning 0 Posted June 19, 2012 · Report post Блин, нашёл тему близнец тыц Можно склеить. Quote Ответить с цитированием Share this post Link to post Share on other sites
IgorKossak 0 Posted June 19, 2012 · Report post Склеил бы, да руки не достают. Тем более, что здесь часто возникают такие вопросы. Пусть остаётся. Quote Ответить с цитированием Share this post Link to post Share on other sites
brag 0 Posted June 19, 2012 · Report post Вот и моя близняшка http://electronix.ru/forum/index.php?showtopic=103157 :) Юзаю простой best-fit аллокатор с ограничением на минимальный свободный блок, правда не в тех задачах, что в той теме описаны. Применяется для хранения сообщений для передачи между потоками... Типа в одном потоке создаем обьект в куче, кидаем указатель на него в FIFO, другие потоки выгребают эти обьекты, выполняют соответствующие методы, возможно передают их дальше другим потокам(в том числе и родителю обратно) и подостижении состояния "final" обьект удаляется(это может произойти в любом потоке). Размер обьектов разный, тип разный. FIFO один. Лучшей реализации,чем использовать кучу пока не придумал. shmur, про tlsf можно по подробнее, мож где-то толковое описание метода есть или алго? где-то краем глаза читал про него в брошюрке, но так и не понял,инфы мало было. Quote Ответить с цитированием Share this post Link to post Share on other sites
Beginning 0 Posted June 20, 2012 · Report post Я тут немного поразмыслил и пришел к выводу что дефрагментация кучи это практически невыполнимая задача без костылей. Вначале я быстро прикинул алгоритм примерно такой. При выделении памяти в начале кучи выделяется собственно память а с конца (например, можно и в начале) выделяется указатели на понтеры, которые собственно и "получат память". Тогда выделение памяти будет выглядеть не так: byte *p = alloc(100); а так byte *p; alloc(&p,100); if(p!=NULL)... Делается это для того, что бы сохранить адрес понтера, и при дефрагментации кучи мы могли бы занести туда новое значение адреса. Но поразмыслив я понял что это накладывает кучу ограничений. Нельзя использовать: byte *pp,*p = alloc(100); pp = p; или p += x; т.е. изменять адрес Придётся использовать функции которые грамотно копировали бы поинтеры. Использовать **p тоже не хочется, усложнение на пустом месте. Есть ли простой способ, без костылей, дефрагментировать кучу? Quote Ответить с цитированием Share this post Link to post Share on other sites
scifi 0 Posted June 20, 2012 · Report post Есть ли простой способ, без костылей, дефрагментировать кучу? Простых способов нет. Дефрагментация неизбежно требует, чтобы программа была готова к тому, что выделенные куски памяти могут переместиться (то есть после перемещения должны обновиться указатели). Кроме того, должен быть некий механизм запирания, чтобы дефрагментатор не стал двигать кусок памяти, с которым ещё не закончена работа (есть активный указатель). Quote Ответить с цитированием Share this post Link to post Share on other sites
Beginning 0 Posted June 20, 2012 · Report post Картина собственно ясна. А теперь вопрос. Стоит ли ради дефрагментации накладывать на программу кучу обязательств - для всех манипуляций с указателями пользоваться только специальными функциями, иначе, если вдруг произошла дефрагментация, будет такой глюк, который практически нереально просчитать. Да же не так, интересует случай из практики, когда применялась дефрагментация и все + и - с этим связанные, и какое такое преимущество вынудило использовать дефрагментацию. Quote Ответить с цитированием Share this post Link to post Share on other sites
jcxz 0 Posted June 20, 2012 · Report post Картина собственно ясна. А теперь вопрос. Стоит ли ради дефрагментации накладывать на программу кучу обязательствПроще наложить одно единственное обязательство - не использовать кучу. Quote Ответить с цитированием Share this post Link to post Share on other sites
brag 0 Posted June 20, 2012 · Report post Забудьте про дефраг. Дефрагментация уместна только, если есть страничная адресация(у кортексов-м3 нету), и то не нужна она там обычно. Если уж других вариантов решить задачу нету - купите проц с внешней шиной и нацепите срам сверху. такие делает STm, на пример. Quote Ответить с цитированием Share this post Link to post Share on other sites
_Pasha 0 Posted June 20, 2012 · Report post Если Вы можете выделить сколь-нибудь детерминированное место под страницу дескрипторов и оперировать не с указателями, а с индексами массива указателей(операция доступа к участку кучи удлиняется) - проблема дефрагментации решается просто. Quote Ответить с цитированием Share this post Link to post Share on other sites
Beginning 0 Posted June 20, 2012 · Report post Я уже писал про **p. Придётся везде лепить. А потом начнётся ***p и т. д. Quote Ответить с цитированием Share this post Link to post Share on other sites
maksimp 0 Posted June 20, 2012 · Report post Практическая реализация дефрагментации без аппаратной поддержки вполне возможна. Это использовалось в Windows старых версий, в том числе на процессоре 8086. См. функцию GlobalAlloc с флагом GMEM_MOVEABLE. А также функции GlobalLock, GlobalUnlock, GlobalFree, GlobalReAlloc. Идея такая. Выделил с помощью GlobalAlloc с флагом GMEM_MOVEABLE кусок памяти - и получил не указатель а дескритор, значение типа HGLOBAL. Нужно попользоваться - закрепил по дескриптору блок с помощью GlobalLock и получил при этом указатель, залез в блок, и отпустил его GlobalUnlock. Ранее полученный указатель стал недействительным. Когда блок отпущен он можен быть сдвинут. Чтобы ещё раз добраться до блока нужно ещё раз вызвать GlobalLock. Quote Ответить с цитированием Share this post Link to post Share on other sites
Beginning 0 Posted June 20, 2012 · Report post Я так понимаю это компромис. Зарезервировал память. Хочеш попользоваться -получай поинт, пользуйся. Не пользуешся разлочивай. Данные при этом не пропадают, но могут переместится. Отсюда два минуса - надо постоянно получать поинты и лочить/разлочить. Пока все не разлочат кучу, её не дефрагментируешь. Как по мне костыль номер один достаточно геморойный. Ну и как эта система, себя оправдала? Quote Ответить с цитированием Share this post Link to post Share on other sites