Лекция 2. Процессы, потоки, задачи

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

Процессы

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

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

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

1. состояния выполнения
2. состояния ожидания
3. состояния готовности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потоки

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

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

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

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

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

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

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

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

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

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

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

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

Задачи

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

ЗАДАЧА (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 подхода.
  • Первый заключается в подсчете количества тактов процессора, необходимых на выполнение той или иной задачи.
    Отметим, что такой подсчет чрезвычайно усложняется в случае, если процессор содержит механизмы типа конвейеров и всевозможных кэшей.
  • Второй подход более прост и состоит в том, что времена исполнения непосредственно измеряются.
    Опять отметим, что в случае процессоров с конвейерами и кэшами такие измерения не дают гарантии, что будет измерено именно МАКСИМАЛЬНОЕ время исполнения того или иного кода (???). Наконец, системы, использующие механизмы подкачки страниц, также являются менее предсказуемыми и поэтому считается, что такого рода механизмы являются «врагами» систем реального времени. Недаром в различного рода стандартах, касающихся СРВ, предусмотрены средства блокировки страниц памяти.

Резюме

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

CC-BY-CA Анатольев А.Г., 31.01.2012