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