Стандарты mpi

Большинство современных реализаций MPI поддерживают версию 1.1. Стандарт MPI версии 2.0 поддерживается большинством современных реализаций, однако некоторые функции могут быть реализованы не до конца.

В MPI 1.1 (опубликован 12 июня 1995 года)

поддерживаются следующие функции:

- передача и получение сообщений между отдельными процессами;

- коллективные взаимодействия процессов;

- взаимодействия в группах процессов;

- реализация топологий процессов;

В MPI 2.0 (опубликован 18 июля 1997 года) дополнительно поддерживаются следующие функции:

- динамическое порождение процессов и управление процессами;

- односторонние коммуникации;

- параллельный ввод и вывод.

OpenMP (Open Multi-Processing) это набор директив компилятора, библиотечных процедур и переменных окружения, которые предназначены для программирования многопоточных приложений на многопроцессорных системах с разделяемой памятью на языках C, C++ и Fortran.

Разработку спецификации OpenMP ведут несколько крупных производителей вычислительной техники и программного обеспечения, чья работа регулируется некоммерческой организацией, называемой OpenMP Architecture Review Board (ARB)

OpenMP реализует параллельные вычисления с помощью многопоточности, в которой «главный» (master) поток создает набор подчиненных (slave) потоков и задача распределяется между ними. Предполагается, что потоки выполняются параллельно на машине с несколькими процессорами (количество процессоров не обязательно должно быть больше или равно количеству потоков).

Задачи, выполняемые потоками параллельно, также как и данные, требуемые для выполнения этих задач, описываются с помощью специальных директив препроцессора соответствующего языка — прагм. Например, участок кода на языке Fortran, который должен исполняться несколькими потоками, каждый из которых имеет свою копию переменной N, предваряется следующей директивой: !$OMP PARALLEL PRIVATE(N)

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

Ключевые элементы

Ключевыми элементами OpenMP являются

- конструкции для создания потоков (директива parallel),

- конструкции распределения работы между потокам (директивы DO/for и section),

- конструкции для управления работой с данными (выражения shared и private),

- конструкции для синхронизации потоков (директивы critical, atomic и barrier),

- процедуры библиотеки поддержки времени выполения (например, omp_get_thread_num),

- переменные окружения (например, OMP_NUM_THREADS).

Алгоритм для параллельного вычисления определенного интеграла на заданном отрезке с помощью нескольких потоков.

Отрезок делится на более мелкие отрезки. На каждом меньшем отрезке считается интеграл. Сбор результатов.

1_21. Реальное время — режим работы автоматизированной системы обработки информации и управления, при котором учитываются жёсткие ограничения на временны́е характеристики функционирования. Нарушение этих ограничений считается отказом системы.

Примеры временных характеристик:

• задержка реакции системы на внешние события;

• моменты генерации внутрисистемных событий и т. п.

Система реального времени (СРВ) — это любая система, работающая в режиме реального времени.

Системы реального времени бывают двух типов — системы жесткого реального времени и системы мягкого реального времени. Системы жёсткого реального времени не допускают задержек реакции системы, так как это может привести к:

• потере актуальности результатов

• большим финансовым потерям

• авариям и катастрофам

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

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

Основное отличие системам жёсткого и мягкого реального времени можно охарактеризовать так: система жёсткого реального времени никогда не опоздает с реакцией на событие, система мягкого реального времени — не должна опаздывать с реакцией на событие.

Основные сервисы

Указанный абстрактный уровень предоставляет для прикладного ПО пять основных категорий сервисов:

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

Динамическое распределение памяти. Многие (но не все) ядра ОСРВ поддерживают эту группу сервисов. Она позволяет задачам заимствовать области оперативной памяти для временного использования в работе приложений. Часто эти области впоследствии переходят от задачи к задаче, и посредством этого осуществляется быстрая передача большого количества данных между ними. Некоторые очень малые по размеру ядра ОСРВ, которые предполагается использовать в аппаратных средах с строгим ограничением на объем используемой памяти, не поддерживают сервисы динамического распределения памяти.

Управление таймерами. Так как встроенные системы предъявляют жесткие требования к временным рамкам выполнения задач, в состав ядра ОСРВ включается группа сервисов, обеспечивающих управление таймерами для отслеживания лимита времени, в течение которого должна выполняться задача. Эти сервисы измеряют и задают различные промежутки времени (от 1 мкс и выше), генерируют прерывания по истечении временных интервалов и создают разовые и циклические будильники.

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

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

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

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

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

Архитектуры ОСРВ

В своем развитии ОСРВ строились на основе следующих архитектур.[1]

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

Уровневая (слоевая) архитектура. Пример — MS-DOS. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и ее сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. Главным недостатком таких систем является отсутствие многозадачности.

Архитектура «клиент–сервер». Основной ее принцип заключается в вынесении сервисов ОС в виде серверов на уровень пользователя и выполнении микроядром функций диспетчера сообщений между клиентскими пользовательскими программами и серверами – системными сервисами. Преимущества такой архитектуры:

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

Улучшенная масштабируемость, поскольку ненужные сервисы могут быть исключены из системы без ущерба к ее работоспособности;

Повышенная отказоустойчивость, т. к. «зависший» сервис может быть перезапущен без перезагрузки системы.

1_22.