Операционная система реального времени QNX. курсовая работа. Основные принципы, которые позволяют создавать операционные системы реального времени
Скачать 3.97 Mb.
|
2.4 Связь между процессами в сети В системе QNX приложение может взаимодействовать с процессом, выполняющимся на другом компьютере сети, так же как с процессом, выполняющемся на своем компьютере. В самом деле, с точки зрения приложения нет никакой разницы между локальными и удаленными ресурсами. Такая высокая степень прозрачности обеспечивается благодаря использованию виртуальных каналов, которые являются путями, по которым Сетевой администратор передает сообщения и сигналы по всей сети. Виртуальные каналы (ВК) способствуют эффективному использованию ресурсов во всей сети QNX по нескольким причинам: при создании виртуального канала имеется возможность задать работу с сообщениями определенной длины: это означает, что вы можете распределить ресурсы для обработки сообщения. Тем не менее, если потребуется послать сообщение, длина которого превышает максимально заданную, виртуальный канал автоматически изменит установленный максимальный размер буфера в соответствии с длиной передаваемого сообщения; если два процесса, находящиеся на разных узлах, взаимодействуют между собой более, чем через один виртуальный канал, виртуальные каналы разделяются во времени, так как между процессами существует только один реальный виртуальный канал. Эта ситуация часто возникает, когда процесс обращается к нескольким файлам удаленной файловой системы; если процесс подключается к существующему разделенному виртуальному каналу и запрашивает размер буфера больший, чем тот, который используется в данное время, размер буфера автоматически увеличивается; когда процесс завершается, все связанные с ним виртуальные каналы освобождаются. операционный система реальный время 2.4.1 Виртуальные процессы Процесс-отправитель отвечает за установку виртуального канала между собой и процессом, с которым устанавливается связь. Для этого процесс-отправитель обычно вызывает функцию qnx_vc_attach(). При этом, кроме создания виртуального канала, на каждом конце канала создается виртуальный процесс с идентификатором - VID. Для каждого процесса на обоих концах виртуального канала VID представляет собой идентификатор удаленного процесса, с которым устанавливается связь. Процессы связываются друг с другом посредством VID. Например, на рисунке 6 виртуальный канал соединяет процессы PID1 и PID2. На узле 20, где находится PID1, VID2 представляет PID2. На узле 40, где находится PID2, VID1 представляет PID1. PID1 и PID2 могут относиться к виртуальному процессу на своем узле, как к любому другому локальному процессу: посылать и принимать сообщения, выдавать сигналы, ожидать и т.п. Так, например, PID1 может послать сообщение к VID на своем конце виртуального канала, которое будет передано по сети к VID на другом конце виртуального канала, представляющему там PID1. Там VID1 передает сообщение PID2. Рисунок 6. Связь в сети посредством виртуальных каналов. Каждый VID обеспечивает соединение, которое содержит следующую информацию: локальный pid; удаленный pid; удаленный nid (идентификатор узла); удаленный vid. Если приложению требуется, например, получить доступ к удаленному ресурсу ввода/вывода, то виртуальный канал создается вызываемой библиотечной функцией open(). Приложения непосредственно не участвуют в создании или использовании виртуального канала. Если приложение определяет нахождение обслуживающего его процесса с помощью функции qnx_name_locate(), то виртуальный канал создается автоматически при вызове функции. Для приложения виртуальный канал просто отождествляется с PID. Существует несколько причин, по которым процесс не может осуществлять связь по установленным виртуальным каналам, а именно: произошло отключение питания компьютера, на котором выполняется процесс; был отсоединен кабель сети от компьютера; был завершен удаленный процесс, с которым установлена связь. Любая из этих причин может препятствовать передаче сообщений по виртуальному каналу. Необходимо фиксировать эти ситуации для выполнения приложением необходимых действий с целью корректного завершения работы, в противном случае, отдельные ресурсы могут оказаться постоянно занятыми. На каждом узле Администратор процессов проверяет целостность виртуального канала. Это делается следующим образом: Каждый раз при успешной передаче по виртуальному каналу, обновляется временная метка, связанная с данным виртуальным каналом, для фиксации времени последней активности; Через интервалы времени, устанавливаемые при инсталляции, Администратор процессов просматривает каждый виртуальный канал. В том случае, если в виртуальном канале нет активности, Администратор процессов посылает сетевой пакет проверки целостности канала Администратору процессов другого узла; В том случае, если ответ не получен, или зафиксирован сбой, виртуальный канал помечается, как сбойный. Далее предпринимается ряд действий, определенных при инсталляции для восстановления связи; Если попытки восстановления закончились безуспешно, виртуальный канал "отключается". Все процессы, блокированные на данном канале, переходят в состояние ГOTOB (READY). (Процессы анализируют возвращаемый код сбоя виртуального канала.) Для управления параметрами, связанными с проверкой целостности виртуального канала, используется утилита netpoll. 2.5 Планирование процессов Планировщик ядра запускается в следующих случаях: после разблокировки процесса; по истечении временного кванта для выполняющегося процесса; после выгрузки выполняющегося процесса. В системе QNX каждому процессу присваивается приоритет. Планировщик выбирает для выполнения процессы, находящиеся в состоянии ГОТОВ, в соответствии с их приоритетами. (Центральный процессор может использовать только процесс, находящийся в состоянии ГОТОВ.) Для выполнения выбирается процесс, имеющий наивысший приоритет. Рисунок 7. Пример выполнения процессов в соответствии с приоритетом. Процессам присваиваются приоритеты в диапазоне от 0 (низший) до 31 (высший). По умолчанию процесс наследует приоритет от породившего его процесса; обычно он равен 10 для приложений, запускаемых из интерпретатора Shell. Таблица 9. Работа с приоритетами процессов в QNX.
2.5.1 Методы планирования Для удовлетворения потребностей разных приложений в системе QNX реализованы три метода планирования: планирование по принципу простой очереди (первым пришел_ первым обслужен); круговой метод планирования; адаптивное планирование. Каждый процесс в системе может выполняться, используя любой из этих методов. Они эффективны применительно к одному процессу, а не ко всем процессам на узле. Данные методы планирования используются только тогда, когда два или более процессов, разделяющих один и тот же приоритет, находятся в состоянии ГОТОВ (то есть процессы непосредственно конкурируют друг с другом). Если в состояние ГОТОВ переходит процесс, имеющий более высокий приоритет, он немедленно выгружает все процессы с меньшим приоритетом. Рисунок 8. Очередь процессов. Метод планирования наследуется от порождающего процесса, однако, он может быть изменен Таблица 10. Функции для работы с планированием процессов в QNX.
Планирование по принципу простой очереди. При планировании по принципу простой очереди процесс, выбранный для выполнения, продолжает работать до тех пор, пока он: не передаст управление сам (например, блокируется); не будет снят с выполнения (выгружен из памяти) процессом с более высоким приоритетом. Два процесса, выполняющихся с одинаковыми приоритетами, могут использовать планирование по принципу простой очереди во избежание взаимных "столкновений" при обращении к разделяемому ресурсу. Например, если они разделяют сегмент памяти, то каждый из двух процессов может обновлять сегмент без использования некоторых форм семафоров. Круговой метод планирования. При круговом методе планирования процесс, выбранный для выполнения, продолжает работать до тех пор, пока он: не передаст управления сам; не будет снят с выполнения (выгружен из памяти) процессом с более высоким приоритетом; не истечет его квант времени (timeslice). Квант времени - это единица временного интервала, закрепляемая за каждым процессом. По истечении кванта времени, процесс выгружается, и управление передается процессу, находящемуся на том же уровне приоритета в состоянии ГОТОВ. Квант времени равен 100 миллисекундам. За исключением квантования времени круговой метод планирования идентичен планированию по принципу простой очереди. Адаптивное планирование. При адаптивном планировании процесс ведет себя следующим образом: по истечении кванта времени (при условии, что процесс не блокировался), его приоритет уменьшается на 1, если другой процесс с таким же приоритетом находится в состоянии ГОТОВ. Это называется понижением приоритета; если процесс с пониженным приоритетом не выполняется в течение одной секунды, его приоритет повышается на 1 (процесс никогда не может повысить приоритет выше начального); если процесс блокируется, ему немедленно возвращается начальный приоритет. Адаптивное планирование можно использовать в среде, где интенсивно выполняющиеся фоновые процессы разделяют компьютер с пользовательскими процессами, работающими в диалоговом режиме. Адаптивное планирование обеспечит интенсивно выполняющимся процессам достаточный доступ к центральному процессору и сохранит малое время отклика для процессов, работающих в диалоговом режиме. Программы, запущенные из интерпретатора Shell, используют по умолчанию адаптивный метод планирования. Рисунок 9. Адаптивное планирование. Приоритет, управляемый клиентом. В системе QNX в большинстве случаев взаимодействия между процессами используется модель "клиент-сервер". Серверы (обслуживающие процессы) выполняют некоторые сервисные функции, а клиенты (обслуживаемые процессы) посылают сообщения к этим серверам, запрашивая обслуживание. В общем случае серверы более "надежны и долговечны", чем клиенты Обычно количество клиентов превосходит количество серверов. В результате сервер, как правило, выполняется с приоритетом, превосходящим приоритеты всех своих клиентов. При этом может использоваться любой из описанных выше методов планирования, однако, круговой метод предпочтительнее. Если низкоприоритетный клиент посылает сообщение серверу, то по умолчанию его запрос будет обрабатываться сервером с более высоким приоритетом. Это косвенно повышает приоритет клиента, так как именно запрос клиента заставил работать сервер. Если сервер работает на коротком отрезке времени, то этим можно пренебречь. Если же сервер работает более длительное время, то низкоприоритетный клиент может негативно влиять на другие процессы, имеющие приоритеты выше, чем у клиента, но ниже, чем у сервера. Для разрешения этой проблемы, серверу можно устанавливать приоритет, соответствующий приоритету клиента, который послал ему сообщение. Когда сервер получает сообщение, его приоритет становится равным приоритету клиента. Обратите внимание на то, что меняется только приоритет, а метод планирования остается тем же. Если при работе сервера поступает другое сообщение, то приоритет сервера увеличивается в том случае, если приоритет нового клиента окажется выше приоритета сервера. В результате новый клиент "выравнивает" приоритет сервера под свой, позволяя ему закончить выполнение текущего запроса и перейти к выполнению вновь поступившего. Если этого не сделать, то приоритет нового клиента понизился бы, так как он заблокировался бы на низкоприоритетном сервере. При выборе для сервера клиентов, управляемых приоритетами следует позаботиться о том, чтобы сообщения доставлялись в порядке приоритетов (а не в порядке времени поступления). Для установки приоритета, управляемого клиентом, воспользуйтесь функцией qnx_pflags(). 2.6 Работа в реальном времени Как бы нам этого не хотелось, но компьютер не может иметь бесконечное быстродействие. В системе реального времени крайне важно, использовать все циклы работы центрального процессора. Также важно минимизировать интервал времени между возникновением внешнего события и фактическим началом выполнения программы, реализующей ответную реакцию на это событие. Это время называется задержкой или временем ожидания (latency). В системе QNX можно определить несколько типов задержки. Задержка прерывания - это интервал времени между приемом аппаратного прерывания и началом выполнения первой команды обработчика данного прерывания. В системе QNX все прерывания открыты все время, поэтому задержка прерывания обычно незначительна. Но некоторые критические программы требуют, чтобы на время их выполнения прерывания были закрыты. Максимальное время закрытия прерывания обычно определяет худший случай задержки прерывания; следует отметить, что в системе QNX это время очень мало. На рисунке 10 представлена диаграмма обработки аппаратного прерывания соответствующим обработчиком прерываний. Обработчик прерываний либо просто возвращает управление процессу, либо возвращает управление и вызывает "срабатывание" proxy. Рисунок 10. Обработчик прерываний нормально отрабатывает. Времена даны для процессора 386, 20 МГц в защищенном режиме. На диаграмме, приведенной выше, задержка прерывания (Til) представляет собой минимальную задержку, для случая, когда во время возникновения прерывания все прерывания были открыты. В худшем случае задержка равна этому времени плюс наибольшее время работы процесса QNX, когда прерывания закрыты. В некоторых случаях низкоприоритетный обработчик аппаратных прерываний должен планировать выполнение высокоприоритетных процессов. В этом случае обработчик прерываний возвращает управление и вызывает срабатывание proxy. Это и есть вторая форма задержки - задержка планирования, которую мы рассмотрим ниже. Задержка планирования - это время между завершением работы обработчика прерываний и началом выполнения первой команды управляющего процесса. Обычно это интервал времени, который требуется для сохранения контекста процесса, выполняющегося в данный момент времени, и восстановления контекста управляющего процесса. Несмотря на то, что это время больше задержки прерывания, оно также остается небольшим в системе QNX. Рисунок 11. Обработчик прерываний завершает работу и инициирует "срабатывание" proxy. Времена даны для процессора 386, 20 МГц в защищенном режиме. Важно заметить, что большинство обработчиков прерываний завершают работу без инициирования "срабатывания" proxy. В большенстве случаев обработчик прерываний сам справляется со всеми аппаратными событиями. Выдача proxy для подключения управляющего процесса более высокого уровня происходит только при возникновении особых событий. Например, обработчик прерываний драйвера устройства с последовательным интерфейсом, передающий один байт данных аппаратуре, должен на каждое принятое прерывание на передачу запустить высокоуровневый процесс (Dev) только в том случае, если выходной буфер в итоге окажется пустым. Поскольку архитектура микрокомпьютера позволяет присваивать аппаратным прерываниям приоритеты, то высокоуровневые прерывания могут вытеснять низкоуровневые. Этот механизм полностью поддерживается в системе QNX. В предыдущих примерах описаны простейшие и наиболее обычные ситуации, когда поступает только одно прерывание. Практически такие же временные характеристики имеют прерывания с высшим приоритетом. При расчете наихудших временных показателей для низкоприоритетных прерываний следует учитывать время обработки всех высокоприоритетных прерываний, так как в системе QNX высокоприоритетные прерывания вытесняют низкоприоритетные. Рисунок 12. Выполняется процесс А. Прерывание IRQx запускает обработчик прерываний Intx, который вытесняется прерыванием IRQy и его обработчиком Inty. Inty вызывает "срабатывание" proxy, которое запускает процесс В, а Intx вызывает "срабатывание" proxy, запускающее процесс С. Список использованных источников Статья «QNX – система реального времени» http://systemnews.com.ru/?mod=art&part=qnx&id=002 Статья «QNX» http://systemnews.com.ru/?mod=art&part=qnx&id=003 Статья «Все операционной системе QNX» http://www.ossite.ru/index.php?dir=os/qnx/&file=qnx Электронный учебник по работе с операционной системой QNX. QNX 4. Руководство пользователя. Гордеев А.В. Операционные системы. Санкт Петербург, Питер, 2006 год. |