Какая информация содержится в дескрипторе процесса: Дескриптор процесса и структура task structure. Разработка ядра Linux

Содержание

Дескриптор процесса и структура task structure. Разработка ядра Linux

Читайте также

Общий обзор средств безопасности: дескриптор безопасности

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

Дескриптор памяти

Дескриптор памяти Ядро представляет адресное пространство процесса в виде структуры данных, которая называется дескриптором памяти. Эта структура содержит всю информацию, которая относится к адресному пространству процесса. Дескриптор памяти представляется с помощью

Internet Engineering Task Force

Internet Engineering Task Force IETF (Internet Engineering Task Force — группа, отвечающая за решение сетевых инженерных задач) — это большое открытое международное сообщество сетевых разработчиков, операторов, производителей и исследователей, работающих в области развития архитектуры Интернета и

При каких условиях дескриптор становится готовым?

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

(1.10) Что такое Task Manager?

(1.10) Что такое Task Manager? Task Manager – это один из самых мощных и удобных инструментов в NT, предназначенных для управления процессами. Вызывается он либо Ctrl+Shift+Esc, либо выбором в меню, появляющимся после нажатия правой кнопкой на Taskbar-е. Можно его выбрать и после Ctrl+Alt+Del.Task manager

(3.18) Как задать пpиоpитет пpоцесса еще пpи его запyске? Чтоб не лазить постоянно для этого в task manager?

(3.18) Как задать пpиоpитет пpоцесса еще пpи его запyске? Чтоб не лазить постоянно для этого в task manager? Запуская с помощью консольной команды start можно запускать приложение с нужным приоритетом, указывать время, через которое приложение должно быть закрыто, и некоторые другие

(3.30) Как отключить (запретить) Task Manager?

(3.30) Как отключить (запретить) Task Manager? Для этого в реестре по адресу HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem создайте ключ типа DWORD под названием DisableTaskMgr, и присвойте ему значение 1. Удалив этот ключ, или присвоив ему 0, вы вновь разрешите Task

Структура

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

Структура

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

1.9. Что такое Task Manager?

1.9. Что такое Task Manager? Task Manager — это один из самых мощных и удобных инструментов в NT, предназначенных для управления процессами. Вызывается он либо Ctrl+Shift+Esc, либо выбором в меню, появляющимся после нажатия правой кнопкой на Taskbar-е. Task manager в XP состоит из пяти закладок — Applications,

3.8. Как задать пpиоpитет процесса еще пpи его запyске, чтоб не лазить постоянно для этого в task manager?

3.8. Как задать пpиоpитет процесса еще пpи его запyске, чтоб не лазить постоянно для этого в task manager? Запуская с помощью консольной команды start можно запускать приложение с нужным приоритетом, указывать время, через которое приложение должно быть закрыто, и некоторые другие

8.1.1. Структура

8.1.1. Структура Это – структура, которой следуют все сценарии в этом руководстве. Если вы обнаружите, что это не так, то скорее всего это моя ошибка, если конечно я не объяснил, почему я нарушил эту структуру.1. Configuration – Прежде всего мы должны задать параметры конфигурации,

7.3.2. Концепции, касающиеся основных средств производственного процесса организации Основные средства производственного процесса организации (ППО)

7.3.2. Концепции, касающиеся основных средств производственного процесса организации Основные средства производственного процесса организации (ППО) Организация устанавливает и сопровождает набор основных средств производственного процесса, как показано на рис. 4.1. К

Структура

Структура Режим Структура используется при создании больших документов, насыщенных заголовками и подзаголовками (рис. 2.60). Для работы с этим режимом нужно, чтобы документ был отформатирован при помощи стилей (см. разд. 4.7), иначе этот режим в работе помочь не сможет. Рис.

Структура

Структура Так как вы имеете дело с отображением структурированных данных, необходимо определится с общим размещением. Обычно Joomla! использует структуру размещения элементов показанную ниже: Рис. 1: СтруктураСекция 1:  Часть 1: Тут стоит разместить логотип или название

12. Дескриптор процесса.

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

1. Идентификатор процесса (ProcessIdentificator(ID))

2. Тип или класс процесса, к-ый определяет для ОС некоторые правила предоставления ресурсов.

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

4. Переменную состояния, к-ая определяет в каком состоянии находится процесс (готовность к работе, состояние выполнения, ожидание устр-ва ввода/вывода и т. д.)

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

6. Информацию о ресурсах, к-ми процесс владеет и имеет право пользоваться (указатели на открытые файлы, информация о независимых операциях вв/выв и т. д.)

7. Место памяти или адрес этого места для организации общения с другими процессами.

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

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

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

13. Потоки в операционных с-мах.

Концепцию процесса можно охарактеризовать двумя параметрами:

1. Владение ресурсами.

Процесс включает виртуальное адресное пространство в к-ом содержится образ процесса и время от времени может владеть такими ресурсами, как основная память, устр-во вв/выв, файлы. ОС выполняет защитные ф, предотвращая нежелательные взаимодействия процессов.

2. Планирование и выполнение.

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

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

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

Осн-ые преимущества использования потоков:1)создание нового потока в уже существующем процессе занимает меньше времени, чем создание нового процесса; 2) поток можно завершить быстрее чем процесс; 3)переключение потоков в рамках одного и того же процесса происходит быстрее; 4)при использовании потока повышается эффективность обмена информацией между двумя выполняющимися прогами. В большинстве ОС обмен между независимыми процессами происходит с участием ядра, в ф которого входит обеспечение защиты и механизма необходимого для осуществления обмена. Однако благодаря тому, что различные потоки одного и того же процесса используют одну и ту же область памяти и одни и те же файлы, они могут обмениваться информацией без участия ядра.

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

НОУ ИНТУИТ | Лекция | Организация вычислительного процесса

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

5.1. Концепция процессов и потоков. Задание, процессы, потоки (нити), волокна

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

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

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


Рис. 5.1. Таблицы ОС

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

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

Процессы рассматриваются операционной системой как заявки или контейнеры для всех видов ресурсов, кроме одного – процессорного времени. Это важнейший ресурс распределяется операционной системой между другими единицами работы – потоками, которые и получили свое название благодаря тому, что они представляют собой последовательности (потоки выполнения) команд. Каждый процесс начинается с одного потока, но новые потоки могут создаваться (порождаться) процессом динамически. В простейшем случае процесс состоит из одного потока, и именно таким образом трактовалось понятие «процесс» до середины 80-х годов (например, в ранних версиях UNIX). В некоторых современных ОС такое положение сохранилось, т.е. понятие «поток» полностью поглощается понятием «процесс».

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

Взаимосвязь между заданиями, процессами и потоками показана на рис. 5.2.


Рис. 5.2. Задания, процессы, потоки

Переключение потоков в ОС занимает довольно много времени, так как для этого необходимы переключение в режим ядра, а затем возврат в режим пользователя. Достаточно велики затраты процессорного времени на планирование и диспетчеризацию потоков. Для предоставления сильно облегченного псевдопараллелизма в Windows 2000 (и последующих версиях) используются волокна (Fiber), подобные потокам, но планируемые в пространстве пользователя создавшей их программой. У каждого потока может быть несколько волокон, с той разницей, что когда волокно логически блокируется, оно помещается в очередь блокированных волокон, после чего для работы выбирается другое волокно в контексте того же потока. При этом ОС «не знает» о смене волокон, так как все тот же поток продолжает работу.

Таким образом, существует иерархия рабочих единиц операционной системы, которая применительно к Windows выглядит следующим образом (рис. 5.3).

Возникает вопрос: зачем нужна такая сложная организация работ, выполняемых операционной системой? Ответ нужно искать в развитии теории и практики мультипрограммирования, цель которой – в обеспечении максимально эффективного использования главного ресурса вычислительной системы – центрального процессора (нескольких центральных процессоров).

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


Рис. 5.3. Иерархия рабочих единиц ОС

5.2. Мультипрограммирование. Формы многопрограммной работы

Мультипрограммирование призвано повысить эффективность использования вычислительной системы [10, 17]. Однако эффективность может пониматься по-разному. Наиболее характерными показателями эффективности вычислительных систем являются:

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

В зависимости от выбора одного из этих показателей эффективности ОС делятся на системы пакетной обработки, системы разделения времени и системы реального времени (некоторые ОС могут поддерживать одновременно несколько режимов).

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

В благоприятных случаях общее время выполнения смеси задач меньше, чем суммарное время их последовательного выполнения. При этом времени выполнения отдельной задачи может быть затрачено больше, чем при монопольном ее выполнении (рис. 5.4).

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


Рис. 5.4. Иллюстрация эффекта мультипрограммирования

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


Рис. 5.5. Система разделения времени

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

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

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

Интересная форма мультипрограммной работы связана с мультипроцессорной обработкой. Мультипроцессорная обработка – это способ организации вычислительного процесса в системе с несколькими процессорами, при котором несколько задач (процессов, потоков) могут одновременно выполняться на разных процессорах системы. Концепция мультипроцессирования не нова, она известна с 70-х годов, однако стала доступной в широком масштабе лишь в последнее десятилетие, особенно с появлением многопроцессорных ПК (часто в качестве серверов ЛВС).

В отличие от мультипрограммной обработки, в мультипроцессорных системах несколько задач выполняется одновременно, т.к. имеется несколько процессоров. Однако это не исключает мультипрограммной обработки на каждом процессоре. При этом резко усложняются все алгоритмы управления ресурсами, т.е. операционная система. Современные ОС, как правило, поддерживают мультипроцессирование (Sun Solaris 2.x, Santa Cruz Operation Open Server 3.x, OS/2, Windows NT/2000/2003/XP, NetWare, начиная с версии 4.1 и др.).

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

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

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

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

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

Процессы и потоки, диспетчер задач windows, синхронизация потоков.

В этой статье мы поговорим на такие темы, как процессы и потокидискрипторы процесса, поговорим о синзронизации потоков и затронем всеми любимый диспетчер задач windows.

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

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

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

В общем случае дескриптор содержит следующую информацию:

  1. Идентификатор процесса.
  2. Тип (или класс) процесса, который определяет для супервизора некоторые правила предоставления ресурсов.
  3. Приоритет процесса.
  4. Переменную состояния, которая определяет, в каком состоянии находится процесс (готов к работе, в состоянии выполнения, ожидание устройства ввода-вывода и т.д.)
  5. Защищенную область памяти (или адрес такой зоны), в которой хранятся текущие значения регистров процессора, если процесс прерывается, не закончив работы. Эта информация называется контекстом задачи.
  6. Информацию о ресурсах, которыми процесс владеет и/или имеет право пользоваться (указатели на открытые файлы, информация о незавершенных операциях ввода/вывода и т.п.).
  7. Место (или его адрес) для организации общения с другими процессами.
  8. Параметры времени запуска (момент времени, когда процесс должен активизироваться, и периодичность этой процедуры).
  9. В случае отсутствия системы управления файлами – адрес задачи на диске в ее исходном состоянии и адрес на диске, куда она выгружается из оперативной памяти, если ее вытесняет другая.

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

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

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

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

Процессы и потоки

Чтобы поддерживать мультипрограммирование, ОС должна определить и оформить для себя те внутренне единицы работы, между которыми будет разделяться процессор и другие ресурсы компьютера. В настоящее время в большинстве ОС определены два типа единиц работы:

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

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

Для повышения быстродействия процессов есть возможность задействовать внутренний параллелизм в самих процессах.

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

Можно выделить следующие отличия потоков от процессов:

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

Главное, что обеспечивает многопоточность, — это возможность параллельно выполнять несколько видов операций в одной прикладной программе. За счет чего реализуется эффективное использование ресурсов ЦП, а суммарное время выполнения задач становится меньше.

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

Диспетчер задач WINDOWS

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

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

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

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

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

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

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

Пример. Задача ведения базы данных клиентов некоторого предприятия.

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

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

Оба эти потока совместно работают над общим файлом базы данных, используя однотипные алгоритмы:

  1. Считать из файла БД в буфер запись и клиенте с заданным идентификатором.
  2. Ввести новое значение в поле Заказ (для потока А) или оплата (для потока В).
  3. Вернуть модифицированную запись в файл БД.

Обозначим шаги 1-3 для потока А как А1-А3, а для потока В как В1-В3. Предположим, что в некоторый момент поток А обновляет поле Заказ записи о клиенте N. Для этого он считывает эту запись в свой буфер (шаг А1), модифицирует значение поля Заказ (шаг А2), но внести запись в базу данных не успевает, так как его выполнение прерывается, например, вследствие истечение кванта времени.

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

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

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

Другим способом является использование блокирующих переменных. С каждым разделяемым ресурсом связывается двоичная переменная, которая принимает значение 1, если ресурс свободен (то есть ни один процесс не находится в данный момент в критической секции, связанной с данным процессом), и значение 0, если ресурс занят. На рисунке ниже показан фрагмент алгоритма процесса, использующего для реализации взаимного исключения доступа к разделяемому ресурсу D блокирующую переменную F(D). Перед входом в критическую секцию процесс проверяет, свободен ли ресурс D. Если он занят, то проверка циклически повторяется, если свободен, то значение переменной F(D) устанавливается в 0, и процесс входит в критическую секцию. После того, как процесс выполнит все действия с разделяемым ресурсом D, значение переменной F(D) снова устанавливается равным 1.

Если все процессы написаны с использованием вышеописанных соглашений, то взаимное исключение гарантируется. Следует заметить, что операция проверки и установки блокирующей переменной должна быть неделимой. Поясняется это следующим образом. Пусть в результате проверки переменной процесс определил, что ресурс свободен, но сразу после этого, не успев установить переменную в 0, был прерван. За время его приостановки другой процесс занял ресурс, вошел в свою критическую секцию, но также был прерван, не завершив работы с разделяемым ресурсом. Когда управление было возвращено первому процессу, он, считая ресурс свободным, установил признак занятости и начал выполнять свою критическую секцию. Таким образом, был нарушен принцип взаимного исключения, что потенциально может привести к нежелаемым последствиям. Во избежание таких ситуаций в системе команд машины желательно иметь единую команду «проверка-установка», или же реализовывать системными средствами соответствующие программные примитивы, которые бы запрещали прерывания на протяжении всей операции проверки и установки.

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

Если ресурс занят, то процесс не выполняет циклический опрос, а вызывает системную функцию WAIT(D), здесь D обозначает событие, заключающееся в освобождении ресурса D. Функция WAIT(D) переводит активный процесс в состояние ОЖИДАНИЕ и делает отметку в его дескрипторе о том, что процесс ожидает события D. Процесс, который в это время использует ресурс D, после выхода из критической секции выполняет системную функцию POST(D), в результате чего операционная система просматривает очередь ожидающих процессов и переводит процесс, ожидающий события D, в состояние ГОТОВНОСТЬ.

Обобщающее средство синхронизации процессов предложил Дейкстра, который ввел два новых примитива. В абстрактной форме эти примитивы, обозначаемые P и V, оперируют над целыми неотрицательными переменными, называемыми семафорами. Пусть S такой семафор. Операции определяются следующим образом:

V(S): переменная S увеличивается на 1 одним неделимым действием; выборка, инкремент и запоминание не могут быть прерваны, и к S нет доступа другим процессам во время выполнения этой операции.

P(S): уменьшение S на 1, если это возможно. Если S=0, то невозможно уменьшить S и остаться в области целых неотрицательных значений, в этом случае процесс, вызывающий P-операцию, ждет, пока это уменьшение станет возможным. Успешная проверка и уменьшение также является неделимой операцией.

В частном случае, когда семафор S может принимать только значения 0 и 1, он превращается в блокирующую переменную. Операция P заключает в себе потенциальную возможность перехода процесса, который ее выполняет, в состояние ожидания, в то время как V-операция может при некоторых обстоятельствах активизировать другой процесс, приостановленный операцией P.

Взаимоблокировка процессов

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

При параллельном исполнении процессов могут возникать ситуации, при которых два или более процесса все время находятся в заблокированном состоянии. Самый простой случай – когда каждый из двух процессов ожидает ресурс, занятый другим процессом. Из-за такого ожидания ни один из процессов не может продолжить исполнение и освободить в конечном итоге ресурс, необходимый другому процессу. Эта тупиковая ситуация называется дедлоком (dead lock), тупикомклинчем или взаимоблокировкой.

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

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

Проблема тупиков включает в себя следующие задачи:

  1. предотвращение тупиков.
  2. распознавание тупиков.
  3. восстановление системы после тупиков.

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

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

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

Образ, дескриптор, контекст процесса — КиберПедия

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

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

При управлении процессами операционная система использует два основных типа информационных структур: дескриптор процесса (структура proc) и контекст процесса (структура user).

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

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

 

Идентификаторы

Идентификатор процесса PID, идентификатор процесса породившего данный процесс. PPID

Идентификатор процесса (PID)

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

Идентификатор родительского процесса (PPID)

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

 

Реальные и эффективные (действующие) идентификаторы пользователя и группы пользователей (UID\EUID, GID\EGID)

Реальный (UID) и эффективный (EUID) идентификаторы пользователя

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

Реальный (GID) и эффективный (EGID) идентификаторы группы

Реальный идентификатор группы равен идентификатору основной или текущей группы пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа к системным ресурсам от имени группы. Обычно эффективный идентификатор группы совпадает с реальным. Но если для выполняемого файла установлен бит SGID, такой файл выполняется с эффективным идентификатором группы-владельца.

 

1.2 процесс, контекст процесса и потоки

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

В Windows NT несколько процессов могут существовать одновременно; но только один процесс выполняется центральным процессором в определенный момент времени. Обратите внимание: драйверы вообще и драйверы систем хранения данных в частности не создают собственных процессов. Операционная система создает несколько процессов для своих нужд, а также определенные процессы в ответ на пользовательские команды, например когда пользователь запускает приложение, такое, как Microsoft Word или Microsoft Excel. Если драйвер вызывается во время работы процесса, считается, что он работает в контексте вызывающего процесса.

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

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

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

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

⇐1.1 режимы ядра и пользователя windows | Системы хранения данных в Windows | 1.3 архитектура windows nt⇒

Переключение контекста

Существенно сократить накладные расходы в современных операционных системах позволяет расширенная модель процессов, включающая в себя понятие threads of execution (нити исполнения или просто нити).

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

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

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

 

 


©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.

Раздел 3.2. Дескриптор процесса | Учебник по ядру Linux. Подход «сверху вниз» для архитектур x86 и PowerPC

3.2. Дескриптор процесса

В ядре дескриптор процесса представляет собой структуру с именем task_struct, которая отслеживает атрибуты процесса и информацию. Вся информация о ядре, касающаяся процесса, находится там. На протяжении жизненного цикла процесс взаимодействует со многими аспектами ядра, такими как управление памятью и планирование. Дескриптор процесса отслеживает информацию об этих взаимодействиях, а также стандартные атрибуты процесса UNIX.Ядро хранит все дескрипторы процессов в кольцевом двусвязном списке, называемом task_list. Ядро также хранит ссылку на task_struct текущего процесса с помощью глобальной переменной current. (В этой книге мы ссылаемся на текущий для обозначения дескриптора процесса, выполняющегося в данный момент.)

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

Следующие категории описывают некоторые типы вещей, которые дескриптор процесса должен отслеживать в течение всего жизненного цикла процесса:

Теперь внимательно рассмотрим поля в структуре task_struct. В этом разделе описывается, что они делают, и относится к фактической обработке, в которой задействовано поле. Хотя многие поля используются для деятельности, относящейся к вышеупомянутым категориям, некоторые из них выходят за рамки этой книги. Структура task_struct определена в include/linux/sched.ч:

 ------------------------------------------------------------- ------------------------- include/linux/sched.h 384 struct task_struct { 385 volatile long state; 386 struct thread_info *thread_info; 387 использование atomic_t; 388 беззнаковых длинных флагов; 389 беззнаковая длинная ptrace; 390 391 int lock_depth; 392 393 int prio, static_prio; 394 struct list_head run_list; 395 prio_array_t *массив; 396 397 unsigned long sleep_avg; 398 длинных интерактивных_кредитов; 399 unsigned long длинная отметка времени; 400 инт активирован; 401 302 беззнаковая длинная политика; 403 cpumask_t cpus_allowed; 404 целое число без знака time_slice, first_time_slice; 405 406 задач struct list_head; 407 struct list_head ptrace_children; 408 struct list_head ptrace_list; 409 410 struct mm_struct *mm, *active_mm; ... 413 struct linux_binfmt *binfmt; 414 int код_выхода, сигнал_выхода; 415 интервал pdeath_signal; ... 419 pid_t pid; 420 pid_t tgid; ... 426 struct task_struct *real_parent; 427 struct task_struct *parent; 428 дочерних структур list_head; 429 struct list_head sibling; 430 struct task_struct *group_leader; ... 433 struct pid_link pids[PIDTYPE_MAX]; 434 435 wait_queue_head_t wait_chldexit; 436 завершение структуры *vfork_done; 437 интервал __user *set_child_tid; 438 int __user *clear_child_tid; 439 440 unsigned long rt_priority; 441 unsigned long it_real_value, it_prof_value, it_virt_value; 442 unsigned long it_real_incr, it_prof_incr, it_virt_incr; 443 struct timer_list real_timer; 444 unsigned long utime, stime, cutime, cstime; 445 unsigned long nvcsw, nivcsw, cnvcsw, cnivcsw; 446 u64 start_time; ... 450 uid_t uid,euid,suid,fsuid; 451 gid_t gid,egid,sgid,fsgid; 452 struct group_info *group_info; 453 kernel_cap_t cap_efficient, cap_inheritable, cap_permitted; 454 int keep_capabilities:1; 455 struct user_struct *user; ... 457 struct rlimit rlim[RLIM_NLIMITS]; 458 беззнаковый короткий used_math; 459 символов комм[16]; ... 461 int link_count, total_link_count; ... 467 struct fs_struct *fs; ... 469 struct files_struct *files; ... 509 unsigned long ptrace_message; 510 siginfo_t *last_siginfo; ... 516 }; -------------------------------------------------- --------------------- 

3.2.1. Поля, связанные с атрибутами процесса

Категория атрибутов процесса — это всеобъемлющая категория, которую мы определили для характеристик задачи, связанных с состоянием и идентификацией задачи. Проверка значений этих полей в любое время дает взломщику ядра представление о текущем состоянии процесса. На рис. 3.2 показаны поля, связанные с атрибутами процесса, в структуре task_struct.

Рис. 3.2. Поля, связанные с атрибутами процесса


3.2.1.1. state

Поле состояния отслеживает состояние, в котором находится процесс в течение своего жизненного цикла выполнения. Возможные значения, которые он может содержать: TASK_RUNNING, TASK_INTERRUPTIBLE, TASK_UNINTERRUPTIBLE, TASK_ZOMBIE, TASK_STOPPED и TASK_DEAD (подробности см. в разделе «Продолжительность жизни процесса» в этой главе).

3.2.1.2. pid

В Linux каждый процесс имеет уникальный идентификатор процесса (pid). Этот pid хранится в task_struct как тип pid_t.Хотя этот тип можно проследить до целочисленного типа, максимальное значение pid по умолчанию равно 32 768 (значение, относящееся к короткому int).

3.2.1.3. flags

Флаги определяют специальные атрибуты, относящиеся к задаче. Флаги процесса определены в include/linux/sched.h и включают в себя флаги, перечисленные в таблице 3.1. Значение флага предоставляет хакеру ядра больше информации о том, что происходит с задачей.

Таблица 3.1. Выбранные значения поля task_struct

При установке

PF_STARTING

Установка при создании процесса.

PF_EXITING

Устанавливается во время вызова do_exit().

PF_DEAD

Устанавливается при вызове exit_notify() в процессе выхода. На данный момент состояние процесса либо TASK_ZOMBIE, либо TASK_DEAD.

PF_FORKNOEXEC

Родитель при разветвлении устанавливает этот флаг.


3.2.1.4.binfmt

Linux поддерживает ряд исполняемых форматов. Исполняемый формат — это то, что определяет структуру того, как ваш программный код должен быть загружен в память. На рис. 3.2 показана связь между структурой task_struct и структурой linux_binfmt, которая содержит всю информацию, относящуюся к определенному двоичному формату (подробнее см. главу 9).

3.2.1.5. exit_code и exit_signal

Поля exit_code и exit_signal содержат значение выхода задачи и завершающий сигнал (если он использовался).Таким образом выходное значение дочернего элемента передается его родителю.

3.2.1.6. pdeath_signal

pdeath_signal — это сигнал, отправленный после смерти родителя.

3.2.1.7. comm

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

3.2.1.8. ptrace

ptrace устанавливается, когда системный вызов ptrace() вызывается для процесса для измерения производительности.Возможные флаги ptrace() определены в include/linux/ptrace.h.

3.2.2. Планирование связанных полей

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

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

Рисунок 3.3. Планирование связанных полей


3.2.2.1. prio

В главе 7 мы видим, что динамический приоритет процесса — это значение, которое зависит от истории планирования процессов и указанного значения nice. (См. следующую врезку для получения дополнительной информации о значениях nice.) Он обновляется во время сна, когда процесс не выполняется и когда квант времени используется. Это значение, prio, связано со значением поля static_prio, описанного далее.Поле prio содержит +/- 5 значений static_prio, в зависимости от истории процесса; он получит бонус +5, если он много спал, и фору -5, если он был борцом с обработкой и израсходовал свой квант времени.

3.2.2.2. static_prio

static_prio эквивалентно значению nice. Значение static_prio по умолчанию — MAX_PRIO-20. В нашем ядре MAX_PRIO по умолчанию равно 140.

Nice

Системный вызов nice() позволяет пользователю изменить статический приоритет планирования процесса.Значение nice может находиться в диапазоне от 20 до 19. Затем функция nice() вызывает set_user_nice() для установки поля static_prio в структуре task_struct. Значение static_prio вычисляется из значения nice с помощью макроса PRIO_TO_NICE. Точно так же значение nice вычисляется из значения static_prio с помощью вызова NICE_TO_PRIO.

 ------------------------------------------------------kernel/sched.c #define NICE_TO_PRIO( хороший) (MAX_RT_PRIO + хороший + 20) #define PRIO_TO_NICE(prio) ((prio MAX_RT_PRIO 20) ----------------------------- ------------------------ 


3.2.2.3. run_list

Поле run_list указывает на очередь выполнения. Очередь выполнения содержит список всех процессов, которые нужно запустить. Дополнительную информацию о структуре очереди выполнения см. в разделе «Основная структура».

3.2.2.4. array

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

3.2.2.5. sleep_avg

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

3.2.2.6. timestamp

Поле timestamp используется для расчета sleep_avg, когда задача приостанавливается или завершается.

3.2.2.7. Interactive_Credit

Поле Interactive_Credit используется вместе с полями sleep_avg и active для расчета sleep_avg.

3.2.2.8. policy

Политика определяет тип процесса (например, с разделением времени или в режиме реального времени). Тип процесса сильно влияет на приоритетное планирование. Дополнительные сведения об этом поле см. в главе 7.

3.2.2.9. cpus_allowed

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

3.2.2.10. time_slice

Поле time_slice определяет максимальное время, в течение которого задача может выполняться.

3.2.2.11. first_time_slice

Поле first_time_slice постоянно устанавливается в 0 и отслеживает время планирования.

3.2.2.12. активировано

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

3.2.2.13. rt_priority

rt_priority — это статическое значение, которое можно обновить только с помощью schedule(). Это значение необходимо для поддержки задач в реальном времени.

3.2.2.14. nivcsw и nvcsw

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

  • Поле nivcsw (количество непроизвольных переключений контекста) содержит количество вытеснений ядра, примененных к задаче. Он увеличивается только после возврата задачи из вытеснения ядра, где для счетчика переключений установлено значение nivcsw.

  • Поле nvcsw (количество добровольных переключений контекста) содержит количество переключений контекста, не основанных на вытеснении ядра. Счетчик переключений устанавливается равным nvcsw, если предыдущее состояние не было активным вытеснением.

3.2.3. Отношения процесса. Связанные поля

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

Рисунок 3.4. Отношения процессаСвязанные поля


3.2.3.1. real_parent

real_parent указывает на описание родителя текущего процесса. Он будет указывать на дескриптор процесса init(), если исходный родитель нашего текущего процесса был уничтожен. В предыдущих ядрах это было известно как p_opptr.

3.2.3.2. parent

parent — указатель на дескриптор родительского процесса. На рис. 3.4 мы видим, что это указывает на ptrace task_struct. Когда ptrace запускается для процесса, родительское поле task_struct указывает на процесс ptrace.

3.2.3.3. children

children — это структура, указывающая на список дочерних элементов нашего текущего процесса.

3.2.3.4. sibling

sibling — это структура, указывающая на список братьев и сестер текущего процесса.

3.2.3.5. group_leader

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

3.2.4. Process CredentialsRelated Fields

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

Рисунок 3.5. Учетные данные процессаСвязанные поля


3.2.4.1. uid и gid

Поле uid содержит идентификационный номер пользователя, создавшего процесс. Это поле используется в целях защиты и безопасности.Точно так же поле gid содержит идентификатор группы, которой принадлежит процесс. uid или gid, равные 0, соответствуют пользователю root и группе.

3.2.4.2. euid и egid

Эффективный идентификатор пользователя обычно содержит то же значение, что и поле идентификатора пользователя. Это изменяется, если выполняемая программа имеет установленный бит UID (SUID). В этом случае эффективным идентификатором пользователя является идентификатор владельца программного файла. Как правило, это используется, чтобы разрешить любому пользователю запускать определенную программу с теми же разрешениями, что и у другого пользователя (например, root).Эффективный идентификатор группы работает почти так же, сохраняя значение, отличное от поля gid, только если установлен бит установки идентификатора группы (SGID).

3.2.4.3. suid и sgid

suid (сохраненный идентификатор пользователя) и sgid (сохраненный идентификатор группы) используются в системных вызовах setuid().

3.2.4.4. fsuid и fsgid

Значения fsuid и fsgid проверяются специально для проверки файловой системы. Обычно они содержат те же значения, что и uid и gid, за исключением случаев, когда выполняется системный вызов setuid().

3.2.4.5. group_info

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

Структура group_info позволяет процессу ассоциироваться с рядом групп, связанных доступной памятью.На рисунке 3.5 вы можете видеть, что поле group_info с именем small_block представляет собой массив NGROUPS_SMALL (в нашем случае 32) единиц gid_t. Если задача принадлежит более чем 32 группам, ядро ​​может выделить блоки или страницы, которые содержат необходимое количество gid_ts за пределами NGROUPS_SMALL. Поле nblocks содержит количество выделенных блоков, а ngroups содержит значение единиц в массиве small_block, которые содержат значение gid_t.

3.2.5. Process CapabilitiesRelated Fields

Традиционно системы UNIX предлагают связанную с процессом защиту определенных доступов и действий, определяя любой данный процесс как привилегированный (суперпользователь или UID = 0) или непривилегированный (любой другой процесс).В Linux были введены возможности для разделения действий, ранее доступных только суперпользователю; то есть возможности — это индивидуальные «привилегии», которые могут быть предоставлены процессу независимо друг от друга и от его UID. Таким образом, определенным процессам может быть предоставлено разрешение на выполнение определенных административных задач без обязательного получения всех привилегий или обязательного владения суперпользователем. Таким образом, возможность определяется как заданная административная операция. Рисунок 3.6 показаны поля, относящиеся к возможностям процесса.

Рисунок 3.6. Возможности процессаСвязанные поля


3.2.5.1. cap_efficient, cap_inheritable, cap_permitted и keep_capabilities

Структура, используемая для поддержки модели возможностей, определена в include/linux/security.h как 32-битное значение без знака. Каждая 32-битная маска соответствует набору возможностей; каждой возможности назначается бит в каждом из:

  • cap_efficient.Возможности, которые в данный момент могут быть использованы процессом.

  • cap_inheritable. Возможности, которые передаются через вызов execve.

  • cap_permitted. Способности, которые можно сделать либо эффективными, либо наследуемыми.

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

    Таким образом, cap_efficient и cap_inheritable всегда являются подмножествами cap_permitted.

  • keep_capabilities. Отслеживает, прекратит ли процесс или сохранит свои возможности при вызове setuid().

В таблице 3.2 перечислены некоторые поддерживаемые возможности, определенные в include/linux/capability.h.

Capability Описание CAP_CHOWN CAP_FOWNER
Таблица 3.2. Выбранные возможности

Игнорирует ограничения, налагаемые Chown ()

игнорирует ограничения файлов разрешение

CAP_FSETID

игнорирует УИП и setgid ограничения на файлы

CAP_KILL

игнорирует RUID и euids при передаче сигналов

CAP_SETGID

игнорирует разрешения, связанные с группой

Ядро проверяет, задана ли определенная возможность, с помощью вызова enable(), передавая в качестве параметра переменную возможности.Как правило, функция проверяет, установлен ли бит возможности в наборе cap_efficient; если это так, он устанавливает флаги current-> в PF_SUPERPRIV, что указывает на то, что возможность предоставлена. Функция возвращает 1, если возможность предоставлена, и 0, если возможность не предоставлена.

С управлением возможностями связаны три системных вызова: capget(), capset() и prctl(). Первые два позволяют процессу получать и устанавливать свои возможности, а системный вызов prctl() позволяет манипулировать текущими->keep_capabilities.

3.2.6. Process LimitationsRelated Fields

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

3.2.6.1. rlim

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

Рис. 3.7. task_struct Ограничения ресурсов

Linux признает необходимость ограничения количества определенных ресурсов, которые разрешено использовать процессу. Поскольку виды и объемы ресурсов, которые могут использовать процессы, варьируются от процесса к процессу, необходимо хранить эту информацию для каждого процесса отдельно. Что может быть лучше, чем сохранить ссылку на него в дескрипторе процесса?

Дескриптор rlimit (include/linux/resource.h) содержит поля rlim_cur и rlim_max, которые являются текущим и максимальным ограничениями, применимыми к данному ресурсу.Предельные «единицы» зависят от типа ресурса, к которому относится структура.

 ------------------------------------------------ ----------------------- include/linux/resource.h struct rlimit { unsigned long rlim_cur; беззнаковое длинное rlim_max; }; -------------------------------------------------- --------------------- 

В таблице 3.3 перечислены ресурсы, для которых определены их ограничения в include/asm/resource.h. Однако и x86, и PPC имеют одинаковый список лимитов ресурсов и значения по умолчанию.

Размер файла размером 9 КБ.

90 Размер кучи.

Размер стека в байтах.

8 Размер файла дампа ядра.

Число процессов, принадлежащих этому процессу.

9005 Физическая память, которая не может быть заблокирована свопингом 8

.

Количество блокировок файлов.

Таблица 3.3. Ограничения ресурсов Значения

RL Название

Описание

По умолчанию rlim_cur

По умолчанию rlim_max

RLIMIT_CPU

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

RLIM_INFINITY

RLIM_INFINITY

RLIMIT_FSIZE

RLIM_INFINITY

RLIM_INFINITY

RLIMIT_DATA

RLIM_INFINITY

RLIM_INFINITY

RLIMIT_STACK

_STK_LIM

RLIM_INFINITY

RLIMIT_CORE

0

RLIM_INFINITY

RLIMIT_RSS

Максимальный размер резидентной памяти.

RLIM_INFINITY

RLIM_INFINITY

RLIMIT_NPROC

0

0

RLIMIT_NOFILE

Количество одновременно открытых файлов этим процессом.

INR_OPEN

INR_OPEN

RLIMIT_MEMLOCK

RLIM_INFINITY

RLIM_INFINITY

RLIMIT_AS

900 размер адресного пространства процесса.

RLIM_INFINITY

RLIM_INFINITY

RLIMIT_LOCKS

RLIM_INFINITY

RLIM_INFINITY

Если установлено значение RLIM_INFINITY, ресурс для этого процесса не ограничен.

Текущий лимит (rlim_cur) — это мягкий лимит, который можно изменить с помощью вызова setrlimit(). Максимальный предел определяется параметром rlim_max и не может быть превышен непривилегированным процессом. Системный вызов geTRlimit() возвращает значение лимитов ресурсов. И setrlimit(), и getrlimit() принимают в качестве параметров имя ресурса и указатель на структуру типа rlimit.

3.2.7. Поля, связанные с файловой системой и адресным пространством

Процессы могут активно работать с файлами на протяжении всего их жизненного цикла, выполняя такие задачи, как открытие, закрытие, чтение и запись. В структуре task_struct есть два поля, которые связаны с файлами и данными, относящимися к файловой системе: fs и files (подробности см. в главе 6, «Файловые системы»). Два поля, относящиеся к адресному пространству, это active_mm и mm (подробнее о mm_struct см. в Главе 4, «Управление памятью»). Рисунок 3.8 показаны поля, связанные с файловой системой и адресным пространством, в структуре task_struct.

Рисунок 3.8. Поля, связанные с файловой системой и адресным пространством


3.2.7.1. fs

Поле fs содержит указатель на информацию о файловой системе.

3.2.7.2. files

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

3.2.7.3. mm

mm указывает на информацию об адресном пространстве и управлении памятью.

3.2.7.4. active_mm

active_mm — это указатель на самое последнее доступное адресное пространство. Поля mm и active_mm начинают указывать на одну и ту же структуру mm_struct.

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

Что хранится в дескрипторе процесса? – QuickAdviser

Что хранится в дескрипторе процесса?

Дескриптор процесса содержит данные, описывающие выполняющуюся программу — открытые файлы, адресное пространство процесса, ожидающие сигналы, состояние процесса и многое другое (см. рис. 3.1).

Где хранится task_struct?

С точки зрения системы виртуальной памяти, структура task_struct выделяется распределителем Slab, поэтому она находится в пространстве ядра.

Где хранится состояние процесса в Linux?

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

Как происходит выделение и хранение дескриптора процесса в управлении процессами?

Выделение дескриптора процесса Структура task_struct выделяется с помощью распределителя slab для обеспечения повторного использования объектов и раскрашивания кэша (см. главу 11, «Управление памятью»).До версии ядра 2.6 структура task_struct хранилась в конце стека ядра каждого процесса.

Что такое дескриптор процесса в Linux?

В Linux дескриптор процесса — это экземпляр типа struct task_struct, определенный в /sched. h> , это одна из центральных структур данных, содержащая все атрибуты, идентификационные данные и записи о распределении ресурсов, хранящиеся в процессе.

Также известен как дескриптор процесса?

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

Что такое thread_info Почему он хранится в конце стека ядра?

Отсутствовало понятие структуры thread_info. Но в ядре Linux 2.6 вместо того, чтобы task_struct помещалась в конец стека ядра для процесса, в конец помещалась структура thread_info. Эта структура thread_info содержит указатель на структуру task_struct.

Что такое thread_info в Linux?

thread_info: данные задачи низкого уровня, напрямую. доступ из entry.S. стек ядра: рабочее пространство для системных вызовов (ядро выполняется от имени пользовательского процесса) или обработчиков прерываний.

Как процесс запускается в Linux?

При выполнении программы/команды система предоставляет процессу специальный экземпляр. Этот экземпляр состоит из всех сервисов/ресурсов, которые могут использоваться исполняемым процессом.Всякий раз, когда команда выдается в Unix/Linux, она создает/запускает новый процесс.

Какие типы процессов существуют в Linux?

Существует два типа процесса Linux: обычный и в режиме реального времени. Процессы реального времени имеют более высокий приоритет, чем все остальные процессы. Если есть процесс реального времени, готовый к запуску, он всегда будет запускаться первым. Процессы реального времени могут иметь два типа политик: циклический алгоритм и метод «первым пришел — первым обслужен».

Где найти дескриптор процесса в Linux?

Ядро хранит список процессов в кольцевом двусвязном списке, называемом списком задач 3.Каждый элемент в списке задач является дескриптором процесса типа struct task_struct, который определен в . Дескриптор процесса содержит всю информацию о конкретном процессе.

Как дескриптор процесса помогает ядру?

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

Из чего состоит таблица процессов в Linux?

Таблица процессов содержит идентификаторы процессов, использование памяти процессом, какие файловые дескрипторы используются в процессе и т. д. Ядро отслеживает созданный и запущенный процесс с помощью дескриптора процесса. Каждый дескриптор процесса содержит: 1. Идентификатор – идентификатор процесса, идентификатор родительского и дочернего процесса, идентификатор пользователя 2. Состояние – состояние процесса, приоритет 3.

Что такое адресные пространства процессов в ядре Linux?

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

управление памятью. Где хранится дескриптор процесса linux и что может получить к нему доступ?

В Linux «дескриптор процесса» — это struct task_struct [и некоторые другие].Они хранятся в адресном пространстве ядра [выше PAGE_OFFSET ] и , а не в пользовательском пространстве.

Это больше относится к 32-битным ядрам, где PAGE_OFFSET имеет значение 0xc0000000.

В 32-битном ядре виртуальное адресное пространство пользовательского процесса было ограничено до PAGE_OFFSET

64-битные ядра несколько отличаются, и ограничение не имеет большого значения. PAGE_OFFSET равно 0xffff880000000000

Кроме того, ядро ​​имеет собственное отображение адресного пространства.

Каждый процесс/поток имеет собственное виртуальное адресное пространство, которое, за исключением общей памяти для библиотек .so и общей памяти для потоков, уникально. Это , а не сопоставляется с чем-либо в адресном пространстве ядра.

Даже с [если бы] было общее сопоставление адресного пространства, страницы ядра защищены от чтения/записи от пользовательского процесса.


Связанный вопрос:

Это действительно два вопроса

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

Нет. Это может быть сделано , а не по нескольким причинам.

Только ядро ​​имеет доступ (т. е. «знает») к адресу task_struct .

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

Однако task_struct довольно велик.Таким образом, когда процесс входит в режим зомби, ядро ​​захватывает маленькую часть данных task_struct (например, pid и status ) и сохраняет их в структуре «зомби». Затем ядро ​​может почти сразу же повторно использовать task_struct [с использованием другого pid ].

Например, в то время как процесс с pid 37 может иметь структуру задачи по адресу (например) 0x1000 во время его работы, после завершения, но до сбора данных, pid 37 имеет адрес структуры задачи , а структура задачи по адресу 0x1000 может уже назначен pid 23727

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

И снова нет.

unix — Что такое файловые дескрипторы, объясняемые простыми словами?

Другие ответы добавили отличные вещи. Я добавлю только свои 2 цента.

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

Файловые дескрипторы привязаны к идентификатору процесса.

Мы знаем, что самые известные файловые дескрипторы — это 0, 1 и 2. 0 соответствует STDIN , 1 соответствует STDOUT и 2 соответствует STDERR .

Скажем, взять в качестве примера процессы оболочки и как это применимо к нему?

Проверьте этот код

  #>сон 1000 &
[12] 14726
  

Мы создали процесс с идентификатором 14726 (PID). Используя lsof -p 14726 , мы можем получить такие вещи:

  КОМАНДА PID ПОЛЬЗОВАТЕЛЬ FD ТИП УСТРОЙСТВО РАЗМЕР/ВЫКЛ НАЗВАНИЕ УЗЛА
спящий 14726 root cwd DIR 8,1 4096 1201140 /home/x
sleep 14726 root rtd DIR 8,1 4096 2 /
сон 14726 root txt REG 8,1 35000 786587 /bin/sleep
sleep 14726 root mem REG 8,1 11864720 1186503 /usr/lib/locale/locale-archive
sleep 14726 корневая память REG 8,1 2030544 137184 /lib/x86_64-linux-gnu/libc-2.27.так
sleep 14726 root mem REG 8,1 170960 137156 /lib/x86_64-linux-gnu/ld-2.27.so
сон 14726 корень 0u CHR 136,6 0t0 9 /dev/pts/6
сон 14726 корень 1u CHR 136,6 0t0 9 /dev/pts/6
сон 14726 корень 2u CHR 136,6 0t0 9 /dev/pts/6
  

4-й столбец FD и следующий за ним столбец TYPE соответствуют дескриптору файла и типу дескриптора файла.

Некоторые значения FD могут быть:

  cwd — текущий рабочий каталог
txt — текстовый файл
mem — файл с отображением памяти
mmap — устройство с отображением памяти
  

Но реальный дескриптор файла находится под:

  ЧИСЛО — представляет фактический файловый дескриптор. 

Символ после числа, т.е. «1u», представляет режим, в котором открыт файл. r для чтения, w для записи, u для чтения и записи.

TYPE определяет тип файла. Некоторые из значений TYPE:

  REG — обычный файл
ДИР – Каталог
FIFO – первый пришел первый ушел
  

Но все файловые дескрипторы CHR — Специальный символьный файл (или файл символьного устройства)

Теперь мы можем легко идентифицировать дескрипторы файлов для STDIN , STDOUT и STDERR с помощью lsof -p PID , или мы можем увидеть то же самое, если мы ls /proc/PID/fd .

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

Вы можете спросить себя, где физически находятся эти файловые дескрипторы и что хранится в /dev/pts/6 например

  сон 14726 корень 0u CHR 136,6 0t0 9 /dev/pts/6
сон 14726 корень 1u CHR 136,6 0t0 9 /dev/pts/6
сон 14726 корень 2u CHR 136,6 0t0 9 /dev/pts/6
  

Ну а /dev/pts/6 живет чисто в памяти.Это не обычные файлы, а так называемые -символьные файлы устройств . Вы можете проверить это с помощью: ls -l /dev/pts/6 и они будут начинаться с c , в моем случае crw--w---- .

Просто напомню, что большинство Linux-подобных ОС определяют семь типов файлов:

  • Обычные файлы
  • Каталоги
  • Файлы символьных устройств
  • Блокировать файлы устройств
  • Сокеты локального домена
  • Именованные каналы (FIFO) и
  • Символические ссылки

Проект документации Linux


Информация о ЛДП
Часто задаваемые вопросы
Манифест/лицензия
История
Волонтеры/персонал
Должностные инструкции
Списки рассылки
ИРК
Обратная связь

Автор / вклад
Руководство для авторов LDP
Поддержите / помогите
Ресурсы
Как отправить
  GIT-репозиторий
Скачано
Контакты

Спонсор сайта LDP
Мастерская

Вики LDP : LDP Wiki — это точка входа для любой незавершенной работы
Участники | Авторы | Посетители
Документы

HOWTO : тематическая помощь
последние обновления | основной индекс | просматривать по категориям
Направляющие : более длинные, подробные книги
последние обновления / основной индекс
Часто задаваемые вопросы : Часто задаваемые вопросы
последние обновления / основной индекс
справочные страницы : помощь по отдельным командам (20060810)
Газета Linux : интернет-журнал
Поиск/Ресурсы

  Ссылки
Поиск OMF
Объявления / Разное


Обновления документов
Ссылка на HOWTO, которые были недавно обновлены.

LinkinWiki

Laboratorio de Investigación en Nuevas Tecnologías Informáticas

Быстрая эволюция технологий аппаратного обеспечения, лас-редес-де-датос и эль-использование программного обеспечения, контраста с эль-хэхо-де-дие-эль-диссено дель ядра и лос-механизмов, которые реализуют защиту и виртуализацию лос-рекурсов, ан лос-системы операционные, no hayan tenido avances significativos en las últimas tres décadas.

Esta line de Investigacion se enfoca en identificar, Proponer y Evaluar nuevas características relacionadas con la performance y escalabilidad del kernel Linux, teniendo en cuenta los nuevos desafíos que presentan las arquitecturas multicore y la computación centrada en las redes a los redes a los приблизительное поколение.


Новые технологии виртуализации

Recientemente, душ nuevas técnicas де виртуализации хан logrado un nivel де производительности sorprendente с уважением а-ля производительность en la ejecución nativa.Паравиртуализация и виртуализация помогают аппаратным средствам, разделенным или объединенным (виртуализация), се позиционируется как новая капа де абстракции, которая является революцией в структуре центров вычислительных ресурсов и консолидации аппаратных средств, мэром Нивели де сегуридад. , la reducción en el uso de energía, la migracion de hosts virtuales sin interrumpir los servicios и т.д. многоядерные технологии.

Estamos encarando un nuevo proyecto que претендует на демонстрацию las ventajas de escribir un sistema operativo diseñado específicamente para ejecutarse sobre un hypervisor (Lguest).


Ядро asimétrico y activo

Ядро активируется как эволюция вертикальной модели ядра и поддерживает выделенные процессоры или ядра, реализуя исключительную активность ядра. Al ser un agente activo, es posible que el kernel se comunique con el hardware y el espacio de usuario utilizando mecanismos alternativos, menos costosos que los Actuales (прерывания аппаратного и программного обеспечения).Nuestro trabajo se centra en el estudio de las posibilidades que ofrecen estos conceptos en el tratamiento de la entrada/salida de red. Нарушение эмбарго, возможность идентификации приложений в других доменах (виртуализация, реальное время и т. д.).


Llamadas al sistema asincrónicas y basadas en memoria compartida

La semántica de pasaje de parametros puede tener un impacto significativo en la eficiencia de la transferencia de datos entre el kernel y las aplicaciones.Линия работы с центрами идей, альтернативно ориентированных на увеличение эффективности ядра Linux в процессе ввода/вывода, взаимосвязь между основными возможностями реализации операций векторизации (lo que que farece las operaciones scatter-gather) y utilizando memoria compartida entre el ядро у эль espacio де usuario, пункт evitar лас копиас físicas en memoria де ип доминио де protección аль otro. Además, пункт lograr мэра escalabilidad, evitando эль накладные расходы дие имплика эль планирования де великих cantidades де потоков, SE están Evaluando APIs дие poseen una semántica де entrada/salida asincrónica para operaciones де сокеты y archivos.

Артикулос

слайдов, глава 6 Понимание ядра Linux 3

слайдов Capitulo 5 Понимание ядра Linux 3

слайдов Capitulo 4 Понимание ядра Linux 3

слайдов Capitulo 3 Понимание ядра Linux 3

слайдов Capitulo 2 Понимание ядра Linux 3

введение в материал SOs (UNNOBA), который используется в ядре Linux в качестве учебного материала

слайдов, посвященных новым технологиям виртуализации

слайдов о введении в ядро ​​Linux

слайдов архитектуры ядра Linux

слайды, которые объясняют механизмы ядра usados ​​en redes de alta velocidad

отчет о взаимосвязи сетки и виртуализации

слайдов lguest (пример реализации гипервизора)

Informe Hardware Assisted Virtualization — Intel VMX (на английском языке)

бумага джайио 36

бумага wicc 2007

бумага wicc 2006

Курс повышения квалификации: Производительность и расширение ядра Linux для приложений с высокой скоростью

Informe Checkpoint/Restart de procesos

Informe Supercomputadoras топ 500

Informe Concurrencia y Sincronización в ядре Linux

Уведомление о буферах ввода данных в GNU/Linux

Информация о сжатии файловой системы для флэш-памяти — OLPC

 место строительства
                   контакт: матиаш (AT) info.unlp.edu.ar
 

Что такое файловый дескриптор?

Обновлено: 13.03.2021 автором Computer Hope

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

Когда программа запрашивает открытие файла или другого ресурса данных, например сетевого сокета, ядро:

  1. Предоставляет доступ.
  2. Создает запись в глобальной таблице файлов.
  3. Предоставляет программе местонахождение этой записи.

Дескриптор определяется уникальным неотрицательным целым числом, например 0, 12 или 567. Для каждого открытого файла в системе существует по крайней мере один файловый дескриптор.

Файловые дескрипторы были впервые использованы в Unix и используются современными операционными системами, включая Linux, macOS и BSD. В Microsoft Windows дескрипторы файлов называются дескрипторами файлов.

Обзор

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

Стандартный ввод, стандартный вывод и стандартный вывод

В Unix-подобных операционных системах первыми тремя файловыми дескрипторами по умолчанию являются STDIN (стандартный ввод), STDOUT (стандартный вывод) и STDERR (стандартная ошибка).

Имя Дескриптор файла Описание Аббревиатура
Стандартный ввод 0 Поток данных по умолчанию для ввода, например, в конвейер команд.В терминале по умолчанию используется ввод с клавиатуры пользователем. стандартный номер
Стандартный выход 1 Поток данных по умолчанию для вывода, например, когда команда печатает текст. В терминале по умолчанию это экран пользователя. стандартный вывод
Стандартная ошибка 2 Поток данных по умолчанию для вывода, относящегося к возникшей ошибке.В терминале по умолчанию это экран пользователя. стдерр

Перенаправление файловых дескрипторов

Доступ к файловым дескрипторам можно получить напрямую с помощью bash, стандартной оболочки Linux, macOS X и подсистемы Windows для Linux.

Например, при использовании команды find успешный вывод отправляется на стандартный вывод (файловый дескриптор 1), а сообщения об ошибках отправляются на стандартный вывод (файловый дескриптор 2). Оба потока отображаются как вывод терминала:

 найти/-имя '*что-то*' 
 /usr/доля/документ/что-то
/usr/share/doc/something/examples/something_random
find: `/run/udisks2': Отказано в доступе
find: `/run/wpa_supplicant': Отказано в доступе
/USR/доля/что-то
/usr/игры/что-то 

Мы получаем ошибки, потому что find пытается выполнить поиск в нескольких системных каталогах, для чтения которых у нас нет прав.Все строки с надписью «Отказано в доступе» были записаны в stderr, а остальные строки были записаны в stdout.

Вы можете скрыть stderr, перенаправив файловый дескриптор 2 на /dev/null, специальное устройство в Linux, которое «никуда не ведет»:

 найти / -name '*что-то*' 2>/dev/null 
 /usr/доля/документ/что-то
/usr/share/doc/something/examples/something_random
/USR/доля/что-то
/usr/игры/что-то 

Ошибки отправлены в /dev/null и не отображаются.

Понимание разницы между stdout и stderr важно, когда вы хотите работать с выводом программы. Например, если вы попытаетесь выполнить grep вывод команды find, вы заметите, что сообщения об ошибках не фильтруются, потому что в grep передаются только стандартные выходные данные.

 найти / -name '*что-то*' | grep 'что-то' 
 /usr/доля/документ/что-то
/usr/share/doc/something/examples/something_random
find: `/run/udisks2': Отказано в доступе
find: `/run/wpa_supplicant': Отказано в доступе
/USR/доля/что-то
/usr/игры/что-то 

Однако вы можете перенаправить стандартную ошибку на стандартный вывод, и тогда grep обработает оба текста:

 find / -name '*something*' 2>&1 | grep 'что-то' 
 /usr/доля/документ/что-то
/usr/share/doc/something/examples/something_random
/USR/доля/что-то
/usr/игры/что-то 

Обратите внимание, что в приведенной выше команде дескриптор целевого файла (1) имеет префикс амперсанда («&»).

Добавить комментарий

Ваш адрес email не будет опубликован.