Операционные системы реального времени

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ КОНТРОЛЯ ИУПРАВЛЕНИЯ РАДИОЭЛЕКТРОННЫМИ СРЕДСТВАМИ

ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

ЕКАТЕРИНБУРГ

2009

1 Введение

1.1 Основные положения

Использование системного и общего программного обеспечения является основным способом сокращения сроков разработки и повышения качества систем реального времени. Для создания мобильных систем реального времени нужно мобильное системное и общее программное обеспечение, а, следовательно, нужна и мобильная ОС.

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

· соответствие международным стандартам,

· мобильность,

· использование концепции микроядра,

· использование объектно-ориентированного подхода,

· использование свободно распространяемого программного обеспечения,

· распространение ОС вместе со средствами разработки прикладных программ.

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

· высокой эффективностью;

· широкой распространенностью;

· наличием международного стандарта на сам язык и на библиотеки языка С;

· наличием компиляторов для широкого круга аппаратных платформ, в том числе и свободно распространяемых вместе с исходными текстами.

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

1.1.1 Соответствие стандартам

При разработке ос2000 использовались следующие международные стандарты:

· POSIX 1003.1, стандарт на мобильные операционные системы (программный интерфейс);

· стандарт С, описывающий язык и библиотеки языка С.

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

Редакция POSIX 1996 года уже охватывает (в качестве необязательной части) основные функции операционных систем реального времени:

· потоки управления (threads),

· сигналы реального времени,

· средства синхронизации (семафоры, мьютексы и условные переменные);

· очереди сообщений,

· высокоточные таймеры,

· асинхронный ввод/вывод.

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

Операционная система ос2000 полностью соответствует стандарту POSIX в части, относящейся к реальному времени. Те части стандарта, которые не относятся к системам реального времени (традиционный UNIX) не реализованы.

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

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

В рамках стандарта С реализованы математические функции (sin, exp, log и др.), функции обработки символов и строк, функции распределения памяти и др. Эти функции хорошо знакомы всем тем, кто разрабатывает программы на языке С. Они входят в состав таких хорошо известных средств разработки программ на языке С, как Borland C и Microsoft Development Studio C/C++.

К сожалению, стандарты не описывают все интерфейсы современных ОС реального времени. Это относится, в частности, к сетевым средствам и к графике. С другой стороны, некоторые свободно распространяемые программные продукты стали стандартами де-факто вследствие их широкого распространения. В силу этого в ос2000 использован аппарат сокетов операционной системы FreeBSD и будет использоваться графический интерфейс X Window.

Для эмуляции протокола Ethernet в многопроцессорных системах, использующих шину VME, будет использован стандарт ANSI/VITA. Этот стандарт позволяет взаимодействовать через шину VME и общую память различным как по аппаратуре, так и по используемой операционной системе процессорным платам.

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

Отметим также, что использование стандартов облегчает освоение системы и помогает при подготовке кадров программистов.

1.1.2 Мобильность

С целью повышения мобильности операционная система разбита на три части:

· не зависящая от аппаратуры,

· зависящая только от типа центрального процессора,

· пакет поддержки модуля (платы).

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

Та часть ОС, которая зависит только от типа процессора, написана на языке C или на Ассемблере и имеет сравнительно небольшой объем. Туда входят, например, функции запоминания и восстановления контекста, пролог и эпилог диспетчера прерываний.

Пакет поддержки модуля (ППМ) содержит ту часть ОС, которая зависит от конкретной ЭВМ (платы). ППМ, в частности, содержит драйверы устройств и диспетчер прерываний (за исключением пролога и эпилога).

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

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

В настоящее время ос2000 содержит пакет поддержки модуля для ЭВМ серии "Багет" с процессором 1В578 (совместимого с процессором MIPS R3000) и для PC-совместимых компьютеров (с процессором Intel).

1.1.3 Архитектура программного обеспечения

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

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

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

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

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

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

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

1.1.4 Временные характеристики

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

· время ответа на прерывание,

· время ответа потока управления.

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

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

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

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

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

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

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

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

· инструментальная ЭВМ (компьютер, с операционной системой типа UNIX),

· целевая ЭВМ (ЭВМ, для которой разрабатывается программное обеспечение).

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

1.2 Потоки управления

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

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

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

1.2.1 Порождение потоков

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

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

1.2.2 Завершение потоков

Поток может быть завершен по его собственной инициативе (нормальное завершение) или принудительно (функцией pthread_cancel() или посылкой сигнала). Нормальное завершение происходит в результате вызова функции pthread_exit() или возврата управления из функции, указанной при порождении потока.

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

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

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

Если удаление разрешено, то указывается когда оно может произойти. Возможны два варианта

· удаление может происходить только в так называемых точках удаления,

· удаление может произойти в любой момент времени, т.е. асинхронно.

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

1.2.3 Функции свертывания

Завершение потока без освобождения ресурсов, которые, вообще говоря, следовало бы освободить, приводит к растратам этих ресурсов. Особенно это важно при принудительном удалении потоков. Для решения этой проблемы служат так называемые функции свертывания, которые выполняются во время завершения потока (как нормального, так и принудительного). Функции свертывания создаются прикладным программистом и выполняются при завершении потока.

Для каждого потока могут использоваться несколько функций свертывания. Функции свертывания регистрируются в стеке функций свертывания. Во время завершения потока функции из этого стека вызываются одна за другой в порядке обратном тому, в котором они заносились в список.

1.2.4 Состояния потоков

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

· ожидает освобождения ресурса,

· ожидает события,

· ожидает истечения интервала времени,

· приостановлен.

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

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

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

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

Более подробную информацию о потоках управления можно получить в гл. Потоки управления.

1.2.5 Планирование потоков

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

В соответствии с POSIX операционная система позволяет использовать следующие три стратегии планирования:

SCHED_FIFO приоритетное планирование,

SCHED_RR приоритетное планирование с разделением времени,

SCHED_OTHER дополнительная стратегия планирования.

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

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

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

При приоритетном планировании (SCHED_FIFO) поток выполняется до тех пор, пока он не перестанет быть работоспособным или пока не появится более приоритетный работоспособный поток.

Приоритетное планирование с разделением времени (SCHED_RR) идентично стратегии SCHED_FIFO с дополнительным условием: если текущий поток управления занимает процессор в течение определенного периода времени (кванта) или дольше, этот поток сначала извлекается из очереди, а затем вновь устанавливается в очередь (то есть становится последним среди потоков с данным приоритетом). При этом ему выделяется новый квант времени.

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

В настоящей версии SCHED_OTHER совпадает с SCHED_RR.

Более подробную информацию о планировании потоков управления можно получить в гл. Планирование.

1.3 Сигналы

1.3.1 Назначение и основные сведения

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

· при обработке исключений (деление на 0, использование неверного адреса и др.);

· для сообщения об асинхронном событии (об окончании операции ввода/вывода, срабатывании таймера и др.);

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

Сигналы могут генерироваться (посылаться прикладной программе) как операционной системой, так и прикладной программой.

В системе имеется несколько видов сигналов. Каждому сигналу соответствует уникальное положительное число (номер сигнала). Кроме того, для сигналов определены имена.

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

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

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

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

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

В ос2000 сигналы реализованы в соответствии с POSIX. При этом надо иметь в виду, что в ос2000 реализованы только потоки управления, но не процессы (с точки зрения POSIX в системе имеется только один процесс). Доставка сигнала процессу трактуется как доставка сигнала прикладной программе (без указания потока управления).

Сигналы можно разбить на две группы:

· обычные сигналы,

· сигналы реального времени.

Рассмотрим отличия сигналов реального времени от обычных сигналов. Пусть повторный сигнал с тем же именем пришел раньше, чем был обработан предыдущий. В этом случае повторный сигнал реального времени будет поставлен в очередь, а обычный сигнал утерян.

В случае обычного сигнала функция обработки сигнала получает только один аргумент - номер сигнала.

В случае сигнала реального времени имеется второй аргумент - значение связанное с сигналом (целое число или указатель). Значение сигнала указывается при порождении сигнала.

1.3.2 Порождение сигналов

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

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

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

· завершение операции асинхронного ввода/вывода,

· поступление сообщения в пустую очередь,

· истечение интервала времени, связанного с программным таймером.

В этих случаях способ уведомления о событии (реакции на событие) указывается прикладной программой в структуре sigevent. Возможны следующие способы уведомления о событии:

· послать сигнал,

· выполнить функцию уведомления в контексте специально созданного для этого потока,

· выполнить функцию уведомления в контексте потока или функции обработки прерываний, производящего уведомление,

· игнорировать событие (не производить уведомления).

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

1.3.3 Доставка и прием сигналов

Если при порождении сигнала не был указан поток управления, которому посылается сигнал, то ОС сама определяет поток, которому будет доставлен сигнал.

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

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

1.3.4 Обработка сигналов

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

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

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

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

Более подробную информацию о сигналах можно получить в гл. Сигналы.

1.4 Средства синхронизации

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

· целочисленные семафоры,

· мьютексы,

· условные переменные.

1.4.1 Семафоры

Семафоры обеспечивают две основные операции:

· захват семафора,

· освобождение семафора.

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

При захвате семафора вначале проверяется счетчик семафора. Если значение счетчика больше нуля, то оно уменьшается на 1, и семафор считается захваченным. Если счетчик равен 0, то это означает, что в настоящее время семафор не может быть захвачен. В таком случае поток управления будет приостановлен (установлен в очередь к семафору) до освобождения семафора. В очереди к семафору может находиться одновременно несколько потоков управления. Потоки управления, находящиеся в очереди, упорядочены по приоритетам, а потоки, имеющие равный приоритет, упорядочены по времени установки в очередь.

При освобождении семафора проверяется, имеются ли потоки, ожидающие освобождения семафора. Если таких потоков нет, счетчик семафора увеличивается на 1. В противном случае значение счетчика не меняется, а из очереди к семафору выбирается первый (наиболее приоритетный) поток управления и объявляется работоспособным.

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

Использование семафоров обеспечит безопасное использование ресурса только в том случае, если все потоки управления будут захватывать семафор перед использованием ресурса, и освобождать его, как только необходимость в нем отпадет. За взаимосвязь ресурсов и семафоров отвечает прикладная программа.

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

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

1.4.2 Мьютексы

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

· захват мьютекса,

· освобождение мьютекса.

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

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

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

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

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

1.4.3 Условные переменные

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

Применение условных переменных основано на использовании двух операций:

· ожидание выполнения условия,

· сообщение о выполнении условия.

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

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

Функции ожидания выполнения условия выполняются в три этапа:

· освобождение мьютекса,

· установка потока в очередь к условной переменной до выполнения условия,

· захват мьютекса.

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

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

Более подробную информацию о средствах синхронизации можно получить в гл. Синхронизация.

1.5 Очереди сообщений

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

· отправка сообщения в очередь,

· прием сообщения из очереди.

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

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

Сообщение устанавливается в очередь в соответствии с приоритетом: после сообщений с большим или равным значением приоритета, но перед сообщениями с меньшим значением приоритета. При приеме сообщений из очереди выбирается первое (то есть наиболее приоритетное) сообщение в очереди. В процессе приема оно удаляется из очереди.

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

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

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

Более подробную информацию об очередях сообщений можно получить в гл. Очереди сообщений.

1.6 Часы и таймеры

1.6.1 Часы

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

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

Оба типа данных (time_t и timespec) могут использоваться для хранения календарного времени. В этом случае хранящиеся в них данные интерпретируются как время, прошедшее с 0 часов 1 января 1970 года.

Структура tm позволяет хранить дату и время в традиционном виде (год, месяц, число, часы, минуты, секунды).

Система всегда содержит, по крайней мере, одни часы с идентификатором CLOCK_REALTIME (системные часы). Значение этих часов интерпретируется как календарное время, то есть время (в секундах и наносекундах), истекшее с 0 часов 1 января 1970 года.

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

Функция clock_settime() позволяет установить показания часов, функция clock_gettime() - опросить показания часов, а clock_getres() - узнать разрешающую способность часов. Все три функции работают с высокой точностью, так используют структуру timespec. Отметим, однако, результаты измерения времени не могут быть точнее, чем разрешающая способность часов.

Функция time() также позволяет опросить показания часов, но с точностью до 1 секунды. Эта функция позволяет опрашивать только системные часы.

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

1.6.2 Таймеры

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

Установка и запуск таймера производится функцией timer_settime(). Эта функция определяет время первого срабатывания таймера, а также период срабатывания (если требуется периодическое срабатывание таймера). Для первого срабатывания таймера можно указать либо абсолютное время срабатывания (то есть таймер сработает, когда часы покажут указанное время), либо относительное (интервал времени, через который должен сработать таймер).

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

Функция timer_settime() позволяет также остановить (сбросить) таймер.

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

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

Когда потребность в таймере отпадет, его следует удалить функцией timer_delete().

1.6.3 Дополнительные возможности

Функции nanosleep() и sleep() позволяют приостановить текущий поток управления, либо на указанный интервал времени, либо до поступления сигнала.

Функция nanosleep() является более точной, чем функция sleep(). Функция sleep() позволяет указывать время только с точностью до секунды, тогда как nanosleep() работает с точностью, которая обеспечивается разрешающей способностью часов.

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

Если компьютер взаимодействует с другими компьютерами, которые находятся в других часовых поясах и используют другое местное время, то вместо местного времени удобно использовать общее для разных часовых поясов время. В качестве такого времени используется всемирное или мировое время - среднее солнечное время начального меридиана. За начальный меридиан условно принимается меридиан обсерватории в Гринвиче (Великобритания). Это время обозначается GMT или UTC. Хотя между GMT и UTC есть определенная разница, мы не будем здесь ее учитывать.

В силу этих причин рекомендуется использовать всемирное время (UTC) для системных часов (CLOCK_REALTIME). Для преобразования местного времени в мировое (UTC) и обратно рекомендуется использовать описанные ниже функции.

Местное (локальное) время описывается разницей с UTC. Эта разница может меняться в зависимости от времени года в связи с переходом на летнее время.

Функции localtime() и localtime_r() позволяют получить локальное время, а функции gmtime() и gmtime_r() - мировое время. Все четыре функции формируют результат в структуре tm, а в качестве исходных данных получают календарное время в секундах, то есть количество секунд, истекших с 0 часов 1 января 1970 года, UTC. Таким образом, исходные данные для этих функций можно получить с помощью функции time().

Функция mktime() преобразует локальное время, записанное в структуре tm, в календарное время (количество секунд, истекшее с 0 часов 1 января 1970 года, UTC).

Функции asctime(), asctime_r(), ctime(), ctime_r() представляют время и дату в виде символьной строки длиной 26 символов фиксированного формата. Функция strftime() также представляет время и дату в виде символьной строки, но формат определяется пользователем.

Более подробную информацию о часах и таймерах можно получить в гл. Часы и таймеры.

1.7 Операции ввода/вывода

Базовые операции ввода/вывода, а также асинхронный ввода/вывода реализован в ос2000 в соответствии со стандартом POSIX, который обеспечивает единообразный доступ к устройствам различных типов.

Потоки ввода/вывода и форматированный ввод/вывод реализован в соответствии со стандартом С и описаны в главе Библиотеки стандарта С.

1.7.1 Устройства и файлы

Устройства и файлы являются основными понятиями системы ввода/вывода ос2000. Устройства делятся на физические (например, последовательный и параллельный порт, диск) и логические (например, программные каналы, сокеты).

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

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

Программный канал представляет собой логическое устройство, предназначенное для передачи данных между потоками управления. Данные, записанные в программный канал, считываются оттуда в порядке поступления (First-In-First-Out, первым записан - первым прочитан). Существует 2 типа программных каналов: именованные и неименованные. Первым соответствуют файлы типа FIFO, вторым - файлы типа PIPE.

1.7.2 Базовые операции ввода и вывода

Для выполнения базовых операций предназначены следующие функции:

close() закрытие файла,

creat() создание файла,

dup(), dup2() дублирование дескриптора файла,

fcntl(), ioctl() управление файлом,

lseek() позиционирование файла,

open() открытие файла,

read() чтение файла,

write() запись в файл.

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

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

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

После открытия текущая позиция устанавливается на начало файла. После успешного завершения операции read() или write() текущая позиция в файле продвигается вперед на количество прочитанных или записанных байтов. Изменить текущую позицию в файле можно функцией lseek().

Непредусмотренная стандартом функция ioctl() позволяет использовать особенности аппаратуры.

1.7.3 Асинхронные операции ввода и вывода

Для выполнения асинхронных операций ввода/вывода предназначены следующие функции.

aio_read() асинхронное чтение;

aio_write() асинхронная запись;

lio_listio() запуск операций асинхронного ввода/вывода по списку.

aio_suspend() ожидание завершения операции асинхронного ввода/вывода;

aio_error() опрос кода ошибки асинхронной операции ввода/вывода;

aio_return() опрос кода возврата асинхронной операции ввода/вывода;

aio_cancel() отмена запроса на асинхронный ввод/вывод;

aio_fsync() асинхронная операция синхронизации файла (обеспечение целостности файла или данных);

Функций read() или write() приостанавливают выполнение потока управления до завершения операции. Асинхронные операции ввода/вывода (aio_read(), aio_write(), lio_listio()) позволяют продолжить выполнение потока управления "параллельно" с операцией ввода/вывода.

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

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

1.7.4 Целостность файлов и данных

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