Методические указания к выполнению курсовой работы по дисциплине ОС (раздел “Управление оперативной памятью”) (стр. 3 )

МЕНЕДЖЕР СТРАНИЦ (Модуль 8).

PROCESS менеджер-страниц

FOR ид-страницы FROM 0 ТО макс-число-реальных-сто

DO

загрузить-дескриптор-страницы(ид-страяицы, адрес-дескриптсра-стр)

IF статус-страницы [адрес-дескриптора-стр] =0

THEN

IF ид-процесса[адрес-дескриптора-стр] не блокирован

THEN

INCREMENT счетчик-использования [адрес-дескриптора-стр]

IF счетчик-использования [адрес-дескриптора-стр] > = время-раб-набора

THEN

ид-процесса[адрес-дескриптора-стр] -> адрес-процесса

INCREMENT текущ-разм-раб-набора [адрес-процесса]

список-процессов(адрес-процесса] -> текущая-очередь

отделить-дескриптор-стр(ид-страницы, текущая очередь,адрес-дескриптора-стр)

освободить-странииу(ид-страницы, адрес-дескриптора-стр)

ENDIF

сохранить-дескриптор-стр (нд-страннцы, адрес-дескриптора-стр)

ENDIF

ENDIF

ENDDO

CLEAR размер-раб-набора

CLEAR неудача

WHILE неудача =0

DO

DECREMENT счетчик-своб-страниц BY размер-раб-набора

просмотр-очереди-на-вып(размер-раб-набора, неудача, адрес-процесса)

IF неудача = 0

THEN

первый-запрос[адрес-процесса] ->виртуальная-стр

отделить-процесс (адрес-процесса, очередь-на-вып)

поставить-в-очер-на-ввод(адрес-процссса, виотуальная-стр)

ENDIF

ENDDO

ENDPROCESS

ПРИМЕР ОФОРМЛЕНИЯ КУРСОВОЙ РАБОТЫ
СОДЕРЖАНИЕ

1. Постановка задачи 3

2. Теоретические основы управления памятью- 5

3. База данных для управления виртуальной памятью---- 7

3.1. Исходные данные 7

3.2. Динамические данные------ 8

3.2.1. Таблицы-- 8

3.2.2. Списки и очереди-- 10

4. Инициализация системы 12

5. Менеджер и его окружение 14

5.1. Работа с очередью процессов на выполнение-- 14

5.2. Работа с таблицей страниц ОП------- 14

5.3. Работа с очередью выполняющихся процессов 16

5.4. Работа с очередью страниц на загрузку с диска в ОП---- 19

5.5. Работа с очередью страниц на выгрузку из ОП на диск- 19

6. Обработка прерываний-- 20

6.1. Обработчик прерываний по ошибке адресации 20

6.2. Обработчик прерываний по переполнению РН 20

6.3. Обработчики сегментно-страничных прерываний------- 20

6.4. Модуль деактивизации процесса----- 22

6.5. Процедура освобождения страницы в ОП----- 22

Приложение------ 23

Литература------- 30

1. ПОСТАНОВКА ЗАДАЧИ

ЗАДАНИЕ НА КУРСОВУЮ РАБОТУ

Номер варианта: 3678

·  Разработать структуру планировщика - диспетчера, реализующего функцию динамического управления памятью при:

сегментно - страничной организацией памяти.

·  Создать подсистему управления ОП в составе:

v  база данных для управления ОП;

v  таблица трансляции;

v  таблица страниц (сегментов, сегментно - страничной организацией);

v  менеджер страниц (сегментов, сегментно - страничной организации).

·  Определить рабочую область менеджера памяти.

·  Разработать алгоритмы обработки прерываний по обращению к ОП:

6.  прерывание по переполнению рабочего набора;

7.  прерывание по ошибке адресации;

8.  сегментно - страничное прерывание.

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

Имитационная модель (полный листинг программы приведен в приложении) написана в на языке Visual Basic в среде Microsoft Visual Basic 5 (в задании не оговаривается конкретный язык программирования). К сожалению, классический С++ не позволяет создавать приложений под Windows, а значит большая часть происходящего «внутри» программы окажется скрытой от пользователя. Visual C++ в этом отношении подходит больше, но из-за сложного механизма связывания переменных с объектами управления, его алгоритмы и громоздкая система классов практически недоступны для восприятия «со стороны», поэтому модель опять оказывается «черным ящиком». В то же время в данной разработке основной акцент делается на наглядную демонстрацию всех моделируемых процессов: динамическое создание, развитие («эволюцию») и уничтожение процессов таблиц управления.

С этой целью все необходимые для работы списки, очереди и таблицы оформлялись либо непосредственно на экранной форме приложения, либо в составе прилагаемой базы данных ControlTables. mdb (Microsoft Access 97), состав которой подробно описан в разделе «База данных для управления ОП». После каждой модификации какой-либо из этих структур пользователю выдается соответствующее сообщение. Работа программы приостанавливается, поэтому можно изучить любую интересующую таблицу и оценить произошедшие изменения.

Базу данных ControlTables. mdb (она должна находиться в той же директории, что и выполняемое приложение) рекомендуется держать открытой. Если ожидаемых изменений вдруг не произошло, следует выбрать команду меню Записи ® Обновить.

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

2. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ ПАМЯТИ ПРИ СЕГМЕНТНО-СТРАНИЧНОЙ ОРГАНИЗАЦИИ

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

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

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

Рис.1

Приведем пример заполнения такой таблицы (рис 2).

Рис.2

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

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

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

Преобразование виртуального адреса в физический показано на рис. 3.

Рис. 3

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

3. БАЗА ДАННЫХ ДЛЯ УПРАВЛЕНИЯ ОПЕРАТИВНОЙ ПАМЯТЬЮ

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

3.1. ИСХОДНЫЕ ДАННЫЕ

Таблица процессов ProcessTable (должна находиться в составе базы данных ControlTables. mdb) содержит информацию о количестве и основных параметрах процессов в системе.

Формат таблицы приведен на рис 4:

Рис.4

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

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

Формат таблицы приведен на рис 5.

Рис.5

3.2. ДИНАМИЧЕСКИ СОЗДАВАЕМЫЕ ДАННЫЕ

3.2.1. ТАБЛИЦЫ

Расширенная таблица процессов ExtendedProcessTable создается на основе таблицы процессов ProcessTable при инициализации системы и автоматически добавляется в базу данных ControlTables. mdb.

Формат таблицы приведен на рис. 6.

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

Рис. 6

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

Возможные значения поля Status и соответствующие состояния процесса приведены в таблице 1.

Таблица 1. Состояния процесса

Status	Состояние процесса
0	Находится в очереди на выполнение
1	Ожидает загрузки страниц(ы) с диска в ОП
2	Находится в очереди выполняющихся
3	Ожидает выгрузки страниц(ы) из ОП на диск
4	Завершен

Очевидно, что значение поля CountLoadPage имеет смысл только в том случае, если процесс находится в состоянии «1» или «3» (заводить разные счетчики не имеет смысла, так как процесс все равно не может находиться в обоих состояниях одновременно).

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

Таблица сегментов Segment*, как уже было сказано выше, ставится в соответствие каждому процессу. Имя ее генерируется по правилу:

“SegmentTable” + Str (Идентификатор процесса)

Таблица автоматически добавляется в базу данных при инициализации системы. Формат таблицы приведен на рис 7.

Рис.7

Поле ATT – адрес таблицы трансляции – есть имя соответствующей таблицы в базе данных ControlTables. mdb

Таблица трансляции страниц сегмента TranslateTable** ставится в соответствие каждому сегменту. Имя ее генерируется по правилу:

“TranslateTable” + Str (Идентификатор процесса)+Str(Номер сегмента)

Таблица автоматически добавляется в базу данных при инициализации системы. Формат таблицы приведен на рис. 8.

Рис.8

Возможные значения поля Status и соответствующие состояния виртуальной страницы приведены в таблице 2

Таблица 2. Состояния виртуальной страницы

Status	Состояние виртуальной страницы
0	Выгружена на диск
1	Ожидает загрузки с диска в ОП
2	Загружена в ОП
3	Ожидает выгрузки из ОП на диск

Таблица страниц PageTable описывает состояние физических страниц оперативной памяти. Формат таблицы приведен на рис 9.

Рис.9

Возможные значения поля Status и соответствующие состояния физической страницы приведены в таблице 3

Таблица 3. Состояния физической страницы

Status	Состояние физической страницы
0	Пустая, доступная для повторного распределения
1	Недоступна
2	Активна

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

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

3.2.2. СПИСКИ И ОЧЕРЕДИ

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

“WorkSetTable” + Str (Идентификатор процесса)

Формат таблицы приведен на рис 10.

Рис.10

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

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

Рис.11

Формат очереди на выгрузку модифицированных страниц из оперативной памяти на диск UnloadPageLine приведен на рис. 12.

Рис.12

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

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

·  очередь процессов на выполнение WFList;

·  очередь процессов, ожидающих загрузки страниц(ы) с диска в оперативную память WLoadList;

·  очередь выполняющихся процессов FulFilList;

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

Перемещение процесса из очереди в очередь сопровождается изменением его поля Status. При Status = 4 процесс считается завершенным и уходит из всех очередей.

4. ИНИЦИАЛИЗАЦИЯ СИСТЕМЫ

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

Во-первых, необходимо определиться с начальным составом рабочего набора страниц каждого процесса. Будем считать, что в первый раз процесс сможет начать свое выполнение только тогда, когда все страницы его нулевого сегмента будут загружены в оперативную память. Поэтому в расширенной таблице процессов ExtendedProcessTable поле каждого процесса WorkSet (размер рабочего набора в страницах) устанавливается равным значению SSize для нулевого сегмента этого процесса. В 0 устанавливаются поля NBeginPage (начальная страница рабочего набора), CountLoad (процесс пока еще не имеет ни одной страницы в очередях на загрузку или выгрузку) и Status (первоначально все процессы находятся в очереди на выполнение). Из этого следует, что во всех таблицах трансляции TranslateTable** поле Status должно быть установлено в 0 для каждой страницы (все страницы находятся в состоянии «Выгружена на диск»), поле WorkSet (признак принадлежности страницы рабочему набору процесса) устанавливается в значение «Истина» для страниц нулевых сегментов (то есть все страницы в таблицах TranslateTable*0), а список страниц рабочего набора процесса WorkSetTable* заполняется виртуальными адресами этих страниц.

Теперь следует договориться о конструкции виртуального адреса. В разработанной программе он составляется по следующему правилу:

VirtAddress = 1000*SNumber+PNumber.

В реальных системах, как уже было сказано в разделе (*), для полей SNumber и PNumber выделяют определенное число бит, то есть правильнее было бы умножать не на 1000, а на 1024 (целую степень числа 2). Но в процессе наблюдения за работой программной модели такие адреса достаточно сложно воспринимать (увидев в таблице страниц оперативной памяти адрес 2003, мы сразу понимаем, что речь идет о третьей странице второго сегмента, а в «правильном» адресе 2051 не разобраться, не взяв в руки калькулятор). Поскольку в базах данных Access, по-видимому, отсутствует возможность представления целых чисел в двоичном коде, а Visual Basic не поддерживает операций сдвига (это один из немногих его недостатков), то с точки зрения алгоритма между модулями 1000 и 1024 нет разницы. В результате выбор был сделан в пользу более «удобного».

В таблице страниц оперативной памяти PageTable создается столько записей, сколько было указано в текстовом поле Size на экранной форме (подпись «Страниц в ОП»). По умолчанию эта величина равна 16. Все физические страницы нумеруются по порядку с нуля, поле Status устанавливается в 0 (все страницы доступны для распределения), затем эти адреса по очереди добавляются в список пустых страниц EmptyList. Значения остальных полей не имеют смысла при Status=0.

Затем следует добавить имена всех процессов в очередь на выполнение WFList. Точнее, туда добавляются имена, организованные по правилу:

Str(WorkSet)+ProcessName,

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

Все остальные очереди и списки создаются пустыми и не являются упорядоченными (дисциплина обслуживания FIFO)

5. МЕНЕДЖЕР ПАМЯТИ И ЕГО ОКРУЖЕНИЕ

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

5.1. РАБОТА С ОЧЕРЕДЬЮ ПРОЦЕССОВ НА ВЫПОЛНЕНИЕ

Работа с очередью процессов на выполнение подразумевает следующую последовательность действий:

·  Выбрать первый процесс из очереди на выполнение (то есть имеющий минимальный размер рабочего набора);

·  Отправить все страницы рабочего набора процесса в очередь на загрузку с диска в оперативную память;

·  Установить в расширенной таблице процессов число страниц, загрузки которых ожидает процесс (то есть заносит в поле CountLoadPage текущий размер рабочего набора процесса WorkSet);

·  Установить статус процесса в 1 (ожидающий загрузки страниц в оперативную память);

·  Добавить процесс в очередь процессов, ожидающих загрузки страниц.

Структура схема этого обработчика изображена на рис. 13.

5.2. РАБОТА С ТАБЛИЦЕЙ СТРАНИЦ ОПЕРАТИВНОЙ ПАМЯТИ

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

IF счетчик числа обращений = 0 и статус страницы = 2

THEN

удалить страницу из рабочего набора процесса;

освободить страницу в ОП.

END IF

CLEAR счетчик числа обращений.

Структура схема этого обработчика изображена на рис. 14

Рис.13

Рис.14

5.3. РАБОТА С ОЧЕРЕДЬЮ ВЫПОЛНЯЮЩИХСЯ ПРОЦЕССОВ

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

Для генерации виртуального адреса, по которому обращается процесс, разработана специальная функция Appeal. Собственно, генерируется даже не сам адрес, а смещение его относительно базовой страницы рабочего набора NBeginPage (этот адрес случайным образом обновляется с течением времени). Это приближает модель к реальной системе: ведь адреса обращений обычно не распределяются равномерно по всему адресному пространству, а характеризуются некоторой дискретностью (в противном случае полностью теряет смысл поддержка концепции рабочего набора). После генерации адреса функция Appeal обращается к таблице сегментов процесса, чтобы убедиться в его (адреса) существовании. Дело в том, что смещение может оказаться слишком большим: при генерации адреса по экспоненциальному закону «хвост» экспоненты намеренно не отсекается, так как заданием оговорена обработка прерывания по ошибке адресации. Если адрес не существует, то функция Appeal возвращает -1 и по этому признаку вызывается обработчик прерывания по ошибке адресации с указанием причины: обращение по несуществующему адресу.

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

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

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

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

Если страницу загрузить можно, то она помещается в очередь на загрузку страниц с диска в ОП и добавляется в рабочий набор процесса. Процесс тем временем переводится в состояние «Ожидание загрузки страницы» (Status=1) и перемещается из очереди выполняющихся процессов FulFilList в конец очереди WLoadList. Все его страницы, уже загруженные в память, переводятся в состояние «недоступны» (status=1), так как если оставить их в активном состоянии, то они могут быть удалены менеджером при очередном сканировании таблицы страниц оперативной памяти, что было бы нежелательным (особенно если рабочий набор у владеющего процесса большой).

Структурная схема, иллюстрирующая все вышеописанное, приведена на рис. 15.

Рис.15

5.4. РАБОТА С ОЧЕРЕДЬЮ СТРАНИЦ НА ЗАГРУЗКУ С ДИСКА В ОП

В описанной выше организации загрузки страницы в ОП после сбоя (без выгрузки всех остальных страниц процесса) таится некоторая опасность. Возможно (хотя маловероятно), что все процессы окажутся в очереди ожидания загрузки страниц, а вся оперативная память при этом будет занята (до тех пор, пока в очереди остается хотя бы один выполняющийся процесс, еще есть надежда, что очередное обращение вызовет прерывание по ошибке адресации либо переполнению рабочего набора, процесс будет деактивизирован, а все его страницы в ОП освобождены). Даже если каждому процессу нужна загрузка всего лишь одной страницы, ситуация оказывается тупиковой: ему никто не «уступит» места в памяти. Поэтому каждый раз при обработке очереди WLoadPage осуществляется необходимая проверка, и если действительно счетчик пустых страниц ОП равен 0, а очередь FulFilList пуста, то обработчик выдает соответствующее сообщение, после чего извлекает из очереди ожидания загрузки страниц WLoadList первый процесс и «волевым образом» его деактивизирует, решая тем самым проблему (при многократных испытаниях модели такое явление наблюдалось дважды).