ИУС_РК2

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

При использовании монолитного ядра (monolithic kernel) вся система является единой программой, в которой можно использовать общие структуры данных и организовывать взаимодействие путем простых вызовов процедур [1].

Для добавления новых частей в ядро необходима перекомпиляция, либо реализация механизма оверлеев. Ядро с реализацией оверлеев называют обычно модульным. Оверлей - механизм управления распределением ресурсов, при котором допускается их совместное использование. Как правило, под термином оверлей понимается механизм повторного использования блоков памяти данных и кода в вычислительных системах, работающих в рамках модели вычислений Фон-Неймана.

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

В своей книге «Just for fun» Линус Торвальс так отзывается о особенностях микроядра. «Теоретически необходимость микроядра обосновывается следующим образом. Операционные системы сложны. Для их упрощения применяется

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

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

Это самое главное возражение против микроядра. Простота, обеспечиваемая микроядром, является мнимой.»

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

Обзор компонентов ядра ОС РВ

Переключатель задач ОС РВ

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

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

Причин переключения всего две: время (time triggered) или наличие события (event triggered). Первый вариант переключения осуществляется по специально созданному расписанию. Второй позволяет вызывать задачи как ответ на возникающее событие.

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

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

•В контроллер прерываний приходит запрос на прерывание.

•Контроллер прерываний прекращает выполнение текущей последовательности команд. На стеке сохраняется адрес следующей, еще не исполненной команды.

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

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

•По окончании работы обработчика, последней командой исполняется команда возврата из прерывания, из стека изымается адрес возврата и осуществляется переход на этот адрес.

•Начинается выполнение прерванной ранее программы.

Как правило, контроллеры прерываний имеют приоритетную систему выбора прерывания, обработчик которого надо вызвать в первую очередь. Суть приоритета в том, что это числовая оценка важности задачи. Чем выше приоритет — тем важнее задача, и тем раньше ее надо выполнить. Казалось бы — вот хороший и простой механизм, позволяющий получить псевдопараллельное исполнение программ на базе Фон-Нейманновской архитектуры. Однако не все так просто, как кажется. Когда задач много, становится достаточно трудно оценить, будет выполнена та или иная задача вовремя или нет. Какие есть проблемы у данного подхода? Если внутри обработчика прерывания запретить прерывания, то все остальные обработчики не смогут выполняться, до тех пор, пока не закончится более высоко приоритетное прерывание.

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

•Таймер переполняется и выставляет запрос на прерывание.

•Контроллер прерываний прерывает работу текущей программы.

•Адрес следующей невыполненной команды и содержимое регистров сохраняется в стеке.

•Переключатель задач запоминает указатель стека в контексте i-го процесса.

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

•Выполняется команда возврата из прерывания. Мы попали в другой процесс.

Вописанной выше схеме процессы получают одинаковые кванты времени и их выполнение имеет одинаковый приоритет. Для управления приоритетом задач в таких системах используют специальные планировщики.

Вкачестве простого примера рекомендую посмотреть исходные тексты переключателя задач операционной системы FreeRTOS. Эта простая и компактная операционная система с открытыми исходными текстами распространяется свободно и может быть использована даже в коммерческих проектах. Исходные тексты доступны на сайте http://www.freertos.org/.

Приведенный пример переключателя задач принадлежит FreeRTOS версии 5.0.3

ивзят из следующего каталога исходных текстов:

FreeRTOS\Source\portable\SDCC\Cygnal

// ----------------------------------------------------------------------------------------------------------------------------------------------------------

//Переключатель задач FreeRTOS

//(порт для ядра MCS51, компилятор SDCC)

//----------------------------------------------------------------------------------------------------------------------------------------------------------

void vTimer2ISR. ( void ) interrupt 5 _naked { portSAVE_CONTEXT () ;

// Сохранение контекста в стеке // (push regs)

portCOPY_STACK_TO_XRAM ();

// Копирование стека во внешнее ОЗУ

vTaskIncrementTick();

// Инкремент системных часов

vTaskSwitchContext();

// Выбор очередной задачи из списка

portCLEAR_INTERRUPT_FLAG();

//Корректное завершение прерывания,

//сброс флагов

portCOPY_XRAM_TO_STACK ();

}

Функция переключателя задач vTimer2ISR реализована как обработчик прерывания от таймера. Исходный текст функции в полном виде можно посмотреть в файле port.c. В файле task.h можно посмотреть описания системных вызовов.

Реализация планирования задач в ОС РВ

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

Врамках ОС РВ, планировщик, как правило, выделяет только один ресурс - ресурс процессорного времени.

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

ВОС РВ планировщик не является монопольным распределителем ресурсов. Кроме планировщика, к вопросам управления ресурсом процессорного времени (процессами) относятся:

•средства IPC;

•средства синхронизации и взаимного исключения (семафоры и мьютексы, критические секции).

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

Межпроцессное взаимодействие

Межпроцессное взаимодействие, IPC (Inter-process communication) - набор механизмов для взаимодействия между процессами, работающих в рамках потоковой модели вычислений.

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

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

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

•арбитр системной шины;

•мьютекс для организации IPC между процессорами NIOS в среде Quartus.

Мьютекс - средство взаимного исключения, двоичный семафор. Переменная, хранящаяся внутри мьютекса, может принимать значения 0 и 1.

Методы реализации взаимного исключения, классификация

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

•внешние;

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

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

Первый вариант управления обычно реализуют в виде планировщика, второй - в виде монитора.

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

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

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

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

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

Алгоритм работает на использовании двух переменных: у каждого процесса есть собственная переменная flag[i]

и общая переменная turn. Все переменные хранятся в общей для обоих процессов памяти. В переменной flag

запоминается факт захвата ресурса, в переменной turn - номер захватившего ресурс процесса.

При исполнении пролога критической секции процесс Pi заявляет о своей готовности выполнить критический участок и одновременно предлагает другому процессу приступить к его выполнению. Если оба процесса подошли к

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

P0: flag[0] = 1 turn = 1

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

соответствует номеру соседа.

Еще один вариант реализации алгоритма Петерсона:

void. mut_excl(int me /* 0 or 1 */)

{

static int loser;

static int interested.[2] = {0, 0}; int other; /* local variable */

other = 1 - me; interested[me] = 1; loser = me; while (loser == me && interested[other])

/* critical section */ interested[me] = 0;

}

Алгоритм Деккера - программная реализация механизма взаимного исключения без запрещения прерываний. Алгоритм имеет смысл в системах на базе модели вычислений Фон-Неймана. Алгоритм Деккера усовершенствован Петерсоном (см. алгоритм Петерсона).

Алгоритм имеет следующие ограничения.

•Алгоритм рассчитан только на 2 процесса (от этого ограничения свободен алгоритм пекарня (Bakery algorithm)).

•При ожидании ресурса, процессы не снимаются с очереди на обслуживание и впустую тратят процессорное время (активное ожидание).

Принцип работы аналогичен используемому в алгоритме Петерсона.

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

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

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

Алгоритм пекарня - программная реализация механизма взаимного исключения без запрещения прерываний. Алгоритм пекарня имеет смысл в системах на базе модели вычислений Фон-Неймана. В отличии от алгоритма Деккера и Петерсона отсутствует ограничение на число процессов.

Изобретен Лесли Лампортом (Leslie Lamport). Приоритет процессов

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

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

// Определение и начальная инициализация глобальных переменных // Переменные доступны всем процессам Entering: array [ 1 . . N ] o f bool = { f a l s e } ;

Number: array [ 1 . . N ] o f integer = { 0 } ; / / ==============================

// Вход в критическую секцию // i - номер процесса // ==============================

lock(integer i)

{

Entering[i] = true;

Number[i] = 1 + max(Number[1], . . . , Number[N]); Entering[i] = false; for (j = 1; j <= N; j + + )

{

/ / Ждем

while ( E n t e r i n g [ j ] ) ; / / Ждем

// while ((Number[j] != 0) && ( ( N u m b e r [ j ] , j ) < (Number[i], i ) ) ) ;

}

}

/ / ==============================

// Выход из критической секции // i - номер процесса // ==============================

unlock(integer i)

{

Number[i] = 0;

}

//==============================

//Пример использования

//i - номер процесса

//==============================

Process_example(integer i)

{

while (true)

{

l o c k ( i ) ;

/ / Критическая секция unlock(i); // Выход из критической секции

}

Критическая секция

Критическая секция (Critical section) - это часть программы, в работу которой не может вмешаться другой процесс. Понятие "критическая секция" имеет смысл в тех системах, где возможно прерывание какого либо действия. Как правило, критические секции используются в системах, сделанных на базе модели вычислений Фон-Неймана и Process Network. Другими словами, критические секции используются при программировании классических микроконтроллеров и микропроцессоров, при использовании ОС РВ или прерываний.