Кто какую реализацию использует для распределения памяти на cortex? Опции

[Beginning]

Проще говоря вы используете malloc и т.п. из библиотеки или свои? Я вот FreeRTOS изучаю. Решил досконально изучить исходники (heap_2). Честно говоря это треш какой то. Конечно как кому, но для меня такой стиль писания... Все эти x,px и и т.д. километровые имена. Принцип бритвы Оккамы походу не известен разработчикам. Пока всю эту дибилистику не убрал постоянно терялся на середине алгоритма. Как там, мозг не может запомнить одновременно более 7 переменных величин. Но да ладно не об этом. Вобщем мне не понравилась такая реализация - нету дефрагментации кучи. Взял стандартные библиотечные (KEIL RVDS). Но их тоже оказывается 2 реализации http://www.keil.com/support/man/docs/armli...ib_Cihfiabf.htm
Как они толком работают, не поймешь - исходников я не нашёл.
Вобщем кто какой реализацией пользуется? Может кто исходниками поделится. Камень Cortex.

[brag]

Я уже писал про **p. Придётся везде лепить. А потом начнётся ***p и т. д.

к тому же перегруженные, а возможно и volatile - защищать это все дело надо будет в многопоточном приложении...

GlobalUnlock. Ранее полученный указатель стал недействительным. Когда блок отпущен он можен быть сдвинут. Чтобы ещё раз добраться до блока нужно ещё раз вызвать GlobalLock.

Ну да, было дело Вероятность схватить Deadlock резко возрастает и тормоза в том числе. в 21 веке никто так не делает...

Ну и как эта система, себя оправдала?

а как себя оправдала Windows 3.1 16-bit? :D

Если после генерации сообщения поток блокируется....
Если после генерации сообщения поток блокируется...

Это убивает прелесть многопоточности и "естетственности" программы. весь смысл прогонки обьекта по нескольким потокам - избавится от гемора, избавится от локов, упростить программу. попишу немного букавок в качестве примера.
Есть GSM модуль, протокол CMUX - 2 канала GSM & GPRS. Каждий канал обрабатывается только своим потоком.
Допустим GSM опрашівает состояние модуля, что-то там куда-то логирует и принимает и отправляет SMS. В SMS приходят команды. Допустим, пришла команда загрузить какой-то файл s ftp://ftp.murzilka.ru/01.zip. GSM формирует обьект-сообщение и кидает в очередь. GPRS по мере готовности выгребает сообщение и выполняет. в конце кидает его обратно в очередь(вернее само сообщение себя кидает и меняет состояние, эт уже детали реализации иерархии классов) и занимается дальше своими делами.
GSM по мере готовности выгребает сообщение и выполняет(отправляет SMS с отчетом о загрузке файла).
Конечно, можно было лочить каналы(довольно медленные) и делать все действия на месте(не отходя от кассы), но в сложном приложении(в том,которое есть на самом деле, все гораздо сложнее) запаритесь потом и система будет простаивать.на пример, чтобы прочитать следующую смс(вообще не относящуюся к командам связанным с GPRS) или снять следующее состояние модема надо будет ждать, пока тормознутый GPRS что-то там обработает минут так 10-15:))

Если есть куча, то система работоспособна. Разумеется память используется по очереди.

Ну чтобы по очереди использовалось нужно это синхронизировать,а это не всегда уследишь на сложном проекте. если не синхронизировать - как уже було сказано в моей теме про кучу: если каждому потоку вероятно понадобится по 100 байт стека, то при реализации на куче и куча должна быть 200 байт(+ оверхед на заголовки):

Раз у вас не хватает памяти чтобы распределить её в виде static или на стеке для всех потоков, значит возможна ситуация (и даже с большей вероятностью), когда много потоков запросит больше памяти чем есть. С наличием служебных полей управления блоками в heap и фрагментации это даже более вероятно, чем при static размещении.
Что ваша система должна делать при этом? Выдать отказ потоку (но значит алгоритм всех потоков должен рассчитывать, что может быть получен отказ в памяти)? Или приостановить выполнение потока (но может случиться dead-lock)?

[maksimp]

GlobalUnlock. Ранее полученный указатель стал недействительным. Когда блок отпущен он можен быть сдвинут. Чтобы ещё раз добраться до блока нужно ещё раз вызвать GlobalLock.

Ну да, было дело Вероятность схватить Deadlock резко возрастает и тормоза в том числе.

Deadlock - вряд ли. Так как GlobalLock не предоставляет блок в исключительное пользование одному процессу. Много процессов могут вызвать GlobalLock для одного и того же блока одновременно - и получат успешно в ответ один и тот же указатель. GlobalLock блокирует только перемещение блока при дефрагментации.

а как себя оправдала Windows 3.1 16-bit? :D

Вещь! была для своего времени. Впрочем эта система выделения памяти была действительно актуальна только до Windows 3.0 включительно, на процессоре 8086. Windows 3.1 на таком процессоре уже не могла работать.