Перейти к содержанию
    

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

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

RapidJSON:

  Allocator::Malloc -> pvPortMalloc

  Allocator::Free -> vPortFree

  Allocator::Realloc -> pvPortMalloc + vPortFree

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, tonyk_av said:

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 minute ago, xvr said:

С чего бы?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, tonyk_av said:

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, _3m said:

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

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

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

1 hour ago, _3m said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 hours ago, _3m said:

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 hours ago, jcxz said:

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

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

9 hours ago, jcxz said:

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

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

 

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

3 hours ago, dxp said:

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

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

Изменено пользователем tonyk_av

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...