Является ли использование malloc() и free() действительно плохой идеей для Arduino?

Обычно при написании скетчей Arduino вы избегаете динамического выделения памяти (будь то с malloc или new для экземпляров C++), люди предпочитают использовать global -или статические-переменные или локальные (стековые) переменные.

Использование динамического размещения может привести к нескольким проблемам:

• утечки памяти (если вы потеряете указатель на память, которую вы ранее выделили, или, что более вероятно, если вы забудете освободить выделенную память, когда она вам больше не нужна)
• фрагментация кучи (после нескольких вызовов malloc/free), когда куча становится больше, чем фактический объем выделенной в данный момент памяти

В большинстве ситуаций, с которыми я сталкивался, динамическое размещение либо не было необходимо, либо его можно было избежать с помощью макросов, как в следующем примере кода:

MySketch.ino

#define BUFFER_SIZE 32
#include "Dummy.h"

Dummy.h

class Dummy
{
    byte buffer[BUFFER_SIZE];
    ...
};

Без #define BUFFER_SIZE, если бы мы хотели, чтобы класс Dummy имел нефиксированный размер buffer, нам пришлось бы использовать динамическое выделение следующим образом:

class Dummy
{
    const byte* buffer;

    public:
    Dummy(int size):buffer(new byte[size])
    {
    }

    ~Dummy()
    {
        delete [] bufer;
    }
};

В этом случае у нас больше вариантов, чем в первом примере (например, использовать разные объекты Dummy с разным размером buffer для каждого), но может возникнуть фрагментация кучи вопросы.

Обратите внимание на использование деструктора, чтобы гарантировать, что динамически выделенная память для buffer будет освобождена при удалении экземпляра Dummy.

Использование динамического размещения (через malloc/free или new/delete) по своей сути не является плохим, поскольку такой. На самом деле, для чего-то вроде обработки строк (например, с помощью объекта String) это часто весьма полезно. Это связано с тем, что во многих скетчах используется несколько небольших фрагментов строк, которые в конечном итоге объединяются в один более крупный. Использование динамического распределения позволяет использовать ровно столько памяти, сколько вам нужно для каждого из них. Напротив, использование статического буфера фиксированного размера для каждого из них может привести к трате большого количества места (что приведет к гораздо более быстрому исчерпанию памяти), хотя это полностью зависит от контекста.

Учитывая все вышесказанное, очень важно обеспечить предсказуемость использования памяти. Разрешение скетчу использовать произвольное количество памяти в зависимости от обстоятельств времени выполнения (например, ввода) может легко вызвать проблему рано или поздно. В некоторых случаях это может быть совершенно безопасно, например, если вы знаете, что количество использований никогда не увеличится. Однако скетчи могут меняться в процессе программирования. Предположение, сделанное ранее, может быть забыто, когда что-то изменится позже, что приведет к непредвиденной проблеме.

Для надежности обычно лучше работать с буферами фиксированного размера, где это возможно, и проектировать скетч так, чтобы он явно работал с этими ограничениями с самого начала. Это означает, что любые будущие изменения скетча или любые непредвиденные обстоятельства во время выполнения не должны вызывать проблем с памятью.

Мое общее правило для встраиваемых систем: использовать только большие буферы malloc() и только один раз, в начале программы, например, в setup(). Проблема возникает, когда вы выделяете и освобождаете память. При длительном сеансе память становится фрагментированной, и в конечном итоге происходит сбой выделения из-за отсутствия достаточно большой свободной области, даже если общей свободной памяти более чем достаточно для запроса.

(историческая перспектива, пропустите, если не интересно): в зависимости от реализации загрузчика единственным преимуществом выделения во время выполнения по сравнению с выделением во время компиляции (инициализированные глобальные переменные) является размер шестнадцатеричного файла. Когда встроенные системы были построены с готовыми компьютерами, имеющими всю энергозависимую память, программа часто загружалась во встроенную систему из сети или с измерительного компьютера, и время загрузки иногда было проблемой. Исключение из изображения буферов, заполненных нулями, может значительно сократить время.)

Если мне нужно динамическое выделение памяти во встроенной системе, я обычно malloc() или, что предпочтительнее, статически выделяю большой пул и делю его на буферы фиксированного размера (или по одному пулу на каждый из маленькие и большие буферы соответственно) и делаю свое собственное выделение/отмену выделения из этого пула. Затем каждый запрос на любой объем памяти вплоть до фиксированного размера буфера обрабатывается одним из этих буферов. Вызывающей функции не нужно знать, больше ли она, чем запрошено, и, избегая разделения и повторного объединения блоков, мы устраняем фрагментацию. Конечно, утечки памяти все еще могут происходить, если в программе есть ошибки выделения/освобождения памяти.

Обновление от 16.02.23:

Мне любопытно, почему реализация malloc в библиотеке Arduino не реализовать некоторое объединение свободных блоков, как в полной ОС.

Об этом интересно подумать, но давайте сначала проясним, что в C/C++ функции malloc() и free() реализованы как библиотечные функции на уровне приложения, а не на уровне ОС, даже в основных операционных системах. И они основаны на фрагментации кучи, как это делают функции malloc() в Arduino.

Встроенные системы относительно новы, по крайней мере, как влиятельная сила при разработке операционных систем, языков и библиотек. Другими словами, программы, которые должны были работать "вечно", без сбоев (кроме, возможно, самой ОС) были выбросами. Большинство программ, которые мы запускаем на наших настольных компьютерах или (когда-то) запускались на мейнфреймах, запускались, обрабатывали пакет данных и закрывались.

Во-вторых, метод malloc()/free() выделения/освобождения памяти был простым, в то время как упреждение размеров запросов памяти не было; и некоторые выделения используются кратковременно и возвращаются, а некоторые сохраняются на время выполнения. Как разработчику библиотеки обеспечить объединение в настоящее время свободной и недавно освобожденной памяти, не зная об использовании выделения/освобождения и размерах запросов? Схема буфера фиксированного размера, описанная выше, не страдает от проблемы фрагментации, которая возникает при использовании "malloc() произвольного числа байт". схема делает. Он по-прежнему ограничен доступной памятью, но в пределах этого ограничения может соответствовать требованиям "работать вечно" требование. Могут существовать алгоритмы, разделяющие и объединяющие память, но, вероятно, только для нескольких (статистически предсказуемых) шаблонов выделения и освобождения.

Обновление от 18.02.23:

@edgarbonet отмечает, что free() Arduino действительно пытается объединить свободные блоки. Это хороший пример алгоритма, который работает в определенных случаях: при правильном выполнении он будет работать для "последний вышел / первый пришел"; случаев и в некоторой степени для некоторых других случаев.

Проблема в том, что большинство наших шаблонов использования не очень регулярны, если они вообще регулярны. Алгоритм, который не выполняет разбиение, а просто выделяет & освобождение фрагментов фиксированного размера (скорее, как одалживание библиотечных книг) может по-прежнему исчерпать память, но не приведет к фрагментации ресурсов. На самом деле, поскольку он не разделяется, ему потребуется больше памяти для обработки тех же запросов произвольного размера, чем даже объединению malloc() и free( ).

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

Допустим, вы используете Arduino для управления дроном. Любая ошибка в любой части вашего кода потенциально может привести к тому, что он упадет с неба и навредит кому-то или чему-то. Другими словами, если кому-то не хватает компетенций для использования malloc, ему, вероятно, вообще не следует писать код, поскольку существует множество других областей, где небольшие ошибки могут вызвать серьезные проблемы.

Сложнее ли отследить и исправить ошибки, вызванные malloc? Да, но это больше вопрос разочарования со стороны кодеров, чем риск. Что касается риска, любая часть вашего кода может быть такой же или более рискованной, чем malloc, если вы не предпримете шаги, чтобы убедиться, что все сделано правильно.

Я взглянул на алгоритм, используемый malloc(), из avr-libc, и кажется чтобы было несколько шаблонов использования, безопасных с точки зрения кучи фрагментация:

1. Выделять только долгоживущие буферы

Под этим я подразумеваю: выделить все необходимое в начале программы, и никогда не освобождай его. Конечно, в этом случае вы могли бы также использовать статический буферы...

2. Выделять только кратковременные буферы

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

void foo()
{
    size_t size = figure_out_needs();
    char * buffer = malloc(size);
    if (!buffer) fail();
    do_whatever_with(buffer);
    free(buffer);
}

Если внутри do_whatever_with() нет malloc или если эта функция освобождает все, что он выделяет, то вы защищены от фрагментации.

3. Всегда освобождать последний выделенный буфер

Это обобщение двух предыдущих случаев. Если вы используете кучу как стек (последний пришел первым вышел), то он будет вести себя как стек а не фрагмент. Следует отметить, что в этом случае безопасно измените размер последнего выделенного буфера с помощью realloc().

4. Всегда выделяйте одинаковый размер

Это не предотвратит фрагментацию, но безопасно в том смысле, что размер кучи не превысит максимальный используемый размер. Если все ваши буферы имеют одинаковый размер, вы можете быть уверены, что всякий раз, когда вы освобождаете один из них слот будет доступен для последующего распределения.

Я не согласен с теми, кто считает, что его не следует использовать или что он вообще не нужен. Я считаю, что это может быть опасно, если вы не знаете всех тонкостей этого, но это полезно. У меня есть случаи, когда я не знаю (и не должен знать) размер структуры или буфера (во время компиляции или во время выполнения), особенно когда речь идет о библиотеках, которые я отправляю в мир. Я согласен, что если ваше приложение имеет дело только с одной известной структурой, вы должны просто запечь этот размер во время компиляции.

Пример: у меня есть класс последовательного пакета (библиотека), который может принимать данные произвольной длины (может быть структура, массив uint16_t и т. д.). На стороне отправителя этого класса вы просто сообщаете методу Packet.send() адрес объекта, который вы хотите отправить, и порт HardwareSerial, через который вы хотите его отправить. Однако на принимающей стороне мне нужен динамически выделяемый приемный буфер для хранения этой входящей полезной нагрузки, поскольку эта полезная нагрузка может иметь другую структуру в любой момент, например, в зависимости от состояния приложения. ЕСЛИ я когда-либо отправляю только одну структуру туда и обратно, я бы просто сделал размер буфера таким, каким он должен быть во время компиляции. Но в случае, когда длина пакетов с течением времени может меняться, malloc() и free() не так уж плохи.

Я запускал тесты со следующим кодом в течение нескольких дней, позволяя ему выполнять непрерывный цикл, и я не нашел признаков фрагментации памяти. После освобождения динамически выделенной памяти свободный объем возвращается к своему предыдущему значению.

// можно найти по адресу Learn.adafruit.com/memories-of-an-arduino/measuring-free-memory
int freeRam () {
    extern int __heap_start, *__brkval;
    int v;
    return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}

uint8_t *_tester;

while(1) {
    uint8_t len = random(1, 1000);
    Serial.println("-------------------------------------");
    Serial.println("len is " + String(len, DEC));
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("_tester = " + String((uint16_t)_tester, DEC));
    Serial.println("alloating _tester memory");
    _tester = (uint8_t *)malloc(len);
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("_tester = " + String((uint16_t)_tester, DEC));
    Serial.println("Filling _tester");
    for (uint8_t i = 0; i < len; i++) {
        _tester[i] = 255;
    }
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("freeing _tester memory");
    free(_tester); _tester = NULL;
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("_tester = " + String((uint16_t)_tester, DEC));
    delay(1000); // Беглый взгляд
}

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

Действительно ли плохо использовать malloc() и free() с Arduino?

Короткий ответ — да. Ниже приведены причины, по которым:

Все дело в понимании того, что такое MPU и как программировать в рамках ограничений доступных ресурсов. Arduino Uno использует ATmega328p MPU с флэш-памятью ISP 32 КБ, EEPROM 1024 КБ и SRAM 2 КБ. Это не так много ресурсов памяти.

Помните, что 2 КБ SRAM используется для всех глобальных переменных, строковых литералов, стека и возможного использования кучи. В стеке также должен быть запас для ISR.

Схема памяти следующая:

Сегодня ПК/ноутбуки имеют более чем в 1 000 000 раз больше памяти. Размер стека по умолчанию в 1 Мбайт на поток не является чем-то необычным, но совершенно нереалистичным для MPU.

Проект встроенного программного обеспечения должен составлять бюджет ресурсов. Это оценка задержки ISR, необходимого объема памяти, вычислительной мощности, циклов инструкций и т. д. К сожалению, бесплатных обедов не существует, и встраиваемое программирование в жестком реальном времени является наиболее трудно овладеть навыками программирования.

Хорошо, я знаю, что это старый вопрос, но чем больше я читаю ответы, тем чаще я возвращаюсь к наблюдению, которое кажется важным.

Проблема остановки реальна

Кажется, здесь есть связь с проблемой остановки Тьюринга. Разрешение динамического распределения увеличивает шансы упомянутой «остановки», поэтому вопрос становится вопросом устойчивости к риску. Хотя удобно отмахнуться от возможности сбоя malloc() и т. д., это все же допустимый результат. Вопрос, который задает OP, кажется, касается только техники, и да, детали используемых библиотек или конкретного MPU имеют значение; разговор идет о снижении риска остановки программы или любого другого аварийного завершения. Нам необходимо признать существование сред, которые терпимо относятся к риску совершенно по-разному. Мой хобби-проект по отображению красивых цветов на светодиодной ленте не убьет кого-то, если произойдет что-то необычное, но MCU внутри аппарата искусственного кровообращения, скорее всего, убьет.

Здравствуйте, мистер Тьюринг, меня зовут Хабрис

Что касается моей светодиодной ленты, мне все равно, заблокируется ли она, я просто перезапущу ее. Если бы я был на аппарате искусственного кровообращения, управляемом MCU, последствия его блокировки или отказа в работе были бы буквально жизнью и смертью, поэтому вопрос о malloc() и free() должен быть разделен между тем, как предполагаемая программа справляется с возможностью демонстрации знаменитой проблемы г-на Тьюринга. Легко забыть, что это математическое доказательство, и убедить себя в том, что если мы достаточно умны, то можем не стать жертвой ограничений вычислений.

На этот вопрос должно быть два общепринятых ответа: один для тех, кто вынужден моргать, глядя в лицо проблеме остановки, и один для всех остальных. Хотя большинство применений Arduino, вероятно, не являются критически важными или жизненно важными приложениями, различие все еще существует независимо от того, какой MPU вы можете кодировать.