Понятие процесса, его модель. Процессы и потоки в системе UNIX.

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

1. понятие процесса и модель процесса

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

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

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

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

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

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

2. Создание процесса

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

1) Инициализация системы. При загрузке ОС создается несколько процессов. Высокоприоритетные: взаимодействие с пользователем и заданная работа. Фоновые: почта, запросы на web-страницы, новости, вывод на печать, называются демонами. В больших системах десятки демонов. В UNIX : команда ps выводит список запущенных процессов. В Windows 2000 CTRL-ALT-DEL вызывает диспетчер задач.

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

3) Запрос пользователя на создание процесса. В интерактивных системах пользователь запускает команду с командной строки или щелкая по пиктограмме. Результат – создание нового процесса и запуск в нем программы. Например, когда на UNIX работает Х-Windows, то новый процесс получает то окно, в котором он был запущен. В Windows 2000 процесс не имеет своего окна, но он должен создать несколько окон. В обоих системах пользователь может открыть несколько окон, каждому из которых соответствует свой процесс.

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

С технической точки зрения во всех перечисленных случаях новый процесс формируется одинаково: текущий процесс выполняет запрос на создание нового процесса.

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

В Windows вызов только одной CreateProcess интерфейса Win32 управляет и созданием процесса и запуском в нем нужной программы. У этой функции 10 параметров (имя запускаемой программы, параметры командной строки этой программы, различные атрибуты защиты, биты, управляющие наследованием открытых файлов, приоритеты, спецификация окна, указатель на структуру – информация о процессе для вызывающей программы.) Кроме того в Windows есть около 100 функций для управления процессами и их синхронизацией.

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

В Windows адресные пространства родительского и дочернего процессов отличаются с самого начала.

3. Завершение процесса

Причины завершения процесса:

1) Обычный выход. Процессы завершаются по мере своей работы. После окончания компиляции программы компилятор выполняет системный запрос, чтобы сообщить операционной системе об окончании работы. В UNIX это запрос-exit, Windows- ExitProcess. 2)Ошибка (преднамеренно). В редакторах, браузерах и других программах такого типа есть кнопка или пункт меню - удаление временных файлов, завершение процесса.

3)Выход по неисправимой ошибке (непреднамеренно). Например, компиляция файла, которого не существует. Интерактивные процессы не завершают работу при получении неверных параметров, просят пользователя ввести правильные параметры. Кроме того, ошибка в программе: деление на ноль, обращение к несуществующей области памяти, выполнение недопустимой команды.

4)Выполнение другим процессом системного запроса на уничтожение. UNIX – kill, Win 32 – TerminateProcess. В обоих случаях киллер должен обладать соответствующими полномочиями по отношению к «убиваемому» процессу. В некоторых системах по завершении процесса, все процессы, им созданные, завершаются; но это не относится ни к UNIX ни к Windows.

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

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

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

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

5. Состояния процессов

Пример: cat chapter1 chapter2 chapter3 | grep tree. Первый процесс, исполняющий файл cat объединяет и выводит три файла. Второй процесс, исполняющий файл grep отбирает все строки, содержащие слово «tree». В зависимости от остальных скоростей может так получиться, что grep уже готов к запуску, но входных данных для этого процесса еще нет. Процесс блокируется до поступления данных.

Вторая причина останова - решение планировщика операционной системы. Две эти ситуации принципиально различны.

Три возможных состояния процесса:

1. Работающий (использующий процессор в этот конкретный момент)

2. Готовый к работе (временно приостановлен, чтобы позволить другому процессу выполнить работу;

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

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

Рассмотренный подход описывается моделью, представленной на рис. 3.2.

Рис. 3.2. Нижний уровесь ОС

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

6. Реализация процессов

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

Таблица 3.1 Некоторые поля типичного элемента таблицы процессов

Таблица 3.2. Об этом говорит сайт https://intellect.icu . Схема обработки прерывания нижним уровнем ОС

7. Процессы в системе UNIX

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

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

Пример типичного демона cron daemon – просыпается раз в минуту и проверяет, не нужно ли что ему сделать. Планирует работу на минуты, часы дни и даже месяцы вперед. Если Вам требуется напоминание, то оставляйте запись в базе данных демона cron, чтобы он пропищал в нужный день в нужное время.

Кроме того, cron daemon используется для периодического запуска задач, например, для ежедневной архивации диска в 4 часа ночи.

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

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

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

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

    алгоритм fork
     входная информация:  отсутствует
     выходная информация: для родительского процесса - идентифи-
                           катор (PID) порожденного процесса
                          для порожденного процесса - 0
     {
        проверить доступность ресурсов ядра;
        получить свободное место в таблице процессов и уникаль-
         ный код идентификации (PID);
        проверить, не запустил ли пользователь слишком много
         процессов;
        сделать пометку о том, что порождаемый процесс находится
         в состоянии "создания";
        скопировать информацию в таблице процессов из записи,
         соответствующей родительскому процессу, в запись, соот-
         ветствующую порожденному процессу;
        увеличить значения счетчиков ссылок на текущий каталог и
         на корневой каталог (если он был изменен);
        увеличить значение счетчика открытий файла в таблице
         файлов;
        сделать копию контекста родительского процесса (адресное
         пространство, команды, данные, стек) в памяти;
        поместить в стек фиктивный уровень системного контекста
         над уровнем системного контекста, соответствующим по-
         рожденному процессу;
             фиктивный контекстный уровень содержит информацию,
             необходимую порожденному процессу для того, чтобы
             знать все о себе и будучи выбранным для исполнения
             запускаться с этого места;
        если (в данный момент выполняется родительский процесс)
        {
           перевести порожденный процесс в состояние "готовности
            к выполнению";
           возвратить (идентификатор порожденного процесса);
                      /* из системы пользователю */
        }
        в противном случае   /* выполняется порожденный
                                            процесс */
        {
           записать начальные значения в поля синхронизации ад-
            ресного пространства процесса;
           возвратить (0);   /* пользователю */
        }
     }

Рисунок 7.2. Алгоритм fork

Листинг 3.1 Создание процесса в системе UNIX

Процессы распознаются по своим PID- идентификаторам. При создании процесса его PID

вручается родителю. Если дочерний процесс желает узнать свой PID –getpid. Идентификаторы процессов используются различным способом, например, когда процесс завершается, его PIDвыдается родителю, потому что у родителя может быть много дочерних процессов.

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

При помощи каналов организуются конвейеры оболочки. Когда оболочка видит строку вроде sort <f| head, то она создает два процесса sort и head, а также устанавливает между ними канал таким образом, что стандартный поток вывода команды sort является стандартным потоком ввода команды head. При этом все данные, формируемые программой sort, попадают напрямую в head, для чего не требуется временного файла. Если канал переполняется, система приостанавливает работу программы sort, пока head не удалит из него хоть сколько-нибудь данных.

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

• А)группы его родителя;
• Б)всех прародителей;
• В)братьев, сестер;

Г)детей ,(внуков и правнуков).

Процесс может послать сигнал сразу всей группе за один системный вызов.

Сигналы используются и для других целей, например, если процесс выполняет вычисления с плавающей точкой и делит число на 0, он получит сигнал SIGFPE (Floating PointExeption Signal).

Таблица 3.3. Сигналы, требуемые стандартом POSIX

Системные вызовы для управления процессами в UNIX

Таблица 3.4. Некоторые системные вызовы, относящиеся к процессам

fork()- единственный способ создания новых процессов в системах UNIX. Как правило, дочерний процесс исполняет программу отличную от родительской. Например, программа оболочки…(пример из Робачевского). Для ожидания завершения дочернего процесса родительский процесс обращается к системному вызову waitpid(…). Первый параметр - pidпроцесса, завершение которого ожидается, если указать -1, то системный вызов ожидает завершение любого дочернего процесса. Второй параметр - адрес переменной, хранящей статус завершения процесса. Третий параметр определяет, будет ли обращающийся к системному вызову waitpid процесс блокирован до завершения дочернего процесса или сразу получит управление после обращения к системному вызову.

В самом общем случае у системного вызова exec три параметра: имя исполняемого файла, указатель на массив аргументов и указатель на массив строк окружения. Различные варианты этой процедуры execve, execl, execv, execle позволяют опускать те или иные параметры. Все эти процедуры обращаются к одному и тому же системному вызову. Хотя сам системный вызов называется exec, библиотечной процедуры с таким именем нет. Что касается третьего параметра: envp, он представляет собой указатель на переменные среды и является массивом, содержащим строки вида имя=значение, используемые в программе для передачи такой информации, как тип терминала и имя рабочего каталога.

Простой системный вызов exit, у него один параметр - статус выхода (0..255), возвращаемый родительскому процессу в переменной status системного вызова waitpid . Младший байт переменной статус содержит статус завершения 0 – нормальное завершение или код ошибки – аварийное завершение. Например, если родительский процесс выполняет оператор:

n=waitpid (-1, &status, 0);

он будет приостановлен до тех пор, пока не завершится какой-нибудь дочерний процесс. Если дочерний процесс завершится со статусом , скажем, равным 4, в качестве параметра библиотечной процедуры exit, то родительский процесс получит PID дочернего процесса и значение статуса, равное 0x400 . Младший байт переменной status относится к сигналам, старший байт представляет собой значение, задаваемое дочерним процессом в виде параметра при обращении к системному вызову exit.

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

Программа создает порожденный процесс, который подтверждает свое создание, а затем завершается с кодом завершения 15. Тем временем родительский процесс приостанавливает свое выполнение посредством вызова waitpid. После завершения порожденного процесса выполнение родительского возобновляется, и его переменным status и child_pid присваивается код завершения порожденного процесса, а также его идентификатор. Родительский процесс использует макросы, определенные в <sys/wait.h>, для определения статуса выполнения порожденного процесса следующим способом:

Если WIFEXITED возвращает ненулевое значение, следовательно, порожденный процесс был завершен с использованием вызова _exit. Родительский процесс извлекает код завершения (который в этом примере равен 15) с помощью макрокоманды WEXITSTATUS. Затем он направляет полученное значение в стандартный поток ошибок.

Если WIFEXITED возвращает нулевое значение, а WIFSTOPPED – ненулевое, следовательно, порожденный процесс был завершен сигналом. Родительский процесс извлекает номер сигнала с помощью макрокоманды WSTOPSIG. Затем он направляет полученное значение в стандартный поток ошибок.

Если WIFEXITED и WIFSTOPPED возвращают нулевое значение, а WIFSIGNALED – ненулевое, то порожденный процесс был завершен неперехваченным сигналом. Родительский процесс извлекает номер сигнала с помощью макрокоманды WTERMSIG. Затем он направляет полученное значение в стандартный поток ошибок

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

Функции wait, waitpid – являются способом уничтожить зомби-процесс.

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

Функция wait приостанавливает выполнение родительского процесса до тех пор, пока ему не буде послан сигнал, либо пока один из его порожденных процессов не завершится или не будет остановлен (а его статус не будет сообщен). Если порожденный процесс уже завершился и был остановлен до вызова wait, функция wait немедленно возвратится со статусом завершения порожденного процесса (его значение содержится в аргументе status_p), а возвращаемым значением функции будет PID порожденного процесса. Если, однако, родительский процесс не имеет порожденных процессов, завершения который он ожидает, или он был прерван сигналом при выполнении wait, функция возвращает значение –1, а переменная errno будет содержать код ошибки. Если родительский процесс создал более одного порожденного процесса, функция wait будет ожидать завершения каждого из них.

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

7 Потоки

Некоторые системные вызовы относятся к сигналам, используемым различными способами. Например, текстовый редактор отображает содержимое очень длинного текстового файла, Нажатие CTRL+C или DEL - редактору посылается сигнал, который прервет работу текстового редактора.

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

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

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

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

Во многих приложения реального времени бывает необходимо прервать процесс через определенный промежуток времени системный вызов alarm. Параметр этого системного вызова задает временной интервал, по истечении которого процессу посылается SIGALARM. У процесса в каждый момент времени может быть только один будильник. Например, если процесс обращается к системному вызову alarm с параметром 10 с, а 3с спустя снова обращается к нему с параметром 20с, то он получит только один сигнал через 20 с после второго системного вызова. Первый сигнал будет отменен вторым обращением к системному вызову alarm. Если параметр системного вызова alarm равен нулю, то такое обращение отменяет любой сигнал будильника. Если сигнала будильника не перехватывается , то действие по умолчанию заключается в уничтожении процесса. Технически возможно игнорирование такого сигнала, но нецелесообразно.

Иногда случается так, что процессу нечем заняться пока придет сигнал. Например, обучающая программа, тестирующая скорость реакции. Отобразив на экране некоторый текст, обращается к системному вызову alarm, чтобы система послала ей сигнал через 30с. Пока студент читает текст, у программы дел нет. Она может сидеть в коротком цикле, ничего не делая, но такая реализация будет напрасно расходовать время центрального процессора, которое может понадобиться фоновому процессу или другому пользователю. Лучшее решение – системный вызов pause, который указывает ОС приостановить работу процесса, пока не придет следующий сигнал.

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

У потока есть:

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

Хотя поток должен исполняться внутри процесса, следует различать концепции потока и процесса. Процессы используются для группирования ресурсов, а потоки являются объектами, поочередно исполняющимися на CPU. Концепция потоков добавляет к модели процесса возможность одновременного выполнения в одной и той же среде процесса нескольких программ, в достаточной степени независимых. Несколько потоков, работающих параллельно в одном процессе, аналогичны нескольким процессам, идущим параллельно на одном компьютере. В первом случае потоки разделяют адресное пространство, открытые файлы и другие ресурсы. Во втором случае процессы совместно пользуются физической памятью, дисками, принтерами и другими ресурсами. Потоки обладают некоторыми свойствами процессов, поэтому их иногда называют упрощенными процессами. Термин многопоточность также используется для описания использования нескольких потоков в одном процессе. На Рис. 4(а) представлены три обычных процесса, у каждого из которых есть собственное адресное пространство и одиночный поток управления. На Рис. 4(б) представлен один процесс с тремя потоками управления. В обоих случаях мы имеем три потока, но на Рис. 4(а) каждый из них имеет собственное адресное пространство, а на Рис. 4(б) потоки разделяют единое адресное пространство. При запуске многопоточного процесса в системе с одним CPU потоки работают поочередно. Пример работы процессов в многозадачном режиме мы уже видели на Рис. 1. Иллюзия параллельной работы нескольких различных последовательных процессов создается путем постоянного переключения системы между процессами. Многопоточность реализуется примерно так же. CPU быстро переключается между потоками, создавая впечатление параллельной работы потоков, хотя и на не столь быстром CPU. В случае трех ограниченных производительностью CPU потоков в одном процессе все потоки будут работать параллельно, и каждому потоку будет соответствовать виртуальный CPU с быстродействием, равным одной трети быстродействия реального CPU.

Различные потоки в одном процессе не так независимы, как различные процессы. У всех потоков одно и то же адресное пространство, что означает совместное использование глобальных переменных. Поскольку любой поток имеет доступ к любому
адресу ячейки памяти в адресном пространстве процесса, один поток может считывать, записывать или даже стирать информацию из стека другого потока. Защиты не существует, поскольку:
1. Это невозможно.
2. Это ненужно.

В отличие от различных процессов, которые могут быть инициированы различными пользователями и преследовать несовместимые цели, один процесс всегда запущен одним пользователем, и потоки созданы таким образом, чтобы работать совместно, не
мешая друг другу. Как показано в таблице 3, потоки разделяют не только адресное пространство, но и открытые файлы, дочерние процессы, сигналы и т. п. Таким образом, ситуацию на Рис. 4(а) следует использовать в случае абсолютно несвязанных
процессов, тогда как схема на Рис. 4(б) будет уместна, когда потоки выполняют совместно одну работу.

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

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

Рис. 4.3. Граф состояний потока в многозадачной среде

В состоянии выполнения в однопроцессорной системе может находиться не более одного потока, а в каждом из состояний ожидания и готовности — несколько потоков. Эти потоки образуют очереди соответственно ожидающих и готовых потоков. Очереди потоков организуются путем объединения в списки описателей отдельных потоков. Таким образом, каждый описатель потока, кроме всего прочего, содержит по крайней мере один указатель на другой описатель, соседствующий с ним в очереди. Такая организация очередей позволяет легко их переупорядочивать, включать и исключать потоки, переводить потоки из одного состояния в другое. Если предположить, что на рис. 4.4 показана очередь готовых потоков, то запланированный порядок выполнения выглядит так: А, В, Е, D, С.

Рис. 4.4. Очередь потоков

Контрольные вопросы для самопроверки

• 1. Сколько будильников может быть у процесса?
• 2. Определения межпроцессных взаимодействий.
• 3. Виды межпроцессных взаимодействий в UNIX.
• 4. Какие процессы входят в группу процессов родственников?
• 5. Сигнал, отправляемый процессу, попадает ко всем его родственникам. Куда, в таком случае, попадает сигнал с клавиатуры CTRL+C, если вы в это время работаете в редакторе?
• 6. Действия процесса при получении сигнала.
• 7. Определение зомби-процесса.
• 8. Планируется ли на выполнение заблокированный процесс.
• 9. Примеры программ, когда процесс при ожидании каких-то действий лучше заблокировать и когда лучше оставить его выполняющимся параллельно.
• 10 в чем отличие процесса от потока

Вау!! 😲 Ты еще не читал? Это зря!

• многозадачность , типы многозадачности ,
• неопределённость параллелизма , состояние гонки ,
• потоки , процессы ,
• процесс отличается от потока ,
• процессы linux , задачи linux ,
• потоки , процессы ,
• формы представления информации ,

• fork-бомба

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

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.