BC/NW 2010, №1 (16): 10.5

АНАЛИЗ ТРЕБОВАНИЙ К МЕНЕДЖЕРУ ДИНАМИЧЕСКОЙ ПАМЯТИ ДЛЯ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

Федотов В.Ю., Семенова О.В.

(Филиал ГОУВПО «МЭИ (ТУ)» в г.Смоленске)

Одной из проблем программирования в операционной системе реального времени является невозможность работы с кучей[1]. Однако многие современные библиотеки, такие как BOOST, STL, LOKI, используют кучу для динамического создания объектов[2]. В связи с этим возникает задача создания менеджера памяти, дающего возможность размещения динамически создаваемых объектов в обход кучи за время, которое не зависит ни от размера запрашиваемой памяти, ни от количества запросов, ни от объема заполненной памяти.

Задача создания менеджера памяти рассматриваются в источниках [2,3]. Однако описанные решения не предназначены для использования в операционных системах реального времени, так как они ориентированы на оптимизацию размещения небольших объектов с обращением к куче.

Рассмотрим подробно требования, предъявляемые к менеджеру памяти.

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

Во-вторых, нужно предусмотреть механизмы автоматического расширения. Такие механизмы позволяют пользователям менеджера не задумываться о наличии свободной памяти в нем или об изменении его внутренней конфигурации. Сама внутренняя конфигурация должна храниться в специальном настроечном файле. При загрузке системы данные из этого файла считываются и используются для инициализации менеджера памяти. При завершении работы системы в этот файл необходимо сохранить информацию о текущей конфигурации менеджера, если она была изменена вследствие расширения. Можно условиться, что при превышении определенного процента заполнения памяти необходимо изменить конфигурацию таким образом, чтобы при следующей загрузке системы в менеджере памяти снова был запас. Это безопасный механизм расширения с использованием “подушки”. Однако при возникновении ситуации, когда в ходе работы системы при создании динамического объекта кончилась свободная память, необходимо произвести ее текущее расширение. Такая операция является небезопасной, так как время ее выполнения спрогнозировать нельзя. Стоит отметить, что расширение должно производиться в соответствии со стратегией экспоненциального роста[3].

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

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

Литература

1. Документация по RTOS32.

2. Александреску А. Современное проектирование на C++. М.:Вильямс, 2008.–335с

3. Саттер Г. Решение сложных задач на C++. М.:Вильямс, 2008.–400с