Санкт-Петербургская группа тестирования JVM

Краткий обзор Java Real-Time

Многие полагают, что когда речь идет о системах реального времени, то в первую очередь имеется ввиду быстродействие и эффективность. На самом деле это не так. Система реального времени—это система, которая должна ответить на внешнее воздействие в пределах заданного конечного периода времени. В области программного обеспечения примеров подобных систем немного. Временные ограничения становятся особенно важными когда речь идет о различного рода устройствах, управляемых программным обеспеченем. Так, например, системы real-time широко используются в самолетах, автомобилях, системах слежения и других областях.

Как правило, подобные системы состоят из набора сенсоров, управляющего модуля, и механизма реакции на данные полученные от сенсоров. Ядро управляющего модуля и является приложенем реального времени. Какие требования предъявляются к подобному программному обеспечению? В первую очередь, это предсказуемость и надежность. Предсказуемость означает, что между событием, произошедшим  в системе и действием (реакцией) на это событие должно пройти как можно меньше времени. Эта задержка (latency) определяет насколько чувствительна ваша система. Для предсказуемости важна не только сама задержка, но и ее изменение. Поэтому, еще более важным показателем предсказуемости является вариация задержки (jitter). Гарантировать фиксированную вариацию задержки—первоочередная задача для системы реального времени.

Получить среду реального времени на основе платформы Java было давней мечтой многих разработчиков. Еще в 1998 году был создан самый первый JSR (Java Specification Request) под названием "Real-time Specification for Java", который был впервые реализован Sun Microsystems лишь в 2005 году. Что же необходимо сделать, чтобы Java стала платформой реального времени? В первую очередь, сделать паузы в приложении, вызванные JIT компилятором и сборщиком мусора, более предсказуемыми и добавить API для контроля времени выполнения приложения.

Спецификация определяет семь основных областей, достаточных для создания приложений real-time.

1. Потоки реального времени (Real-time Threads)

В любой системе реального времени существуют части, для которых временные ограничения крайне важны и части, для которых это не важно. Как правило, выделяют 3 области, связанные с временными ограничениями: hard real-time—все задачи должны быть выполнены в срок, soft real-time—некоторые задачи могут нарушить временные ограничения, non real-time—временные ограничения отсутствуют. Согласно RTSJ (Real-time Specification for Java) в каждой их этих областей нужно использовать определенные классы-потоки: NoHeapRealtimeThread, RealtimeThread, Thread соответственно.

2. Модель управления памятью (Memory Management Schemes)

Как и следует из названия NoHeapRealtimeThread, этот вид потока не может создавать объекты в куче. Для того, чтобы гарантировать полную предсказуемость для hard real-time области, была придумана новая программная модель, полностью исключающая взаимодействие со сборщиком мусора. Спецификация определяет 3 области памяти, в которых возможно создавать объекты: Immortal Memory, Scoped Memory, Heap Memory. Сборщик мусора работает только в heap memory, поэтому используя эту память вы не только по прежнему не заботитесь об удалении объектов, но получаете непредсказуемое поведение приложения. Объекты, создаваемые в Immortal memory никогда не удаляются. В этой области памяти создаются базовые объекты, которые должны существовать до конца работы приложения. Scoped memory предназначена для работы потоков hard real-time. Если такому потоку необходимо произвести некоторые промежуточные вычисления,  он "входит" в область памяти используя метод enter(), создает там временные объекты, которые будут сразу же удалены при выходе из этой области памяти. Каждый real-time поток использует, как правило, свою scoped memory, а immortal и heap едина для всех потоков. Таким образом в hard real-time области разработчик сам контролирует время удаления временных объектов, избегая при этом работы сборщика мусора.

3. Планировщик (Scheduling)

Механизм распределения задач (scheduler) один из самых важных в приложениях real-time. Именно он определяет какая из задач будет выполняться в тот или иной момент времени. Всем известен scheduler, который распределяет задачи согласно приоритету. Но даже в этом случае трудно сказать, какая из задач выполняется в данный момент и как много процессорного времени будет ей отдано. Планировщик реального времени, базирующийся на приоритетах, гарантирует, что потоку real-time будет отдано все процессорное время, которое необходимо ему для работы, и ни один поток не сможет прервать другой поток с большим приоритетом. Такой предсказуемости вполне достаточно, однако, существуют дополнительные планировщики, которые выполняют в первую очередь задачи, основываясь на временных ограничениях, заданных разработчиком.

4. Синхронизация (Synchronization)

Синхронизация означает, что один поток будет ждать другой, в случае если они совместно используют некоторые ресурсы. Но что произойдет если поток hard real-time будет ждать поток non real-time? В таком случае поток hard real-time будет ждать очень долго, так как планировщик не выделит процессорное время для потока non real-time, пока есть хотя бы один работающий поток real-time. Такая ситуация неприемлема для систем реального времени. Основная идея решения подобных проблем—инверсия приоритета (priority inversion). Инверсия приоритета—это автоматическое повышение приоритета потока non real-time до приоритета потока real-time, который его ожидает. Основная проблема здесь—на какое время повышать приоритет?  Когда система вновь должна сделать его прежним? В системах реального времени очень часто происходит сбои вызванные тем, что приоритет потока non real-time не понизился вовремя (unbound priority inversion).

5. Асинхронные события и передача управления (Asynchronous Events Handling & Asynchronous Transfer of Control)

Существуют большое количество систем, которые реагируют на внешние события в режиме реального времени (event-based real-time systems). Такие системы довольно легко смоделировать, используя механизм обработки событий (Events Handling). Разработчик определяет события (events) в системе и обработчики этих событий (handlers). Обработчики, по сути, ни чем не отличаются от потоков: они также управляются планировщиком в соответствии с их приоритетами.

Кроме того RTSJ определяет безопасный способ передачи управления в рамках потока. В обычных системах вызов метода Thread.interrupt() может привести к непредсказуемым результатам в приложении (например, могут остаться незакрытыми ресурсы). В потоках real-time есть возможность среагировать на вызов метода Thread.interrupt() и завершить необходимые работы.

6. Время и Таймеры (Time & Timers)

Создавая потоки real-time, разработчик указывает необходимые временные рамки их выполнения. RTSJ определяет несколько способов указания время с достаточно высокой точностью, до единиц наносекунд. Это очень важно для систем с короткими управляющими циклами (control loop). Так, например, в самолетах система контроля полета считывает информацию с датчиков и реагирует на нее тем или иным образом каждые 20 миллисекунд. Кроме того есть возможность создавать триггеры с такой же точностью срабатывания.

7. Прямой доступ к физической памяти (Direct Access to Physical Memory)

Контролируя различные устройства ранее необходимо было использовать native-методы для прямого доступа к памяти этого устройства. RTSJ предоставляет возможность делать это напрямую из Java. Теперь можно писать драйвера для этих устройств на языке высокого уровня.

8. Сборщик мусора реального времени (Real-Time Garbage Collector)

Новой модели управления памятью вполне достаточно для хорошей предсказуемости потоков hard real-time: работая в scoped-памяти они могут в любое время остановить сборщик мусора, который собирает объекты в куче. Однако это не решает проблем с потоками soft real-time. Потоки реального времени могут работать как в куче, так и в scoped-памяти. Для того, чтобы сделать потоки, работающие в куче, более предсказуемыми был создан специальный сборщик мусора для работы в условиях реального времени. Основная идея заключается в том, что этот сборщик не может останавливать потоки real-time с высоким приоритетом.

9. Компиляция в момент инициализации (Initialization Time Compilation)

При работе приложения реального времени, паузы вызванные компиляцией JIT или загрузкой классов (class loading) могут быть критичны. Поэтому есть возможность определить набор классов и методов, которые будут загружены и скомпилированны предварительно, в момент загрузки приложения. Это, конечно, замедляет загрузку программы, но зато позволяет избежать непредсказуемых пауз во время работы.

На данный момент существуют 3 основные реализации RTSJ: Java Realtime System (Sun Microsystems),  Metronome (IBM),  Jamaica (aicas). Sun Microsystems анонсировала выход первой версии платформы Java Real-time System в 2005 году. Эта реализация основывается на JDK 1.4.2, и содержит в себе всю функциональность,  описанную в спецификации. В будущем Sun планирует выпустит Real-Time System 2.0, базирующуюся на JDK 1.5 и реализующую Real-Time Garbage Collector и Initialization Time Compilation.

О.С.

опубликовал vmrobot ( апр 28 2006, 03:32:23 AM MSD ) Permalink Комментарии [3]