Выбор способа реализации программных модулей и их взаимодействия со средой исполнения

Рассмотрев содержание структуры (см. раздел 1, [2]), можно перейти к более сложному вопросу: определение типов связей между модулями системы. Для этого, попробуем определить, в каких модулях может произойти непредвиденный отказ, последствия которого нужно предотвратить. Данные проекта, загружаются в начале работы, и (при необходимости) сохраняются при завершении — отказ при хорошей отладке произойти не может. Отказ ИУ и УИ в любом случае приведет к искажению данных и, как следствие, к отказу всей системы, поэтому подстраховаться тут универсальными программными средствами невозможно. Модуль сравнения двух результатов содержит довольно простой алгоритм и простым тестированием этого модуля можно свести вероятность отказа в нем к нулю. Следовательно, связь этих модулей со средой исполнения можно реализовать через статическую компоновку или статические или динамические библиотеки. Таким образом, единственное «слабое звено» нашей системы – это мультиверсии, так как в них производятся сложные вычислительные операции. Здесь возможны несколько вариантов взаимодействия со средой (представлены, по порядку возрастания потребности в памяти).

 

1. Статическая компоновка: из исходных кодов, либо с использованием статических библиотек.

Проект программной системы выглядит как набор исходных текстов (либо объектных кодов) СМВИ, в который требуется поместить под строго заданными именами исходные тексты (либо объектные коды) мультиверсий, ИУ, УИ, модуля сравнения двух результатов. После этого вызывается makefile – файл сборки проекта (в данном случае, хранящий данные проекта) и получается исполняемый модуль, готовый к исполнению.

Преимущества:

+ простые механизмы взаимодействия между модулями

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

+ эта модель обладает самой большой производительностью и самой низкой потребностью к памяти

+ данная модель не требует от ОС (либо эмулирующего ее модуля) только наличия функций поддержки многопотоковости и объектов синхронизации.

 

Недостатки:

- общий процесс для всех модулей

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

- общее адресное пространство у версий и среды исполнения

При «зависании» одной из версий, СМВИ вынуждена будет ее перезапустить, т.е. удалить старый поток и создать его заново. Из-за общего адресного пространства операционная система (ОС) заблокирует весь процесс на время удаления потока (что может продлиться от миллисекунд до нескольких секунд), что может оказаться катастрофичным для объекта управления.

- накапливаемые утечки памяти

При перезапуске версии, неизбежно будут возникать «утечки памяти», которые могут привести к неработоспособности (либо отказу) как среды исполнения, так и перезапущенных версий. Бороться с ними можно либо создав в СМВИ общие механизмы выделения и освобождения памяти, и обязать использовать их мультиверсии (что несколько снизит производительность), либо использовать статическую память (что не всегда возможно).

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

 

2. Компоновка с использованием динамических библиотек

В этом случае, среда мультиверсионного исполнения представлена исполняемым модулем. Файлы с ИУ, УИ, версиями, модулем сравнения двух результатов и файл проекта выполнены в виде динамических библиотек со строго заданными в файле проекта именами. Для запуска такого проекта, достаточно поместить все файлы в одну папку и запустить исполняемый модуль.

 

Преимущества:

+ простые механизмы взаимодействия между модулями

+ данная модель не требует от ОС (либо эмулирующего ее модуля) только наличия функций поддержки многопотоковости и объектов синхронизации.

 

Недостатки:

- общий процесс для всех модулей

- общее адресное пространство у версий и среды исполнения

- накапливаемые утечки памяти

 

3. Компоненты выполнены в отдельных исполняемых модулях

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

Данную модель можно разделить на две, по виду взаимодействия между исполняемыми модулями:

 

А) через общие участки памяти (например, файлы);

 

Преимущества:

+ нет утечек памяти при рестарте потоков

+ утечки памяти не катастрофичны

+ необработанное исключение приведет только к отказу одного модуля, и безопасно для системы

 

Недостатки:

- усложнение модулей, для обеспечения синхронизации доступа к общим участкам памяти и, как следствие, возможное снижение надежности.

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

- необходимо написание специальных программ-агентов для рестарта модулей

- Данная модель компоновки модулей применима только, если ОС (либо эмулирующий ее модуль) поддерживает динамическое подключение библиотек.

 

В) через сетевой протокол.

 

Преимущества:

+ нет утечек памяти при рестарте потоков

+ утечки памяти не катастрофичны

+ необработанное исключение приведет только к отказу одного модуля, и безопасно для системы

+ возможность распределения вычислений по сети

Однако, это не исключает запуск и выполнение всех модулей на одной ЭВМ: современные сетевые протоколы позволяют производить соединение с самим собой, что нередко используется в различном программном обеспечении.

Недостатки:

- необходимо написание специальных программ-агентов для рестарта модулей.

- Данная модель компоновки модулей применима только для ОС (либо эмулирующих ее модулей), поддерживающих работу с сетевыми протоколами.

 

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