Home News

Процессы, потоки, задачи | Системы реального времени

05.09.2018

видео Процессы, потоки, задачи | Системы реального времени

Процесс постановки задач перед воплощением. Теория и конкретный пример

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



Процессы

Термин «процесс» впервые появился при разработке операционной системы Multix и имеет несколько определений, которые используются в зависимости от контекста, согласно которым процесс — это:

программа на стадии выполнения «объект», которому выделено процессорное время асинхронная работа

Примером контекстной зависимости применения термина «процесс» является ОС Android. В этой системе процесс и приложение не являются тесно связанными сущностями: программы для андроид могут выглядеть выполняющимися при отсутствии процесса; несколько программ могут использовать один процесс; либо одно приложение может использовать несколько процессов; процесс может присутствовать в системе даже если его приложение бездействует. Отметим, что в этом нет никаких противоречий с теорией операционных систем — объектные библиотеки и загружаемые модули тоже являются процессами.


Урок 225. Задачи на поток вектора напряженности электрического поля

Для описания состояний процессов используется несколько моделей. Самая простая — модель трех состояний (рис. 1). Она определяет следующие состояния процесса:

состояния выполнения состояния ожидания состояния готовности

Рис. 1. Модель трех состояний


ПОТОК. Инструкция к абсолютной продуктивности

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

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

Готовность — это тоже пассивное состояние, процесс тоже заблокирован, но в отличие от состояния ожидания, он заблокирован не по внутренним причинам (ведь ожидание ввода данных — это внутренняя, «личная» проблема процесса — он может ведь и не ожидать ввода данных и свободно выполняться — никто ему не мешает), а по внешним, независящим от процесса, причинам.

Когда процесс может перейти в состояние готовности ? Предположим, что наш процесс выполнялся до ввода данных. До этого момента он был в состоянии выполнения , потом перешел в состояние ожидания — ему нужно подождать, пока мы введем нужную для работы процесса информацию. Затем процесс хотел уже перейти в состояние выполнения, так как все необходимые ему данные уже введены, но не тут-то было: так как он не единственный процесс в системе, пока он был в состоянии ожидания, его «место под солнцем» занято — процессор выполняет другой процесс. Тогда нашему процессу ничего не остается как перейти в состояние готовности: ждать ему нечего, а выполняться он тоже не может.

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

Из состояния выполнения процесс может перейти либо в состояние ожидания, либо в состояние готовности. Почему процесс может оказаться в состоянии ожидания, мы уже знаем — ему просто нужны дополнительные данные или он ожидает освобождения какого-нибудь ресурса, например, устройства или файла. В состояние готовности процесс может перейти, если во время его выполнения, квант времени выполнения «вышел». Другими словами, в операционной системе есть специальная программа — планировщик , которая следит за тем, чтобы все процессы выполнялись отведенное им время. Например, у нас есть три процесса. Один из них находится в состоянии выполнения. Два других — в состоянии готовности. Планировщик следит за временем выполнения первого процесса, если «время вышло», планировщик переводит процесс 1 в состояние готовности, а процесс 2 — в состояние выполнения. Затем, когда, время отведенное, на выполнение процесса 2, закончится, процесс 2 перейдет в состояние готовности, а процесс 3 — в состояние выполнения.

Более сложная модель — это модель, состоящая из пяти состояний. В этой модели появилось два дополнительных состояния: рождение процесса и смерть процесса .

Рождение процесса — это пассивное состояние, когда самого процесса еще нет, но уже готова структура для появления процесса.

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

Диаграмма модели пяти состояний представлена на рис. 2.

Рис.5. Модель пяти состояний

В ОС РВ время перехода процесса из одного состояния в другое должно быть детерминированно. Функции контроля за временем (deadline) возлагаются на планировщика (о планировании будет сказано далее).

Операции над процессами

Над процессами можно производить следующие операции:

Создание процесса — это переход из состояния рождения в состояние готовности Уничтожение процесса — это переход из состояния выполнения в состояние смерти Восстановление процесса — переход из состояния готовности в состояние выполнения Изменение приоритета процесса — переход из выполнения в готовность Блокирование процесса — переход в состояние ожидания из состояния выполнения Пробуждение процесса — переход из состояния ожидания в состояние готовности Запуск процесса (или его выбор) — переход из состояния готовности в состояние выполнения

Для создания процесса операционной системе нужно:

Присвоить процессу имя Добавить информацию о процессе в список процессов Определить приоритет процесса Сформировать блок управления процессом Предоставить процессу нужные ему ресурсы

Иерархия процессов

Процесс не может взяться из ниоткуда: его обязательно должен запустить какой-то процесс. Процесс, запущенный другим процессом, называется дочерним (child) процессом или потомком . Процесс, который запустил новый процесс называется родительским (parent), родителем или просто — предком . У каждого процесса есть два атрибута — PID (Process ID) - идентификатор процесса и PPID (Parent Process ID) — идентификатор родительского процесса.

Процессы создают иерархию в виде дерева. Самым «главным» предком, то есть процессом, стоящим на вершине этого дерева, является процесс init (PID=1).

Потоки

Концепция процесса, пришедшая из мира UNIX, плохо реализуется в многозадачной системе, поскольку процесс имеет тяжелый контекст. Возникает понятие потока (thread) , который понимается как подпроцесс, или легковесный процесс (light-weight process) , выполняющийся в контексте полноценного процесса.

С помощью процессов можно организовать параллельное выполнение программ. Для этого процессы клонируются вызовами fork() или exec(), а затем между ними организуется взаимодействие средствами IPC. Это довольно дорогостоящий в отношении ресурсов способ.

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

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

Если рассматривать эти характеристики независимо друг от друга (как это принято в современной теории ОС), то:

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

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

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

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

Преимущества многопоточности

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

Улучшенная реакция приложения — любая программа, содержащая много не зависящих друг от друга действий, может быть перепроектирована так, чтобы каждое действие выполнялось в отдельном потоке. Например, пользователь многопоточного интерфейса не должен ждать завершения одной задачи, чтобы начать выполнение другой. Более эффективное использование мультипроцессирования — как правило, приложения, реализующие параллелизм через потоки, не должны учитывать число доступных процессоров. Производительность приложения равномерно увеличивается при наличии дополнительных процессоров. Численные алгоритмы и приложения с высокой степенью параллелизма, например перемножение матриц, могут выполняться намного быстрее. Улучшенная структура программы — некоторые программы более эффективно представляются в виде нескольких независимых или полуавтономных единиц, чем в виде единой монолитной программы. Многопоточные программы легче адаптировать к изменениям требований пользователя. Эффективное использование ресурсов системы — программы, использующие два или более процессов, которые имеют доступ к общим данным через разделяемую память, содержат более одного потока управления. При этом каждый процесс имеет полное адресное пространство и состояние в операционной системе. Стоимость создания и поддержания большого количества служебной информации делает каждый процесс более затратным, чем поток. Кроме того, разделение работы между процессами может потребовать от программиста значительных усилий, чтобы обеспечить связь между потоками в различных процессах или синхронизировать их действия.

Задачи

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

ЗАДАЧА (TASK) — блок программного кода, ответственный за обработку тех или иных событий, возникающих на объекте управления.

Задача может быть «оформлена» в виде:

Отдельного процесса Потока управления внутри процесса (нити, легковесного процесса) Обработчика прерывания/подпрограммы

РАБОТА ЗАДАЧИ (JOB) — процесс исполнения блока программного кода в ходе обработки события.

Каждая работа задачи характеризуется следующими временнЫми параметрами:

r (Release Time) — момент времени, когда задача становится готовой к исполнению (например, процесс переходит в состояние готовности) d (Absolute Deadline) — абсолютный крайний срок, момент времени, к которому задача должна завершить очередную работу. s (Start Time) — момент времени, когда задача начала исполняться на процессоре с (Complition Time) — момент времени, когда задача закончила работу, обработав событие D (Relative Deadline) — относительный крайний срок. D = d — r e (Execution Time) — время исполнения задачи при выполнении ею очередной работы. e = c — s R (Response Time) — время отклика. R = c — r

Диаграмма ниже иллюстрирует эти параметры:

r s c d * |---------------| | | | | | | | | * --+---+---+---+---+---+---+---+---+---+---+---+---+---+----> t (у.е.) 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Приведенная на этой диаграмме работа задачи имеет следующие параметры:

r = 2 d = 11 s = 5 с = 9 D = 11 — 2 = 9 e = 9 — 5 = 4 R = 9 -2 = 7

Упомянутые параметры определяются следующим:

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

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

Опять отметим, что в случае процессоров с конвейерами и кэшами такие измерения не дают гарантии, что будет измерено именно МАКСИМАЛЬНОЕ время исполнения того или иного кода (???). Наконец, системы, использующие механизмы подкачки страниц, также являются менее предсказуемыми и поэтому считается, что такого рода механизмы являются «врагами» систем реального времени. Недаром в различного рода стандартах, касающихся СРВ, предусмотрены средства блокировки страниц памяти.

Резюме

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

Постоянный адрес этой страницы:

rss