Особенности задач потоков и процессов в СРВ




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


Плюсы потоков:

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

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

Минусы потоков:

- Потоки, прежде всего, как правило, не подгружаются динамически (теоретически это возможно, не нерационально). Чтобы добавить новый поток, надо изменить исходный текст и перекомпилировать его. Вообще говоря, система получается довольно-таки жесткой. Если мы работаем с процессами, то у них очень легко реализуется их динамическое подключение, а, значит, в процессе работы мы можем подключать и отключать процессы, получая достаточно гибкую систему. Кроме того, такой подход позволяет в ряде случаев обойтись минимальными аппаратными затрами (поскольку можно выгружать процессы), а для таких систем это очень важно. Кроме того, поскольку все модульное, то можно использовать уже готовые наработки или продукты других кампаний. Это существенно сокращает время разработки. (Например, работа с таймером уже написана для предыдущей системы -- модуль для новой системы можно не переписывать, а подключить). -- С одной стороны, общие области кода и данных -- вроде бы, удобно. С другой стороны, при этом очень вероятна ситуация, что один поток испортит данные другого. Напртимер, мы записываем данные четко в какой-то сектор диска: write sector N, где N -- номер сектора; У нас два потока -- один, например, пишет в пятый сектор, другой -- в седьмой. Подготовленны данные, с числом сектора 5 -- память ячеки процессора. Пусть тут приходит прерывание от более приоритетного потока (например, тот, который пишет в десять). Данные, которые должны были идти в сектор пять, запишутся уже поверх записанных в сектор 10:(Такие варианты могут возникать достаточно часто, и интуитивно они ловятся программистом только достаточно опытным. Соответственно в процессах такие ситуации невозможны -- любая попытка залезть не в свою область вызывает прерывание:) Вопрос, что использовать, процессы или потоки. определяется разработчиком, исходя из условий поставленной задачи.

Основые свойства задач.

Прежде всего, вся информация о задачах для ОС хранится в унифицированной структуре данных Task Control Block (TCB -- управляющем блоке). Абсолютно все параметры: имя задачи, ее номер, статус, приоритет, ссылка на очереди сообщений, границы стеков, состояния регистров, -- полный набор данных, который позволяет запустить задачу с того же самого места. Вот этот набор данных, который позволяет запустить задачу с места остановки, называют контекстом задачи. Его, как правило, тоже записывают в TCB, и это не только состояния регистров в момент прерывания, а еще и дополнительные данные, вроде счетчкика команд, указатели стеков и т.д. Функции остановки выполняет планировщик задач. Переключение между задачами с сохранением контекста -- это основной механизм работы ОС РВ и многопроцессорных систем.

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

В СРВ обязательным элементом является наличие так называемой "пустой задачи" -- она запускается при инициализации системы, а также в те моменты, когда нет готовых к выполнению задач. (обычно это пустой бесконечный цикл с условием остановки). Это дает синхронизацию, а, во-вторых, нет необходимости каким-либо образом модернизировать работу планировщика для раличения между собой пауз и работающих задач. Для СРВ важна возможность многократного запуска задачи. Скажем, два различных физически, но по сути одинаковых датчика температуры должны обрабатываться одинаково -- не писать же две разных программы. Для каждой запущенной копии задачи нужно писать свой TCB. Кроме этого, запрещено использовать файлы с зарезервированными именами в тексте программы, и важно обращать внимание на работу с глобальными ресурасами -- разные копии могут мешать друг другу, если имена глобальных переменных одинаковые. Также важно свойство реинтеррабельности (повторная входимость) -- возможность вызова себя самой. Чаще всего этому мешает использование глобальных переменных, и, потому что нет реинтеррабельности, не используется (как ОС) DOS.

Лекция 3

(17/09/2012)

Планирование задач.

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

Рис. 1 "Циклический алгоритм диспетчера задач"

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

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

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

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

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

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

 

Вторым стандартным методом является планирование в режиме разделения времени (time-slicing, time-sharing):

Берется определенный временной интервал. Чаще всего, его берут кратным 1 мс. Задача работает в течении выделенного временного интервала. Если за это время задача не выполнилась, контекст задачи сохраняется и управление передается готовой задаче с наивысшим приоритетом. Из готовых задач должна быть предварительно сформирована очередь.

Алгоритм имеет целый ряд "подводных камней":

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

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

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

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

Одним из популярных алгоритмов, EDF (Earliest Deadline First), заключается в следующем:

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

Пример:

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

Синхронизация задач.

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

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

message, mail box, signal, event, proxy.

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

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

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

Разделяемые ресурсы.

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

§ считать все в буфер какого-то драйвера

§ продолжить работу предыдущей программы, а данные обрабатывать параллельно

Также распространенная ошибки, связанная с прерываниями:

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

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

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

Семафоры и мьютексы.

 

Лекция 4

Ошибки, которые являются следствием гонок, характерны для двух случаев:

· Обращение нескольких задач к общему ресурсу

· Гонки, которые возникают как следствие совпадения нескольких условий

Наиболее часто возникают в ОС при использовании алгоритмов с вытеснением.

Для избежания ошибок:

· стараются не использовать алгоритмы с вытеснением. Такой подход возможен не всегда.

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

· на время доступа к разделяемым ресурсам запрещают прерывания. Это тоже не всегда возможно.

· Используют семафоры

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

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

Например: принт-сервер (см. рис. "Задачи принт-сервера")

Задачи принт-сервера

Таким образом можно регулировать доступ к общему ресурсу некоторого количества задач.

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

Чаще всего проблемы возникают с потоками в рамках одного программного модуляю

В Windows предусмотрено управление мьютексами специальной функцией:

CriticalSection

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

Наиболее плохим последствием неверной синхронизации является "смертельный захват" (зависание ОС)

Например, задача 1 захватывает ресурс клавиатуры и ждет, пока освободится дисплей. Дисплей занят задачей 2, но для ее завершения нужно обратиться к клавиатуре.

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

Использование мьютексов чревато появлением инверсии приоритетов.

Пусть есть 3 задачи: 1-ая имеет высший приоритет, третья -- низший. Высокоприоритетная и среднеприоритетная задачи запланированы по прерыванию внешнего события. Значит, задача 3 спокойно захватывает семафор и начинает выполнение. Задача 3 выполняется; задача 1 получает прерывание и, как более высокоприоритетная, заблокирует задачу 3. Но задача 3 не освободила семафор -- следовательно, задача 1 тоже заблокируется -- следовательно, две задачи заблокированы -- следовательно, управление получит оставшаяся задача (2). Получаем, что высокоприоритетная задача не выполняется, т.к. нужный ей ресурс занимает низкоприоритетная.

Еще одной проблемой является синхронизация с внешними событиями. Чаще всего для этого используются прерывания.

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

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

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

Очень много ограничений на обработки прерываний накладывает аппаратная платформа.

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

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

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

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

Также используются навигационные приемники ГЛОНАСС и GPS, имеющие высокую точность.

Особенности тестирования:

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

Тесты для таких систем должны быть очень тщательно проработаны и обязательно "прогонять" худшие случаи.

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

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

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

Также кэш может сильно влиять на показатели быстродействия (я бы добавил, что и cache, и cash -- тупое прим. от себя %)) Наиболее сложно тестировать системы.

материал выше -- для первой контрольной


Лекция 5

1 окт 2012

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

Простейший пример:

Есть три переключателя, которые нужно опрашивать не реже 10 раз в секунду. В зависимости от их положения включать или выключать насос.

[рис. 1] -- потерял

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

Теперь пусть нам нужно производить тот же опрос строго 10 раз в секунду. Такие программы, чаще всего, пишутся на Си. Как известно, в Си есть функция установки какой-либо переменной в состояние, зависящее от таймера (по таймеру). Введем некоторую переменную t, которая будет устанавливаться в единицу каждые 100 мс. В этом случае придется модифицировать алгоритм:

[рис.2] -- потерял

-- вот такой алгоритм, в общем-то, как оценить? будет он успевать работать или нет? упростим его, вынесем определенную часть в подпрограмму:

[рис.3] -- потерял

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

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

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

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

По усливию 100 мс -- переключатели, 200 мс -- насос. Придется вводить еще одну переменную

[рис.4] -- первым запустим короткий цикл (100 мс -- задача 1 -- задача опр./упр. ) Безупречно работавший ранее алгоритм может стать некорректным даже при незначительных изменениях.

Например, если увеличить число счетчиков до тысячи в первом случае.

Например, если нам нужно просчитывать и специально выбирать процессы.

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

Например, подключение еще одного дополнительного датчика.

Зато время выполнения написанных программ, особенно при нынешних интерпретаторах -- даже не требуют ассемблерных вставок.


Лекция 6

15/10/2012

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

Для KURT в ядро стандартного Linux внесено минимальное количество изменений. Самое главное: в этом проекте реализовано сразу 2 режима работы: Normal Mode и Real Time Mode. И можно переключаться с одного режима на другой. В некоторых источниках kurt называют планировщиком задач реального времени. Переключения из режима в режим могут происходить по событию или в заданных местах программы. Если работаем в режиме Normal -- стандартная логика, когда переходим в RealTime -- стандартная логика приостанавливается, и выполняется только задача реального времени, а потом продолжаем в Normal.

Если использовать только KURT, то время переключения не превышает 10мс, а если еще добавить UTIME, то можно уменьшить время переключения до 1мс.

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

set.rtparams // с помощью этой функции процесс переводится в режим выполнения в реальном времени

get num rtprocs // -- это установка идентификаторов процессов как таковых; чтобы их отличать друг от друга

rt suspend // -- приостановка процесса реального времени

get rt stats // -- позволяет установить процессу статус

// У планировщика задач СРВ существует таблица, по сути своей с приоритетами

Такой подход, в общем-то, для программирования предельно удобен и в основном используется для видео и аудио-процессов (мягкое реальное время). Для жесткого реального времени -- RTLinux.

Здесь совершенно другая идеология. Есть ядро реального времени. Базовый набор "linux-возможностей" запускается, как задача с более низким приоритетом. Все прерывания обрабатываются ядром реального времени. Для того, чтобы не было всяких там "смертельных захватов", имеется специальный драйвер, представляющий собой систему управления прерывания. Если не выполняется задача реального времени, то управленение передается стандартной конфигурации Linux. Все прерывания без исключения обрабатываются ядром реального времени. Прерывание анализируется и по особым признакам определяется, относится ли оно к реальному времени или нет -- драйвер их классифицирует на две группы. Прерывания реального времени обрабатываются ядром. Если нет -- задача передается в "базовую часть" Linux. Ядро реального времени никогда не ждет освобождения контекстов. // тут написано, каким образом. Для обмена данными между двумя этими частями ОС чаще всего используют разделяемые области памяти и подход "псевдоустройств" (задачи можно описывать несуществующими физическими устройствами). На ядро реального времени возлагается минимум задач: обработка прерываний и планирование задач реального времени. Все остальные системные задачи решает стандартное ядро Linux. С точки зрения модульности (чтобы иметь расширяемость) все процессы реального времени описываются как подгружаемые модули. Получается, что любую задачу реального времени выполняет как ядро релаьного времени, так и обыкновенные Linux-приложения. Если у нас речь идет о получении внешних каких-нибудь данных, то ядро реального времени фактически будет считывать их и помещать в очередь для стандартной части Linux и там будет происходить обработка этих данных. Этот подход теперь считается стандартным и для других ОС. Соответственно, в зависимости от того, какая задача, выбирается конкретная реализация ядра.

Очень многие крупные фирмы используют Linux для систем реального времени -- там удобная работа с API-интерфейсов. Кроме того, все это прекрасно отдокументировано на сегодняшний день. Лучше всего подходит для систем обработки в режиме реального времени аудио и видео, а также используется в системах промышленной реализации (но там RTL). iOS и Macintosh на основе Unix тоже.



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2019-04-30 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: