GRID_УП

111

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

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

Механизмы синхронизация в ОС LynxOS 5.0 на уровне ядра

В ОС LynxOS 5.0 для обеспечения работы в SMP-среде были добавлены новые механизмы синхронизации на уровне ядра операционной системы: атомарные операции, спин-блокировки

(spin lock) ядра, большая блокировка ядра (BKL — Big Kernel

Lock).

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

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

BKL — специальный вид спин-блокировки, который существует только в единственном экземпляре на всю систему. BKL

112

может использоваться только одной задачей в системе в любой момент времени. В отличие от обычной спин-блокировки BKL влечет запрет прерывания и вытеснения потоков на всех процессорах в системе.

Атомарные переменные и операции. ОС LynxOS 5.0 под-

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

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

1.Процессор загружает текущее значение счетчика, например 2, в один из своих регистров.

2.Процессор уменьшает это значение в своем регистре; теперь оно равно 1.

3.Процессор записывает новое значение (1) обратно в па-

мять.

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

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

1.Процессор А загружает текущее число 2 в один из своих регистров.

2.Процессор В загружает текущее число 2 в один из своих регистров.

113

3.Процессор А уменьшает значение в своем регистре; теперь оно равно 1.

4.Процессор В уменьшает значение в своем регистре; теперь оно равно 1.

5.Процессор А записывает новое значение (1) обратно в

память.

6.Процессор В записывает новое значение (1) обратно в

память.

7.Процессор А решает, что поскольку значение равно 1, этот разделяемый объект используется каким-то другим процессом, поэтому не освобождает его.

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

Число ссылок в памяти теперь должно быть равно 0, но вместо этого, оно равно 1. Оба процессора удалили свои ссылки на разделяемый объект, но ни один из них его не освободил. Каждый процессор выполнил именно то, что требовалось, и все равно возник неправильный результат. Проблема, безусловно, состоит в том, что процессоры не синхронизировали свои действия. Простейшим средством синхронизации ядра ОС LynxOS

вSMP-среде являются атомарные операции.

ОС LynxOS 5.0 обеспечивает многие операции, которые могут быть атомарно выполнены над значением целого числа,

расположенного в ОЗУ. Атомарно означает, что операция

появляется на всех процессорах и потоках в системе как единственный непрерываемый доступ памяти. Атомарные операции являются самыми быстрыми (по сравнению с другими методами синхронизации) доступными методами синхронизации в случае, когда для синхронизации доступа требуется только одно целое число, поскольку они позволяют пользователю избегать более тяжелых примитивов синхронизации, таких, как семафоры и спин-блокировки. Однако атомарные операции обычно намного более медленные, чем соответствующие неатомарные операции. API для атомарных операций определено в заголовочном файле atomic_ops.h. Атомарные операции с целыми числами доступны как при работе ядра, так и в приложениях пользователя.

114

Все атомарные операции воздействуют на платформенно зависимую переменную типа atomic_t (называемую атомарной переменной). Целое значение числа, содержащееся в типе atomic_t, имеет тип atomic_value_t. Это 32-битовое число со зна-

ком. Тип atomic_t преднамеренно определен так, чтобы переменные этого типа не могли применяться в выражениях на языке C с целыми числами, а только использовались с помощью API для атомарных операций.

Вызов atomic_init (av, v) инициализирует атомарную переменную av и устанавливает ее в указанное значение v. Все атомарные переменные должны инициализироваться прежде, чем они смогут использоваться. Другой способ инициализировать атомарную переменную состоит в том, чтобы присвоить ей начальное значение ATOMIC_INITIALIZER (v) при определении переменной, где v — ее начальное значение:

#include <atomic_ops.h>

…

atomic_t av1 = ATOMIC_INITIALIZER (0); atomic_t av2;

…

atomic_init (av2, 0);

Операции над атомарными переменными приведены в таблице 5.1.

Таблица5.1 — ОперациинадатомарнымипеременнымивОСLynxOS

116

Барьеры памяти

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

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

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

117

1.Блокировка ресурса.

2.Доступ к ресурсу.

3.Разблокировка ресурса.

Все три пункта содержат доступы памяти. Крайне важно, чтобы пункт 1 был выполнен сначала, затем пункт 2, затем пункт 3. Однако это, возможно, не настолько очевидно для оптимизирующего компилятора и процессора, которые видят только последовательность команд, не зная их цели. Если компилятор или процессор переставляют команды доступа к памяти пункта 2 с пунктом 1 или пунктом 3, то эти команды выпадают из критической области, чего определенно не хочет программист.

ОС LynxOS 5.0 реализует ряд вызовов, чтобы обеспечить желательный порядок доступа к памяти — барьеры памяти.

Есть два вида барьеров памяти: общий и специализированный. Общие барьеры памяти гарантируют выполнение своих функций в любой ситуации; однако они являются обычно весьма медленными. В определенных случаях могут использоваться менее универсальные барьеры, которые называются специали-

зированными барьерами.

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

API барьеров памяти определен в заголовочном файле membar.h. Барьеры памяти доступны и в ядре, и в программах пользователя. Общие барьеры памяти приведены в таблице 5.2.

Таблица 5.2 — Описание барьеров памяти в ОС LynxOS

Особенности генерации ядра ОС LynxOS 5.0 для работы с несколькими процессорами (ядрами).

Каждый процессор может выполнять один поток в каждый момент времени. Следовательно, система с N процессорами в состоянии выполнять одновременно N потоков.

При генерации ядра ОС LynxOS 5.0 для работы с несколькими процессорами надо задать значение параметра

NUM_CPUS в файле

$ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h

Если параметра NUM_CPUS нет в файле uparam.h, то ОС LynxOS не будет поддерживать SMP и будет использовать только один процессор. Если параметр NUM_CPUS определен и равен 0 (по умолчанию), то ОС LynxOS будет стараться определить число процессоров автоматически и использовать все найденные процессоры.

Обычно этого достаточно для большинства конфигураций, но иногда желательно явно указать число процессоров, например для того чтобы уменьшить время загрузки операционной системы. Если параметр NUM_CPUS равен –1, то число процессоров берется из установок BIOS. Если параметр NUM_CPUS равен 1, то ОС LynxOS работает в однопроцессорной конфигу-

119

рации. И, наконец, если параметр NUM_CPUS не меньше двух, то он задает число процессоров, которые должны использоваться операционной системой.

Основными аппаратными платформами, которые поддерживаются всеми версиями ОС LynxOS, являются x86 и PowerPC. Кроме того, существуют специальные заказные версии для процессоров MIPS. Кроме ОС LynxOS, компания LynuxWorks предлагает пользователям еще четыре системных продукта: LynxOS-178, LynxOS-SE, LynxSecure, BlueCat Linux.

5.3.2 OS-9

Система OS-9 выпускается фирмой Microware (USA). Основные характеристики:

Категория: host/target.

Архитектура: на основе микроядра. Стандарт: собственный.

ОС разработки (host): Unix/Windows

Процессоры (target): Intel 80x86, Motorola 68xxx, ARM,

PowerPC, MIPS и др.

Линии связи host/target: последовательный канал и Ethernet.

Размер ядра: 16Кб.

Средства синхронизации и взаимодействия: разделяемая память, сигналы, семафоры, события и т.д.

Планирование: приоритетное, FIFO, специальный механизм планирования, preemptible.

Средства разработки:

Hawk — интегрированная среда разработки на С/C++. PersonalJava — виртуальная машина Java.

В 1979 году совместными усилиями фирм Microware и Motorola была разработана операционная система реального времени для микропроцессора 6809. Версия Level I OS-9/6809 была способна адресовать 64 КВ памяти. Версия Level II OS- 9/6809, используя прогрессивные в то время аппаратные средства динамической трансляции адресов, была способна адресовать уже до 2 МВ памяти и стала применяться в ряде популярных

120

компьютерных систем, например таких, как Tandy Color Computer III.

В1982 году Microware (уже независимо от Motorola) порти-

ровала ОС OS-9 для семейства микропроцессоров 68000, создав систему OS-9/680X0 для 16- и 32-разрядных микропроцессоров

имикроконтроллеров. Код системы лишь на 20 % был написан на языке высокого уровня (фрагмент распределения памяти и настраиваемая часть загрузочного кода), остальная часть с целью достижения максимальной производительности написана на Ассемблере. За пять лет с момента появления ОС OS-9/680X0 стала признанным промышленным стандартом де-факто для операционных систем реального времени (и абсолютным лидером по применимости в промышленных приложениях на базе технологии VME).

Всписке поддерживаемых микропроцессоров ОС OS-9/68K наиболее полно представлено семейство 68К — от младшего в серии MC68000 до 32-разрядного, суперскалярного MC68060. Наибольшую популярность и распространение получили версии 2.4/2.5 системы, и в настоящее время пользователями по достоинству оценены мощь и надежность новейшей версии системы — 3.0.1.

ОС OS-9000 — переносимая версия ОС OS-9, написанная главным образом (95 %) на С. Оставшиеся, критичные с точки зрения производительности, участки кода написаны на Ассемблере. Как результат, только 5 % ОС OS-9000 необходимо переписать, чтобы перенести ее на новый процессор. Теоретически ОС OS-9000 может быть перенесена на любую современную микропроцессорную архитектуру.

Для пользователя ОС OS-9 и ОС OS-9000 — UNIX подобная среда. Модель процессов, межпроцессная коммуникация, многопользовательская файловая система и большое количество стандартных для UNIX утилит — все это позволит программисту, знакомому с UNIX, в минимально короткий срок почувствовать себя уверенно в среде реального времени ОС OS-9. Единство архитектурных решений, совместимость приложений на уровне исполняемого кода, технология реализации интегральных средств разработки, а также дизайна и состава системных продуктов — эти факторы объединяют операционные сис-