Министерство транспорта РФ

Федеральное агентство железнодорожного транспорта

ГОУ ВПО "ДВГУПС"

Кафедра: "Информационные технологии и системы"

на тему: "Подсистема управления процессами"

Выполнил: Шолков И.Д.

группа 230

Проверил: Решетникова О.В.

Хабаровск 2010

Введение

1. Описание программы

1.1 Функциональное назначение

1.2 Технические средства, используемые при создании программы

1.3 Многопоточность и многопроцессорность

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

1.5 Способы синхронизации потоков

1.3 Логическая структура программы

2. Руководство пользователя по работе с программой

2.1 Общие сведения и назначение программы

2.2 Графический интерфейс

2.3 Работа с программой

2.4 Основные характеристики программы ProcessManager

Заключение

Список литературы

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

Программа на C# запускается как единственный поток, автоматически создаваемый CLR и операционной системой ("главный" поток), и становится многопоточной при помощи создания дополнительных потоков.

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

На однопроцессорных компьютерах планировщик потоков использует квантование времени – быстрое переключение между выполнением каждого из активных потоков. Это приводит к непредсказуемому поведению, как в самом первом примере, где каждая последовательность символов ‘X’ и ‘Y’ соответствует кванту времени, выделенному потоку. В Windows XP типичное значение кванта времени – десятки миллисекунд – выбрано как намного большее, чем затраты CPU на переключение контекста между потоками (несколько микросекунд).

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

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

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

В некоторых аспектах потоки и процессы схожи – например, время разделяется между процессами, исполняющимися на одном компьютере, так же, как между потоками одного C#-приложения. Ключевое различие состоит в том, что процессы полностью изолированы друг от друга. Потоки разделяют память (кучу) с другими потоками этого же приложения. Благодаря этому один поток может поставлять данные в фоновом режиме, а другой – показывать эти данные по мере их поступления.

Свойство Priority определяет, сколько времени на исполнение будет выделено потоку относительно других потоков того же процесса. Существует 5 градацийприоритетапотока:enum ThreadPriority { Lowest, BelowNormal, Normal, AboveNormal, Highest }

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

Установка приоритета потока на максимум еще не означает работу в реальном времени (real-time), так как существуют еще приоритет процесса приложения. Чтобы работать в реальном времени, нужно использовать класс Process из пространства имен System.Diagnostics для поднятия приоритета процесса.

От ProcessPriorityClass.High один шаг до наивысшего приоритета процесса – Realtime. Устанавливая приоритет процесса в Realtime, вы говорите операционной системе, что хотите, чтобы ваш процесс никогда не вытеснялся. Если ваша программа случайно попадет в бесконечный цикл, операционная система может быть полностью заблокирована. Спасти вас в этом случае сможет только кнопка выключения питания. По этой причине ProcessPriorityClass.High считается максимальным приоритетом процесса, пригодным к употреблению.

Если real-time приложение имеет пользовательский интерфейс, может быть не желательно поднимать приоритет его процесса, так как обновление экрана будет съедать чересчур много времени CPU – тормозя весь компьютер, особенно если UI достаточно сложный.

Оператор lock (aka Monitor.Enter/Monitor.Exit) – один из примеров конструкций синхронизации потоков. Lock является самым подходящим средством для организации монопольного доступа к ресурсу или секции кода, но есть задачи синхронизации (типа подачи сигнала начала работы ожидающему потоку), для которых lock будет не самым адекватным и удобным средством.

В Win32 API имеется богатый набор конструкций синхронизации, и они доступны в.NET Framework в виде классов EventWaitHandle, Mutex и Semaphore. Некоторые из них практичнее других: Mutex, например, по большей части дублирует возможности lock, в то время как EventWaitHandle предоставляет уникальные возможности сигнализации.

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

EventWaitHandle имеет два производных класса – AutoResetEvent и ManualResetEvent (не имеющие никакого отношения к событиям и делегатам C#). Обоим классам доступны все функциональные возможности базового класса, единственное отличие состоит в вызове конструктора базового класса с разными параметрами.

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

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

AutoResetEvent очень похож на турникет – один билет позволяет пройти одному человеку. Приставка "auto" в названии относится к тому факту, что открытый турникет автоматически закрывается или "сбрасывается" после того, как позволяет кому-нибудь пройти. Поток блокируется у турникета вызовом WaitOne (ждать (wait) у данного (one) турникета, пока он не откроется), а билет вставляется вызовом метода Set. Если несколько потоков вызывают WaitOne, за турникетом образуется очередь. Билет может "вставить" любой поток – другими словами, любой (неблокированный) поток, имеющий доступ к объекту AutoResetEvent, может вызвать Set, чтобы пропустить один блокированный поток.

Если Set вызывается, когда нет ожидающих потоков, хэндл будет находиться в открытом состоянии, пока какой-нибудь поток не вызовет WaitOne. Эта особенность помогает избежать гонок между потоком, подходящим к турникету, и потоком, вставляющим билет ("опа, билет вставлен на микросекунду раньше, очень жаль, но вам придется подождать еще сколько-нибудь!"). Однако многократный вызов Set для свободного турникета не разрешает пропустить за раз целую толпу – сможет пройти только один человек, все остальные билеты будут потрачены впустую.

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

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

AutoResetEvent может быть создан двумя путями. Во-первых, с помощью своего конструктора:EventWaitHandle wh = new AutoResetEvent(false);

Если аргумент конструктора true, метод Set будет вызван автоматически сразу после создания объекта.

Другой метод состоит в создании объекта базового класса, EventWaitHandle:EventWaitHandle wh = new EventWaitHandle(false, EventResetMode.Auto);

Конструктор EventWaitHandle также может использоваться для создания объекта ManualResetEvent (если задать в качестве параметра EventResetMode.Manual).

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

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

Эту функциональность можно эмулировать при помощи булевой переменной "gateOpen" (объявленной как volatile) в комбинации со "spin-sleeping" – повторением проверок флага и ожидания в течении короткого промежутка времени.

ManualResetEvent может использоваться для сигнализации о завершении какой-либо операции или инициализации потока и готовности к выполнению работы.

1.3 Логическая структура программы

Основу программы составляет абстрактный класс Betaproc. В нем реализована абстрактная модель процесса, без спецификации выполняемых действий, с набором переменных и методов общих для всех процессов. Три процесса sinProc, FibbonProc и ProcRandom являются производными от этого класса и в каждом из них реализован лишь методы возвращающие тип процесса и сам метод выполняемый процессом. При этом каждый метод Base, в котором находится исполняемый код, имеет в своем теле общий для всех хэндл, который позволяет выполнять код лишь одному процессу, когда другие становятся в очередь и получают свое время на выполнение пропорционально приоритету. В момент начала работы стартует таймер, который обеспечивает одинаковый квант времени в 3 секунды для каждого процесса.

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

2. Руководство пользователя по работе с программой

2.1 Общие сведения и назначение программы

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

2.2 Графический интерфейс

После открытия программы пользователю предоставляется графический интерфейс.

рис 1.: главное окно программы после запуска

Область "Процесс" позволяет выбрать тот процесс, который нам необходимо запустить. Имеет три пункта: Числа Фибоначчи, Случайные числа и Рекурсивный синус.

Область "Приоритет" позволяет установить приоритет запускаемому процессу. Имеет 5 пунктов: Низкий, Ниже среднего, Средний, Выше среднего, Высокий.

Кнопка запуск служит для запуска процесса с выбранными параметрами.

Таблица в центральной части окна отображает состояние каждого из запущенных процессов. После добавления каждого процесса в нее автоматически добавляется одна строка. Имеет 5 полей:

1) Номер процесса – показывает порядковый номер процесса

2) Тип процесса – показывает действие, с которое выполняет данный процесс

3) Состояние процесса – показывает работает ли процесс в данный момент или нет. Также показывает, если процесс является остановленным, завершенным или только что возобновленным.

4) Приоритет процесса – показывает приоритет процесса, который был присвоен ему при создании.

5) Процент процессорного времени – отображает процент используемого процессорного времени.

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

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

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

Кнопка "Возобновить" - вновь запускает остановленный процесс.

Кнопка "Завершить" - останавливает выбранный процесс без возможности его завершения.

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

2.3 Работа с программой

Запуск процессов выполняется с помощью кнопки "Запустить", однако перед этим следует установить параметры процесса.

Случайное число – процесс генерирует случайное число в интервале от одного до ста и выводит его в поле вывода.

Числа Фибоначчи – генерирует последовательность Фибоначчи, начиная с первого члена, и выводит их в поле вывода. Как только значение чисел последовательности превосходит тысячу – значения сбрасываются до первых членов.

Рекурсивный синус – генерирует значение синуса X. Первоначально X равен 1, позже ему присваиваются посчитанные значения sin(x). Значения, округленные до третьего знака выводятся в поле вывода.

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

После запуска нескольких процессов окно программы примет следующий вид:

рис 2: работа программы.

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

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

рис. 3: процесс с Process ID = 2 остановлен.

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

Процесс, который вновь начал работу, но еще ни разу не выполнялся отмечается подписью "Возобновлен" в третьем столбце, как на картинке:

рис. 4: работа процесса с Process ID = 2 возобновлена.

Если мы захотим завершить процесс, под номером 3, необходимо выбрать третью строку в таблице процессов и нажать кнопку "Завершить". Процесс, который завершен уже не может быть запущен вновь. Создайте процесс с такими же параметрами.

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

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

2.4 Основные характеристики программы Process Manager

ProcessManager – это программа, предназначенная для управления процессами пользователем персонального компьютера. Она работает под управлением операционных систем MS Windows 2000/XP/Vista/7.

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

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

Заключение

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

Список литературы

1) Безбогов, А.А. Безопасность операционных систем: учебное пособие / А.А. Безбогов, А.В. Яковлев, Ю.Ф. Мартемьянов. – М. : "Издательство Машиностроение-1", 2007. – 220 с.

2) Операционные системы, лекции по операционным системам [Электронный ресурс] / www.osi-ru.ru. - Содержание: Управление процессами; Управление памятью; Управление данными; Управление устройствами

3) Троелсен, Э. C# и платформа.NET: учебное пособие/ Э.Троелсен. – Спб. : "Питер Пресс", 2007. –796с.

Приложение

Исходный код программы ProcessManager

using System.Diagnostics;

using System.Linq;

using System.Text;

using System.Threading;

using System.Windows.Forms;

using Timer=System.Threading.Timer;

namespace ProcManager

abstract class BetaProc

protected Thread a;

bool isWorking = false;

public event EventHandler WorkingStateChanged = delegate { };

public bool IsWorking

get { return isWorking; }

isWorking = value;

WorkingStateChanged(this, EventArgs.Empty);

public void Delete()

if (IsWorking == true)

if (WaitToStart.Set() == false)

WaitToStart.Set();

public ThreadPriority Prior

get { return a.Priority; }

set { a.Priority = value; }

public void Stop()

if(isWorking == true)

WaitToStart.Set();

private DataGridView data;

public delegate void ChangeStateEventHandler(string msg);

public static event ChangeStateEventHandler change;

public abstract string GetType();

public string GetState()

return IsWorking ? "Работает" : "Не работает";

public string GetPriority()

return a.Priority.ToString();

public void ChangeState()

if (IsWorking == false)

IsWorking = true;

IsWorking = false;

public abstract void Base();

private Control pReporter;

public DataGridView reporterD

public Control reporter

return pReporter;

pReporter = value;

public EventWaitHandle SwaitTostart

WaitToStart = value;

protected Stopwatch timer = new Stopwatch();

public void Start()

a = new Thread(Base);

delegate void SetTextDelegate2(string Text);

public static EventWaitHandle WaitToStart;

public void SetText2(string Text)

if (reporter.InvokeRequired)

SetTextDelegate2 a = new SetTextDelegate2(SetText2);

reporter.Invoke(a, new object { Text });

else reporter.Text += Text;

public void Restart()

if(isWorking == true)

timer = new Stopwatch();

a=new Thread(Base);

using System.Collections.Generic;

using System.Diagnostics;

using System.Linq;

using System.Text;

using System.Threading;

namespace ProcManager

class FibbonProc:BetaProc

public readonly string Type = "ЧислаФиббоначи";

private int FSum = 1;

private int FSum2 = 1;

private int temp = 0;

public override void Base()

WaitToStart.WaitOne();

if (IsWorking == false)

if (FSum >= 1000)

FSum = FSum + FSum2;

SetText2(FSum.ToString() + "\r\n");

Thread.Sleep(1110);

<= 3000);

WaitToStart.Set();

using System.Collections.Generic;

using System.Diagnostics;

using System.Linq;

using System.Text;

using System.Threading;

namespace ProcManager

class ProcRandom:BetaProc

Random a = new Random();

private int res;

public readonly string Type = "Случайноечисло";

public override string GetType()

public override void Base()

WaitToStart.WaitOne();

if (IsWorking == false)

res = a.Next(100);

SetText2(res.ToString()+"\r\n");

Thread.Sleep(1110);

while (timer.ElapsedMilliseconds <= 3000);

WaitToStart.Set();

using System.Collections.Generic;

using System.Diagnostics;

using System.Linq;

using System.Text;

using System.Threading;

namespace ProcManager

class SinProc:BetaProc

private double x = 1;

public readonly string Type = "Синус X";

public override string GetType()

public override void Base()

WaitToStart.WaitOne();

if(IsWorking == false)

x = Math.Sin(x);

SetText2(Math.Round(x, 3).ToString()+"\r\n");

Thread.Sleep(1110);

while (timer.ElapsedMilliseconds <= 3000);

WaitToStart.Set();

using System.Collections;

using System.Threading;

using System.Windows.Forms;

namespace ProcManager

class ClassProcManager

private BetaProc mas = new BetaProc;

private DataGridView a;

private int index = 0;

public BetaProc ReturnMas()

public int Index()

public DataGridView reporterD

public void AddThread(BetaProc a)

if (index < mas.Length)

MessageBox.Show("Слишком много процессов");

public void ShowInDataView(BetaProc b)

a.Rows.Add(index + 1, b.GetType(), b.GetState(), b.GetPriority());

public void SetWaitProperty(BetaProc b)

int i = Array.IndexOf(mas, b);

if((i<0) || (i>a.Rows.Count - 1))

for (int s = 0; s < index; s++)

if ((int)a.Rows[s].Cells.Value == i+1)

DataGridViewRow row = a.Rows[s];

row.Cells.Value = b.GetState();

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Diagnostics;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Threading;

using System.Windows.Forms;

namespace ProcManager

public partial class Form1: Form

InitializeComponent();

public int index = 0;

private ClassProcManager manager = new ClassProcManager();

private EventWaitHandle wh1 = new AutoResetEvent(true);

private RadioGroup processType;

private RadioGroup processPriority;

private ThreadPriority ProcessPriorities = new ThreadPriority;

ThreadPriority HighestPriority = ThreadPriority.Lowest;

///

/// Tag

/// Объектизперечисления ThreadPriority

private ThreadPriority IndexToPriority(int priority)

switch (priority)

case 0: return ThreadPriority.Lowest;

case 1: return ThreadPriority.BelowNormal;

case 2: return ThreadPriority.Normal;

case 3: return ThreadPriority.AboveNormal;

case 4: return ThreadPriority.Highest;

default: return ThreadPriority.Normal;

private void button1_Click(object sender, EventArgs e)

BetaProc process;

switch (processType.SelectedButton)

case 0: process = new FibbonProc();

case 1: process = new ProcRandom();

case 2: process = new SinProc();

default: process = new ProcRandom();

process.SwaitTostart = wh1;

process.reporter = richTextBox1;

process.reporterD = dataGridView1;

process.Start();

process.Prior = IndexToPriority(processPriority.SelectedButton);

manager.AddThread(process);

manager.ShowInDataView(process);

process.WorkingStateChanged += new EventHandler(a_WorkingStateChanged);

// расчётпроцессорноноговремени

if (process.Prior > HighestPriority) HighestPriority = process.Prior;

ProcessPriorities = process.Prior;

if (index >= 1)

double FreeProcessorTime = 100;

double TimePerProcess = 100 / (index + 1);

double PriorityWeight = 0;

int HighPriorityProcessCount = 0;

// расчётдляпроцессовсприоритетомнижесамогобольшого

for (int i = 0; i < index + 1; i++)

if (ProcessPriorities[i] != HighestPriority)

switch (ProcessPriorities[i])

case ThreadPriority.Lowest: PriorityWeight = 0.2;

case ThreadPriority.BelowNormal: PriorityWeight = 0.4;

case ThreadPriority.Normal: PriorityWeight = 0.6;

case ThreadPriority.AboveNormal: PriorityWeight = 0.8;

FreeProcessorTime -= TimePerProcess * PriorityWeight;

dataGridView1.Rows[i].Cells.Value = Math.Round(TimePerProcess * PriorityWeight);

else HighPriorityProcessCount++;

// расчёт для процессов с самым большим приоритетом

for (int i = 0; i < index + 1; i++)

if (ProcessPriorities[i] == HighestPriority)

dataGridView1.Rows[i].Cells.Value = Math.Round(FreeProcessorTime / HighPriorityProcessCount);

else dataGridView1.Rows.Cells.Value = "100";

void a_WorkingStateChanged(object sender, EventArgs e)

BetaProc b = sender as BetaProc;

manager.SetWaitProperty(b);

private void Form1_Load(object sender, EventArgs e)

manager.reporterD = dataGridView1;

// Заполняем RadioGroup processType и processPriority объектами RadioButton

RadioButton processTypeRadioButtons = new RadioButton;

for (int i = 0; i < groupBox1.Controls.Count; i++) processTypeRadioButtons[i] = (RadioButton)groupBox1.Controls[i];

RadioButton processPriorityRadioButtons = new RadioButton;

for (int i = 0; i < groupBox2.Controls.Count; i++) processPriorityRadioButtons[i] = (RadioButton)groupBox2.Controls[i];

processType = new RadioGroup(processTypeRadioButtons);

processPriority = new RadioGroup(processPriorityRadioButtons);

private void button2_Click(object sender, EventArgs e)

if (processID != -1 && (string)manager.reporterD.Rows.Cells.Value != "Завершен")

manager.ReturnMas().Stop();

manager.reporterD.Rows.Cells.Value = "Приостановлен";

private void button3_Click(object sender, EventArgs e)

int processID = (int)dataGridView1.SelectedRows.Cells.Value - 1;

if ((string)manager.reporterD.Rows.Cells.Value == "Приостановлен")

manager.ReturnMas().Restart();

manager.reporterD.Rows.Cells.Value = "Возобновлен";

private void button4_Click(object sender, EventArgs e)

int processID = (int)dataGridView1.SelectedRows.Cells.Value - 1;

if (processID != -1)

manager.ReturnMas().Delete();

manager.reporterD.Rows.Cells.Value = "Завершен";

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

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

обеспечение процессов и потоков необходимыми ресурсами;

изоляция процессов ;

планирование выполнения процессов и потоков (вообще, следует говорить и о планировании заданий);

диспетчеризация потоков;

организация межпроцессного взаимодействия;

синхронизация процессов и потоков;

завершение и уничтожение процессов и потоков.

1. К созданию процесса приводят пять основных событий:

выполнение запроса работающего процесса на создание процесса;

запрос пользователя на создание процесса, например, при входе в систему в интерактивном режиме;

инициирование пакетного задания;

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

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

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

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

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

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

5. Диспетчеризация заключается в реализации найденного в результате планирования решения, т.е. в переключении процессора с одного потока на другой. Диспетчеризация проходит в три этапа:

сохранение контекста текущего потока;

запуск нового потока на выполнение.

6. Когда в системе одновременно выполняется несколько независимых задач, возникают дополнительные проблемы. Хотя потоки возникают и выполняются синхронно, у них может возникнуть необходимость во взаимодействии , например, при обмене данными. Для общения друг с другом процессы и потоки могут использовать широкий спектр возможностей: каналы (в UNIX ), почтовые ящики (Windows ), вызов удаленной процедуры, сокеты (в Windows соединяют процессы на разных машинах). Согласование скоростей потоков также очень важно для предотвращения эффекта "гонок" (когда несколько потоков пытаются изменить один и тот же файл ), взаимных блокировок и других коллизий, которые возникают при совместном использовании ресурсов.

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

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

• Создание и удаление процессов
• Распределение системных ресурсов (памяти, вычислительных ресурсов) между процессами
• Синхронизацию процессов
• Межпроцессное взаимодействие

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

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

Основы управления процессом

• Stack (c тек ) - область памяти, в которой программа хранит информацию о вызываемых функциях, их аргументах и каждой локальной переменной в функциях. Размер области может меняться по мере работы программы. При вызове функций стек увеличивается, а при завершении - уменьшается.
• Heap (к уча ) - это область памяти, в которой программа может делать всё, что угодно. Размер области может меняться. Программист имеет возможность воспользоваться частью памяти кучи с помощью функции malloc() , и тогда эта область памяти увеличивается. Возврат ресурсов осуществляется с помощью free() , после чего куча уменьшается.
• Сode (к одовый сегмент ) - это область памяти, в которой хранятся машинные инструкции скомпилированной программы. Они генерируются компилятором, но могут быть написаны и вручную. Обратите внимание, что эта область памяти также может быть разделена на три части (текст, данные и BSS). Эта область памяти имеет фиксированный размер, определяемый компилятором. UNIX. Профессиональное программирование ст.259

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

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

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

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

Структуры данных процесса

описанными, соответственно, в файлах sys/proc.h и sys/user.h . Содержимое и формат этих структур различны для разных версий UNIX.

....................................................................................................

https://m.habr.com/ru/company/*nix <-----------
….................................................................................................
В любой момент времени данные структур proc для всех процессов должны присутствовать в памяти, хотя остальные структуры данных, включая образ процесса, могут быть перемещены во вторичную память, область свопинга. Это позволяет ядру иметь под рукой минимальную информацию, необходимую для определения местонахождения остальных данных, относящихся к процессу, даже если они отсутствуют в памяти. Структура proc является записью системной таблицы процессов, которая, как мы только что заметили, всегда находится в оперативной памяти. Запись этой таблицы для выполняющегося в настоящий момент процесса адресуется системной переменной curproc. Каждый раз при переключении контекста, когда ресурсы процессора передаются другому
процессу, соответственно изменяется значение переменной curproc , которая теперь указывает на структуру proc активного процесса. Вторая упомянутая структура user , также называемая u-area или u-block , содержит дополнительные данные о процессе, которые требуются ядру только во время выполнения процесса (т. е. когда процессор выполняет инструкции процесса в режиме ядра или задачи). В отличие от структуры proc , адресованной указателем curproc , данные user размещаются
(точнее, отображаются) в определенном месте виртуальной памяти ядра и адресуются переменной u . Ниже показаны две основные структуры данных процесса и способы их адресации ядром UNIX.
В u-area хранятся данные, которые используются многими подсистемами ядра и не только для управления процессом. В частности, там содержится информация об открытых файловых дескрипторах, диспозиция сигналов, статистика выполнения процесса, а также сохраненные значения регистров, когда выполнение процесса приостановлено. Очевидно, что процесс не должен иметь возможности модифицировать эти данные произвольным образом, поэтому u-area защищена от доступа в режиме задачи. Как видно из рис., u-area также содержит стек фиксированного размера, системный стек или стек ядра (kernel stack). При выполнении процесса в режиме ядра операционная система использует этот стек, а не обычный стек процесса.

Состояния процесса

• 1. Процесс выполняется в режиме задачи. При этом процессором выполняются прикладные инструкции данного процесса.
• 2. Процесс выполняется в режиме ядра. При этом процессором выполняются системные инструкции ядра операционной системы от имени процесса.
• 3 . Процесс не выполняется, но готов к запуску, как только планировщик выберет его (состояние runnable).Процесс находится в очереди на выполнение и обладает всеми необходимыми ему ресурсами, кроме вычислительных.
• 4. Процесс находится в состоянии сна (asleep), ожидая недоступного в данный момент ресурса, например завершения операции ввода/вывода.
• 5. Процесс возвращается из режима ядра в режим задачи, но ядро прерывает его и производит переключение контекста для запуска более высокоприоритетного процесса.
• 6. Процесс только что создан вызовом fork и находится в переходном состоянии: он существует, но не готов к запуску и не находится в состоянии сна.
• 7. Процесс выполнил системный вызов exit и перешел в состояние зомби (zombie, defunct). Как такового процесса не существует, но остаются записи, содержащие код возврата и временную статистику его выполнения, доступную для родительского процесса. Это состояние является конечным в жизненном цикле процесса.

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

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

Принципы управления памятью

Управление памятью часть-1

12:51 - Разрешение адресов 34:21 - Оверлейная,динамическая структуры

59:26 - Линейное непрерывное отображение - Кусочно линейное (ст.25)

Управление памятью часть-2

Что было в начале? ООП или виртуальная память.

51:44--> "Виртуальная память"; <-(стр. 18)-> 56:03--> "Сегменты";

Одной из основных функций операционной системы является эффективное управление памятью.
Оперативная память, или основная память, или память с произвольным доступом (Random Access Memory, RAM). Время доступа к оперативной памяти составляет всего несколько циклов процессора, поэтому работа с данными, находящимся в памяти, обеспечивает максимальную производительность.
Данный ресурс, как правило, ограничен. В большей степени это справедливо для многозадачной операционной системы общего назначения, каковой является UNIX.
Поэтому данные, которые не могут быть размещены в оперативной памяти, располагаются на вторичных устройствах хранения, или во вторичной памяти, роль которой обычно выполняют
дисковые накопители. Время доступа ко вторичной памяти на несколько порядков превышает время доступа к оперативной памяти и требует активного содействия операционной системы.
Подсистема управления памятью UNIX отвечает за справедливое и эффективное распределение
разделяемого ресурса оперативной памяти между процессами и за обмен данными между оперативной и вторичной памятью. Часть операций производится аппаратно, устройством
управления памятью (Memory Management Unit, MMU) процессора под управлением операционной системы, чем достигается требуемое быстродействие.
Примитивное управление памятью значительно уменьшает функциональность операционной системы. Такие системы, как правило, позволяют загрузить в заранее определенное место в оперативной памяти единственную задачу и передать ей управление. При этом задача получает в свое
распоряжение все ресурсы компьютера (разделяя их, разумеется, с операционной системой),
а адреса, используемые задачей, являются физическими адресами оперативной памяти.
По скольку такой способ запуска и выполнения одной программы безусловно является наиболее быстрым он часто используется в специализированных микропроцессорных системах, однако практически неприменим в операционных системах общего назначения, какой является UNIX.
Можно сформулировать ряд возможностей, которые должна обеспечивать подсистема управления памятью современной многозадачной операционной системы:

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

Виртуальная и физическая память

• Во-первых, трудно себе представить механизм, защищающий адресное пространство одного процесса, от адресного пространства другого или, что более важно, от адресного пространства самой операционной системы. Поскольку каждый процесс работает с физическими адресами, нет никакой гарантии, что процесс не обратится к ячейкам памяти, принадлежащим другим процессам или ядру системы. Последствия такого обращения скорее всего будут весьма плачевными.
• Во-вторых, уже на этапе компиляции необходимо было бы предусмотреть распределение существующего физического адресного пространства. При запуске каждый процесс должен занимать непрерывную и непересекающуюся область физических адресов.
• В-третьих, подобное распределение памяти между процессами вряд ли можно назвать оптимальным. Объем физической оперативной памяти будет существенным образом ограничивать число процессов, одновременно выполняющихся в системе. Так восемь процессов, каждый из которых занимает 1 Мбайт памяти, исчерпают 8 Мбайт оперативной памяти, а операционная система при средней загрузке насчитывает более 80 процессов!

Виртуальное адресное пространство - рай для процесса.

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

Современные процессоры, как правило, поддерживают объединение адресного пространства (сегментно - страничная организация памяти):

в области переменного размера - сегменты и

в области фиксированного размера - страницы,

понятие "страница" можно трактовать как способ организации памяти когда физическая память разделяется на блоки фиксированного размера (512-2Кб, кратное 2-ум), как и понятие "сегмент", "страница" одно из фундаметальных абстракций в понимании архитектуры и работы операционных систем. При этом для каждого сегмента или страницы может быть задано собственное отображение виртуальных адресов в физические.
Виртуальное адресное пространство процесса, как правило, является последовательно структуированным в рамках сегментов - кода, данных, стека и библиотек. Расположение соответствующих областей физической памяти может иметь фрагментированный характер. Размер виртуальной памяти может существенно превышать размер физической за счет использования вторичной памяти или области свопинга - как правило, дискового пространства, где могут сохраняться временно не используемые участки адресного пространства процесса. Например, если при выполнении процесса происходит обращение к виртуальному адресу, для которого присутствует соответствующая страница физической памяти, операция чтения или записи завершится успешно. Если страница в оперативной памяти отсутствует, процессор генерирует аппаратное прерывание, называемое страничной ошибкой (page fault) , в ответ на которое ядро определяет положение сохраненного содержимого страницы в области свопинга, считывает страницу в память, устанавливает параметры отображения виртуальных адресов в физические и сообщает процессору о необходимости повторить операцию. Все эти действия невидимы для приложения, которое работает с виртуальной памятью.
Механизм отображения виртуальных адресов в физические (трансляция адреса) существенным

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

Сегменты

1 5 3 2 1 0

• Поле INDEX является номером (индексом) дескриптора в таблице дескрипторов, который должен использоваться при вычислении линейного адреса.
• Бит TI указывает, какая таблица дескрипторов должна использоваться Ø - соответствует GDT 1 - соответствует LDT
• Поле RPL используется для контроля прав доступа программы к сегменту . является запрошенным уровнем привилегий и является одним из механизмов обеспечения защиты сегментов. Например, если процесс, находясь в режиме задачи, попытается обратиться к сегменту, принадлежащему ядру, процессор сгенерирует особую ситуацию, в ответ на это ядро отправит процессу сигнал SIGSEGV.

Дескрипторы сегментов (кода, данных, стека) имеют несколько полей:

• Базовый адрес В этом поле хранится 32-битный адрес начала сегмента. Процессор добавляет к нему смещение и получает 32-битный линейный адрес.
• Предел Это поле определяет размер сегмента. Если результирующий линейный адрес выходит за пределы сегмента, процессор генерирует особую ситуацию. Границы сегмента позволяют процессору обнаруживать такие распространенные ошибки, как переполнение стека, неверные указатели, неверные адреса вызовов и переходов. В случае, когда операционная система считает, что обращение за пределы сегмента не является ошибкой (например, при переполнении стека), она может расширить сегмент путем выделения дополнительной памяти и запросить выполнение команды вновь.
• Привилегии Это поле, имеющее название Descriptor Privilege Level (DPL), определяет уровень привилегий сегмента и используется совместно с полем RPL селектора для разрешения или запрещения доступа к сегменту. Для получения доступа к сегменту задача должна иметь по крайней мере такой же уровень привилегий, как и сегмент, т. е. RPL DPL.
• Признак присутствия. Этот бит обеспечивает один из механизмов реализации виртуальной памяти. Если бит не установлен, при попытке обращения к сегменту процессор генерирует особую ситуацию отсутствия сегмента, позволяя ядру подгрузить сегмент из вторичной памяти и вновь повторить инструкцию, не затрагивая при этом выполнение процесса. Однако в большинстве современных версий UNIX виртуальная память основана на страничном механизме, при котором сегмент всегда присутствует в памяти, а обмен между оперативной и вторичной памятью происходит на уровне страниц.
• Тип Это поле определяет тип сегмента. Процессор проверяет тип сегмента на соответствие исполняемой команде. Это, в частности, не позволяет интерпретировать информацию сегмента данных как инструкции процессора.
• Права доступа Это поле определяет права доступа, ограничивающие множество операций, которые можно производить с сегментом. Например, сегмент кода обычно отмечается как исполняемый и читаемый. Сегменты данных могут иметь право доступа только для чтения, или для чтения и записи.

Страничный механизм

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

Page Directory Entry, PDE - Первое поле адреса, с 22 по 31 бит, указывает на элемент каталога таблиц страниц PDE . Каталог таблиц страниц имеет длину,равную одной странице, и содержит до 1024 указателей на таблицы страниц (page table). Таким образом, первое поле адресует определенную таблицу страниц.
Page Table Entry, РТЕ - Второе поле, занимающее с 12 по 21 бит, указывает на элемент таблицы страниц РТЕ . Таблицы страниц также имеют длину 4 Кбайт, а элементы таблицы адресуют в совокупности 1024 страниц. Другими словами, второе поле адресует определенную страницу.
Наконец, смещение на странице определяется третьим полем, занимающим младшие 12 бит линейного адреса. Таким образом, с помощью одного каталога таблиц процесс может адресовать

1024 x 1024 x 4096 = 4 Гбайт физической памяти.

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

характеристики страницы. Поля PTE :

Адресное пространство процесса

Подсистема управления процессами