[Axel 1]

Как правильно приделать одно к другому (в смысле аллокатора памяти)?

 

[xvr 12]

А какие проблемы с аллокатором?

У FreeRTOS из 5 штук - выбирайте любой

RapidJSON:

  Allocator::Malloc -> pvPortMalloc

  Allocator::Free -> vPortFree

  Allocator::Realloc -> pvPortMalloc + vPortFree

 

[tonyk_av 80]

33 minutes ago, xvr said:

Allocator::Realloc -> pvPortMalloc + vPortFree

А память не утечёт?

[xvr 12]

1 hour ago, tonyk_av said:

А память не утечёт?

С чего бы? Выделяете новую память требуемого размера, копируете в неё старое содержимое, старую память освобождаете.

 

[tonyk_av 80]

1 minute ago, xvr said:

С чего бы?

Но ведь на месте освобождённой будет "дырка". Где гарантия того, что при следующем обращении будет запрошена память размером с "дырку"?

[xvr 12]

Just now, tonyk_av said:

Но ведь на месте освобождённой будет "дырка". Где гарантия того, что при следующем обращении будет запрошена память размером с "дырку"?

Этим занимается менеджер памяти (точнее heap_2, heap_4 или heap_5). Если будет запрос подходящего размера, то он займёт 'дырку'.

 

[jcxz 361]

В 21.05.2023 в 09:54, Axel сказал:

Как правильно приделать одно к другому (в смысле аллокатора памяти)?

Правильно - не использовать аллокатор вообще.

[_3m 19]

3 часа назад, xvr сказал:

Этим занимается менеджер памяти (точнее heap_2, heap_4 или heap_5). Если будет запрос подходящего размера, то он займёт 'дырку'.

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

[tonyk_av 80]

1 hour ago, _3m said:

А потом снаружи поступят запросы неподходящего размера, менеджер дырки занять не сможет, исчерпает память и будет очередной "фобос-в-грунт".

Вот-вот, я на это и намекал.

Тем не менее, ИМХО, выход есть. Если известны размеры полей, то можно написать свой распределитель памяти, который будет учитывать специфику обрабатываемых данных и будет распределять память без "дырок".

1 hour ago, _3m said:

Проблема в непредсказуемости.

Она решается путём статического распределения памяти для определённого количества элементов. Да, будет резервироваться некоторый избыток памяти, который останется неиспользованным, но по другому нельзя, иначе " будет очередной "фобос-в-грунт".

Кстати, NASA разрешает использовать в программах malloc-free и new-delete до входа в основной цикл программы управления. Внутри него запрещено динамическое выделение памяти.

[xvr 12]

5 hours ago, _3m said:

А потом снаружи поступят запросы неподходящего размера, менеджер дырки занять не сможет,

Это общая проблема любых алокаторов памяти. К связке FreeRTOS и RapidJSON она отношения не имеет.

 

[jcxz 361]

16 часов назад, tonyk_av сказал:

Она решается путём статического распределения памяти для определённого количества элементов. Да, будет резервироваться некоторый избыток памяти, который останется неиспользованным, но по другому нельзя

А почему "избыток" и откуда распространённое заблуждение, что статическое распределение требует больше памяти? Статическое распределение как правило требует меньше памяти. Но да - оно требует бОльшего мастерства от кодонаписателя.

[dxp 213]

Фрагментация кучи на физической памяти — неустранимая проблема. Успешно она преодолевается при использовании  виртуальной памяти — сиречь через MMU.

[tonyk_av 80]

9 hours ago, jcxz said:

Сатическое распределение как правило требует меньше памяти.

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

9 hours ago, jcxz said:

Но да - оно требует бОльшего мастерства от кодонаписателя.

Как раз наоборот, меньшего.

 

У меня в ПЛК именно так сделана поддержка Модбас и I2C. Никто не может предсказать, сколько пользователь активирует функциональных блоков "Запрос по Модбас", поэтому выделяется какое-то разумное количество памяти для запросов.

3 hours ago, dxp said:

Фрагментация кучи на физической памяти — неустранимая проблема. Успешно она преодолевается при использовании  виртуальной памяти — сиречь через MMU.

По-честному- это не преодоление. Никто не знает, в какой момент потребуется переконфигурация MMU для уборки "дырок". Может, в этот момент будет работать алгоритм аварийной защиты, а мы остановим процессор для обслуживания памяти. По этой причине в контроллерах, управляющих ответственным оборудованием, запрещено использование языков программирования, которым необходимо динамическое управление памятью.

Edited May 23, 2023 by tonyk_av

[Arlleex 334]

1 час назад, tonyk_av сказал:

Нет, бОльшего. Ведь приходится резервировать память, априори не зная реальную потребность...

Про оверлеи слышали? Функционал изделия довольно часто можно разбить на независимые части, которым не обязательно работать всегда одновременно...

[tonyk_av 80]

11 minutes ago, Arlleex said:

Про оверлеи слышали?

С ПЛК работали? Там такая штука не канает.