Краткий обзор архитектуры Windows.
Эволюция ОС.
I. 1945-1955 г.г. В восемнадцатом веке английский математик Чарльз Бэббидж изобрёл компьютер (теоретически). ОС он не имел. С середины 40-х годов были изобретены первые ламповые вычислительные устройства. Занимался разработкой, программированием и использованием один коллектив. ОС не было. Были библиотеки служебных и математических программ.
II. 1955-1965 г.г. Появление полупроводниковых элементов. Выполнение практических задач. Разделение персонала на программистов, операторов и т.д. Появились алгоритмические языки, а следовательно и компиляторы. Появились системы пакетной обработки, из-за высокой стоимости процессорного времени. Формируется группа задач, а затем они выполняются на тачке. Пакет заданий тогда был на перфокартах.
III. 1965-1980 г.г. Переход от полупроводников к ИС(интегральным схемам). Появление семейства программно совместимых машин. Семейство IBM 360, ЕС ЭВМ. Возникла необходимость создания ОС. OS/360. Важнейшее достижение: мультипрограммирование, то есть попеременно выполняются несколько программ. Данная система использовала обработку как пакетную, так и с разделением времени.
IV. 1980-2002 г.г. Появление СБИС(сверхбольшая интегральная схема). Удешевление тачек. Особенность: доступ к тачке получили ламеры. ОС стали иметь дружественный интерфейс. Идёт бурное развитие сетей.
2. Классификация операционных систем.
Операционные системы можно классифицировать по следующим признакам:
1.Особенности алгоритмов управления ресурсами
А) Поддержка многозадачности.
Однозадачные: MS-DOS, MSX.
Многозадачные: OS/2, UNIX, Windows, OS ЕС
Б) Поддержка многопользовательского режима. Основное отличие многопользовательских состоит в наличии средств защиты информации каждого пользователя от несанкционированного доступа других пользователей.
Однопользовательские: MS-DOS
Многопользовательские: Windows NT, UNIX
В) Вытесняющая и невытесняющая многозадачность. Отличие состоит в степени централизации механизма планирования процессов. В случае вытесняющей многозадачности механизм планирования процессов сосредоточен в ОС, то есть ОС каждой выполняющейся задаче выделяет квант времени, приблизительно 20 мс. По истечении времени ОС переключается на выполнение другого процесса. В случае невытесняющей многозадачности каждый активный процесс выполняется до тех пор, пока сам не передаст управление ОС, а ОС затем сама определяет, какой процесс выполнять дальше.
Вытесняющая многозадачность: Windows NT, OS/2
Невытесняющая многозадачность: NetWare, Windows 3.x
Г) Поддержка многопоточности (thread - поток). Распараллеливание вычислений в рамках одной задачи.
Представители: OS/2, Windows, UNIX
Д) Многопроцессорная обработка. Существует асимметричная и симметричная. В случае асимметричной системы ОС целиком выполняется только на одном из процессоров системы, распределяя прикладные задачи между другими процессорами. В случае симметричной (SMP) система полностью децентрализована.
2. Особенности аппаратных платформ.
Существуют ОС для: ПК, мини-ЭВМ, мейнфреймов, кластеров и сетей ЭВМ.
3. Особенности областей использования.
А) Системы пакетной обработки. Носят вычислительный характер, не требуют быстрого полу-чения результата.
Представители: OS EC
Б) Системы разделения времени. Для работы юзеров, программистов. У каждого юзера создаётся иллюзия использования отдельной тачки.
Представители: VMS, UNIX, Windows
В) Системы реального времени. Предназначены для управления различными техническими объектами. Существует предельно допустимое время, в течение которого должна быть выполнена та или иная программа.
Представители: QNX, RT/11
4. Особенности метода построения.
Существует особенность построения ядра: монолитный или микро-ядерный подход. Обычно ОС должны работать в нулевом кольце. Это монолитный подход. В случае
микроядра
тает медленнее, так как есть переходы между кольцами, но система яв-
лять, удалять.
5. Построение ОС на базе объектно ориентированного подхода.
Наличие нескольких прикладных сред, то есть это возможность в рамках одной ОС использовать приложение для других ОС. Например, в Windows NT можно использовать приложения для UNIX, OS/2.
6. Распределённая организация ОС.
Реализованы механизмы воспринимать сеть, в виде традиционного компьютера с одним процессором.
3. Структура ОС Windows.
Алгоритмы замещения страниц
Идеальный алгоритм заключается в том, что бы выгружать ту страницу, которая будет запрошена позже всех.
Но этот алгоритм не осуществим, т.к. нельзя знать какую страницу, когда запросят. Можно лишь набрать статистику использования.
7.1.1 Алгоритм NRU (Not Recently Used - не использовавшаяся в последнее время страница)
Используются биты обращения (R-Referenced) и изменения (M-Modified) в таблице страниц.
При обращении бит R выставляется в 1, через некоторое время ОС не переведет его в 0.
M переводится в 0, только после записи на диск.
Благодаря этим битам можно получить 4-ре класса страниц:
1. не было обращений и изменений (R=0, M=0)
2. не было обращений, было изменение (R=0, M=1)
3. было обращение, не было изменений (R=1, M=0)
4. было обращений и изменений (R=1, M=1)
7.1.2 Алгоритм FIFO (первая прибыла - первая выгружена)
Недостаток заключается в том, что наиболее часто запрашиваемая страница может быть выгружена.
7.1.3 Алгоритм "вторая попытка"
Подобен FIFO, но если R=1, то страница переводится в конец очереди, если R=0, то страница выгружается.
Алгоритм "вторая попытка"
В таком алгоритме часто используемая страница никогда не покинет память.
Но в этом алгоритме приходится часто перемещать страницы по списку.
7.1.4 Алгоритм "часы"7.1.4.2 Алгоритм WSClock
Чтобы избежать перемещения страниц по списку, Алгоритм основан на алгоритме "часы", но использует рабочий набор.
можно использовать указатель, который Используются битов R и M, а также время последнего использования.
перемещается по списку.
Алгоритм "часы"
Атрибуты защиты страниц.
Отдельные страницы имеют различные атрибуты защиты:
1) PAGE_NOACCESS. Попытка чтения, записи, исполнения в этом регионе памяти вызовет нарушение доступа.
2) PAGE_READONLY. Попытка записи, исполнения в этом регионе памяти вызовет нарушение доступа.
3) PAGE_READWRITE. Попытка исполнения в этом регионе памяти вызовет нарушение доступа.
4) PAGE_EXECUTE. Попытка чтения, записи в этом регионе памяти вызовет нарушение доступа.
5) PAGE_EXECUTE_READWRITE. Данный регион допускает любые операции.
6) PAGE_EXECUTE_READ. Попытка записи в этом регионе памяти вызовет нарушение доступа.
7) PAGE_WRITECOPY. Попытка исполнения в этом регионе памяти вызовет нарушение доступа. Запись в память этого региона приводит к тому, что процессу предоставляется личная копия данной страницы физической памяти.
8) PAGE_EXECUTE_WRITECOPY. Данный регион допускает любые операции.
В Windows 95 используются 1,2 и 3 атрибуты защиты. Кроме рассмотренных атрибутов защиты существуют два флага: PAGE_NOCACHE – отключает кэширование выделенной страницы. Использовать его не рекомендуется. В основном используется этот флаг разработчиками драйверов; PAGE_GUARD – специальный флаг. Используется при работе стека потока. Windows 95 эти флаги игнорирует. Флаги защиты можно объединять, используя логическую операцию OR. Для изменения атрибутов используется функция VirtualProtect(...).
| Виртуальное адресное пространство ////////////////////////////////////////////////// |
| ////////////////////////////////////////////// |
| Программный код или данные |
1-я копия Физическая память 2-я копия
Чтобы предотвратить одновременную запись в общий блок данных разными процессами ОС присваивает этому блоку данных атрибут защиты копирования при записи. Когда поток в одном процессе пытается записать что-нибудь в общий блок данных, то он
1) выделяет из страничного файла страницу физической памяти
2) отыскивает свободную страницу в памяти
3) копирует страницу с данными, которые поток пытается записать в общий блок на свободную страницу памяти, полученную на этапе 2
4) сопоставляет адрес этой страницы виртуальной памяти с новой страницей в памяти.
После этих действий ОС получает собственную копию этого блока данных и может делать с ней, что хочет. Windows 95 и Windows 98 не поддерживают копирование рпи записи.
8. Стек потока под управлением Windows NT (2000).
ОС сама резервирует место в виртуальном адресном пространстве регион для размещения стека потока.
Глобальные переменные хранятся в специальном сегменте, а локальные в стеке.
| программный сегмент сегмент данных |
Рассмотрим стек Windows NT, 2000. Под стек по умолчанию выделяется регион размером 1 Мб и передаются две страницы физической памяти. Значения устанавливаемые по умолчанию можно изменять в программе. Размер физической памяти можно менять при вызове функции CreateThread(…). Так выглядит стек при создании:
080FF000
| Страница физической памяти | PAGE_READWRITE Страница физической памяти c флагом | PAGE_GUARD Зарезервированная страница | | … Зарезервированная страница | … | Программный код |
Указатель стека устанавливается в верхней части стека. Физическая память выделена двум страницам.
Вторая страница имеет флаг запрещения доступа.
По мере создания различных локальных переменных стек разрастается, по мере его заполнения происходит переход во вторую страницу. Но эта страница защищена. ОС будет извещена о попытке записи на защищенную страницу и обрабатывает её следующим образом: снимает флаг запрещения записи со второй старницы. Выделяет стеку третью страницу физической памяти и присваивает третьей странице атрибуты PAGE_READWRITE и флаг PAGE_GUARD.
Рассмотрим ситуацию, когда стек потока фактически заполнен.
| //////////////////////////// PAGE_GUARD 3арезервированная страница Зарезервированная страница |
Флаг PAGE_GUARD снимается и физическая память выделяется следующей странице.
Физическая
память
После этого ОС формирует исключение, то есть информирует процесс о Stack Overflow. В этом случае процесс должен среагировать, если этого не произойдёт, то производится попытка записи на зарезервированную страницу, то есть когда это происходит, то ОС берёт управление на себя и завершает не только данный поток, а и весь процесс. В этом случае ОС даже не извещает пользова-теля. Процесс исчезает бесследно.
Почему нижняя страница стека всегда остаётся зарезервированной?
1. Для того, чтобы защитить стек от перезаписи.
| Стек Зарезервированная страница Данные |
память
Физическая
память
2. Для защиты программ и данных при переполнении стека. Например,
| Стек Пароли |
память
Стираем пароли и получаем доступ к сети.
КУЧИ (Heaps).
Мы рассматривали функции для работы с виртуальной памятью. Для работы с небольшими областями памяти используются кучи. В DOS кучей являлась вся свободная память.
Каждая программа имеет следующую структуру.
| /////////////// |
| главная куча стек локальная куча переменные код ехе файла |
свободная
память
куча
данные
При работе с кучей используются следующие функции.
HeapCreate(…) – создание кучи. HeapDestroy(…) – уничтожение кучи. HeapAlloc(…) – выделение блока в куче.
HeapFree(…) – освобождение блока в куче. GetProcessHeap(…) – определение идентификатора кучи, предоставляемой процессу по умолчанию.
Список свободных блоков
| куча заголовок |
| //////////////////////////// |
Каждая структура списка свободных блоков имеет следующий формат.
- максимальный размер блока (это число 20h, 80h, 200h и FFFFFFFFh).
- структура, представляющая собой арену, то есть заголовок.
Длина блока в арене 0, а указатель типа next указывает на первый свободный блок данного размера в куче, то есть указывает на первый свободный блок.
В заголовке кучи кроме того находится указатель на следующую кучу, созданную функцией HeapCreate(…). Если следующей кучи нет, то 0. В заголовке кучи имеется поле флагов.
В заголовке содержится критическая секция CriticalSection. Это структура, которая организует последовательный доступ к куче различных потоков процесса.
Несколько потоков обращаются к куче для того, чтобы выделить блок памяти в куче. Процесс выделения памяти в куче состоит из следующих этапов.
1. Поиск свободного блока.
2. Выделение физической памяти для этого блока.
3. Запись информации в выделенный блок.
Первый поток выполнил два этапа, его квант времени истёк. Начинается выполнение программного кода второго потока. Второй поток выполняет три этапа и находит тот же блок. Когда управление вернётся к первому потоку, то он запишет информацию в тот же блок, то есть информация второго потока будет испорчена.
Чтобы этого избежать существует критическая секция. Это признак. Как только какой-либо поток начинает работу с кучей устанавливается признак в CriticalSection.
Недостатком кучи является снижение производительности из-за последовательного доступа.
Heap_No_Serialsize – куча допускает одновременный доступ к куче со стороны нескольких потоков. Его рекомендуется не использовать, а если использовать, то только в том случае, если процесс имеет один поток.
В заголовке кучи обычно указывается сигнатура “HI” – признак того, что это заголовок кучи. Рассмотрим структуру отдельных блоков кучи. Каждый блок начинается с заголовка, то есть с арены.
Структура арены.
Арена в занятых блоках. Начинается с поля длины блока. Затем в некоторых версиях Windows кроме длины блока могут указываться значения счётчика команд перед обращением к куче.
Арена в свободных блоках. SIZE – размер PREV – указатель на пустой свободный блок. NEXT – указатель на следующий свободный блок, то есть свободные блоки связаны в цепочки.
Функции управления кучей Win32.
GetProcessHeap(…) – получить дескриптор кучи, предоставляемый процессу по умолчанию. Эта функция находит PDB и извлекает из базы данных дескриптор кучи.
HeapCreate(…) – создание кучи. Вызывают не только приложения пользователя, но и kernel32.dll и user32.dll вызывает для создания системных структур данных, например PDB или базы данных потока (TDB).
Процесс создания кучи проходит в 2 этапа:
1. резервирование памяти для кучи и связывание кучи в списке куч процесса.
2. инициализация всех полей заголовка кучи.
Функция HeapCreate(…) проверяет корректность параметров. Округляет границу кучи до ближайшего целого числа кратного 4 Кб.
Удаление кучи.
HeapDestroy(…). Проблема состоит в том, что 1.куча должна быть свободной, то есть CriticalSection=0. 2. куча может иметь подкучи.
Необходимо удалить весь список связанных подкуч. Windows поддерживает связанный список кучи, то есть HeapDestroy(…) должна выполнять действия по корректировке списка.
Локальный доступ.
Объекты kernel32.dll.
Объекты kernel32 являются ключевыми структурами данных ОС и находятся в куче, которой владеет kernel32. Например, в Windows 95,98 около 17 объектов, в Windows 2000 около 26 объектов. Примеры объектов:
объект-процесс
объект-поток
объект-файл
объект-файл проецируемый в память
объект-семафор
объект-событие
объект-mutex
объект-почтовый слол
объект-сокет
объект-именованный программный канал
Такая структура как модули не является объектом ядра. Каждый объект ядра начинается с заголовка. Он состоит из нескольких полей.
1. Тип объекта. Заносится постоянная, характеризующая тип объекта. В зависимости от типа объекта интерпретируются другие поля.
2. Счётчик ссылок на объект. Определяет сколько раз программный код обращается к объекту. Когда оно станет равно 0, то ОС удаляет объект.
Модули – это версия в памяти кода данных и ресурсов исполняемого файла или dll. В каждом процессе имеется модуль для ехе файла, каждая dll – это модуль.
Процесс – есть субъект владения. Процесс владеет памятью, то есть своим ВАП. Владеет дескрипторами файлов, которые прикладная программа может использовать для чтения записи, владеет потоками, списками модулей, dll, которые необходимы процессу для работы. Процесс не представляет исполнение программного кода. За выполнение программного кода отвечают потоки. Каждый процесс связан с файлом на диске. Но файл становится процессом тогда, когда загружен в память на выполнение.
Потоки отвечают за исполнение программного кода. При создании процесса всегда создаётся первичный поток. По желанию программиста создаются дополнительные потоки.
13. Модули Win32. База данных модуля. Глобальный список модулей (структуры IMTE) и локальный список модулей (структура MODREF). Связь между структурами MODREF и IMTE. Функции для работы с модулями.
Модули – это версия в памяти кода данных и ресурсов исполняемого файла или dll. В каждом процессе имеется модуль для ехе файла, каждая dll – это модуль.
Если два или более процесса обращаются к одной dll они используют один и тот же модуль. Точно также, когда запущены 2 копии процесса, они используют один и тот же модуль.
Информация о модулях хранится в базе данных модуля. В Windows 95, 98, NT база данных модуля фактически представляет собой заголовок исполняемого файла. Любой процесс загружается в ВАП.
начало база данных
ехе файла модуля
При работе с модулями Win32 использует дескриптор модуля HMODULE.
GetModuleHandle(…) – получает дескриптор модуля, виртуальный адрес с которого загружается ехе или dll. Например для всех процессов, работающих под Windows 95, 98 это 00400000h.
База данных модуля находится в адресном пространстве процесса, кроме того, для оператив-ной работы с модулем W32 создаёт копию базы данных своей системной кучи.
ВАП
| //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// |
| база данных модуля |
2 Гб
личная база данных модуля
начальный адрес
При работе с модулями возникают две проблемы:
1. Проблема защиты информации, то есть создание закрытого адресного пространства для каждого процесса.
2. Для оперативной работы ОС надо знать список всех загруженных модулей.
Эти проблемы решаются с помощью двух структур IMTE (Internal Module Table Entry) и MODREF – она поддерживает собственный список модулей для каждого процесса. И та и другая структуры находятся в системной куче ядра. Рассмотрим структуру IMTE.
Структура IMTE.
таблица модулей IMTE
| kernel32.dll |
pModuleTableArray
| user32.dll |
| gdi32.dll |
| my.exe |
Начало таблицы модулей хранится в pModuleTableArray. Как только новый процесс или dll создаются, то kernel32 создаёт структуру IMTE, ищет свободный элемент в таблице модулей и записывает в него указатель на структуру IMTE. ОС сама следит за тем, чтобы не произошло заполнение таблицы модулей. Структура:
· Указатель на базу данных модуля, расположенного в куче kernel32.dll в области выше 2 Гб. Благодаря указателю kernel32 может получать информацию о любом модуле не переключаясь в контекст памяти.
· Указатель на полное имя файла из которого был создан модуль. Память под полное имя модуля выделяется.
· Указатель на строку с именем модуля. Этот указатель указывает внутрь предыдущей структуры.
· Число символов в полном имени файла.
· Число символов только в имени файла.
Зачем нужны эти два предыдущих поля? Например, функция GetModuleHandle с помощью указателя просматривает структуры IMTE и для ускорения поиска сравнивает длины запрашиваемого модуля и модуля в очередной структуре IMTE, если длины не совпадают, то сравнивать имена смысла не имеет.
· Число разделов в модуле. Например, раздел, содержащий данные, программный код и т.д.
· Базовый адрес, по которому был запущен модуль.
· Счётчик ссылок к модулю.
· Счётчик числа ссылок в модуле, например, если какая-то программа была запущена на выполнение три раза, то для этой программы создаётся три объекта ядра процесса и одна база данных модуля.
Структура MODREF.
С помощью структуры MODREF создаётся список модулей для каждого процесса, что позволяет процессам не знать о модулях, загруженных другими процессами.
Структура MODREF создаётся для exe файла и для каждой dll, используемой файлом. Память для каждой MODREF выделяется из кучи kernel32.
Рассмотрим список MODREF для файла my.exe, который использует kernel32.dll и bar.dll.
| PDB my.exe |
pModuleTableArray Таблица модулей
MODREF
| kernel32.dll |
индекс в IMTE
E o4y7XifGpNphx3KhxYEeWqo+VntnIZRr2pVfs2pmNpeNp2T3+PyE1p6fTfd3oCJN8Q+GH31Rh0Kc tn7PdVC9ZJNeC2ohMQtQAiTp1S2o7W+ji1z/f6H4BgAA//8DAFBLAQItABQABgAIAAAAIQC2gziS /gAAAOEBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhADj9If/WAAAAlAEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAIz4wqtTAgAAYQQAAA4AAAAAAAAAAAAAAAAALgIAAGRycy9lMm9Eb2MueG1sUEsBAi0AFAAG AAgAAAAhAH/rqkTcAAAACgEAAA8AAAAAAAAAAAAAAAAArQQAAGRycy9kb3ducmV2LnhtbFBLBQYA AAAABAAEAPMAAAC2BQAAAAA= " o:allowincell="f"/>таблице
| my.exe |
| bar.dll |
Структура MODREF содержит недокументированные поля:
1. Указатель на структуру PDB для обеспечения обратной связи.
2. Индекс в таблице модулей, то есть индекс в глобальной таблице модулей.
3. Указатель на следующую структуру MODREF.
Конец списка обозначается 00000000.
Все модуль-зависимые функции просматривают только структуры MODREF для конкретного процесса. Модуль-зависимые функции:
GetProcAddress(…) – получив идентификатор модуля и идентификатор функции (это её имя или порядковый номер экспорта) возвращает адрес точки входа этой функции.
GetModuleFileName(…) – по идентификатору модуля возвращает полный путь к exe или dll файлам.
GetModuleHandle(…) – по имени файла возвращает идентификатор этого модуля.
14. Процессы Win32. Идентификатор процесса и дескриптор процесса. Объект ядра процесс в Win32. Функции для работы с процессами Таблица дескрипторов процесса.
Процесс – есть субъект владения. Процесс владеет памятью, то есть своим ВАП. Владеет дескрипторами файлов, которые прикладная программа может использовать для чтения записи, владеет потоками, списками модулей, dll, которые необходимы процессу для работы. Процесс не представляет исполнение программного кода. За выполнение программного кода отвечают потоки. Каждый процесс связан с файлом на диске. Но файл становится процессом тогда, когда загружен в память на выполнение.
Для работы с процессом ОС создаёт структуру базы данных процесса. Эта база данных PDB. EPROCESS – управляющая структура (идентификатор).
Однозначно сослаться на него можно с помощью дескриптора процесса и идентификатора процесса. Дескриптор – это индекс в таблице дескрипторов процесса, а указателем на процесс является сожержимое таблицы процесса.
TD
| PDB |
Идентификатор процесса является указателем на базу данных процесса. Функции Win32 для работы с процессами.
CreateProcess(…) – создаёт новый процесс.
ExitProcess(…) – завершает процесс с уведомлением всех подключенных dll.
TerminateProcess(…) – завершает процесс без уведомления подключенных dll.
GetProcessTimes(…) – получает временные параметры процесса. Определяет сколько времени в режиме ядра, а сколько в пользовательском режиме. В Windows 95, 98 функция не поддерживается.
GetCurrentProcess(…) – можно получить дескриптор текущего процесса.
GetCurrentProcessId(…) – можно получить идентификатор текущего процесса.
GetExitCodeProcess(…) – возвращает код завершения процесса.
GetCommandLine(…) – возвращает указатель на командную строку, переданную текущему процессу, то есть можно получить входные параметры с помощью неё.
GetEnvironmentString(…) – возвращает адрес блока переменных окружения.
Структуры данных процесса.
| TEB |
| PEB |
Адресное пространство
процесса
| PDB |
| Блок процесса Win32 |
пространство
| TDB |
| Таблица дискрипторов |
1 i87EmR+Q+PbhgzOJZWikDebI4a6X8yy7ls50xB9aM+B9i/XndnQaNuvlSr2uxqkO7w/50+55/fgW ldbnZ9PdLYiEU/ozww8+o0PFTHs/ko2iZ32jrtiqYZ7lINhwmSke9r8LWZXyf4PqGwAA//8DAFBL AQItABQABgAIAAAAIQC2gziS/gAAAOEBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhADj9If/WAAAAlAEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAFyz9JljAgAAfQQAAA4AAAAAAAAAAAAAAAAALgIAAGRycy9l Mm9Eb2MueG1sUEsBAi0AFAAGAAgAAAAhAPcZ0UneAAAACQEAAA8AAAAAAAAAAAAAAAAAvQQAAGRy cy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPMAAADIBQAAAAA= " o:allowincell="f"> …
EB – Environment Block. PEB – блок окружения процесса. TEB – блок окр. потока. TDB – база данных потока. PDB – бд процесса.
PDB или EProcess содержат данные, необходимые ОС для управления процессом и указатели на некоторые доп. структуры.
Блок PDB.Дескрипторы виртуальных адресов – это структуры, описывающие распределение ВАП.Указатель на цепочку потоков данного процесса.Указатель на таблицу дескрипторов.Указатель на блок переменных окружения PEB.
Блок KPROCESS.Содержит доп. информацию:указатель на каталог страниц процесса, базовый приоритет по умолчанию.
Блок переменных окружения (PEB).Расположен в пользовательском адресном пространстве.В Windows 2000 находится по адресу 7FFDF000h. Содержит следующую информацию:Адрес кучи процесса по умолчанию.Указатель на структуры, описывающий загруженные модули.IMTE – описывает все загруженные модули всеми процессами.MODREF – содержит список всех модулей, используемых данным процессом.Содержит указатель на список файлов, которые используются данным процессом.Указатель на базу данных среды, которая содержит текущий каталог, область окружения процесса, командную строку.Указатель на заголовок списка свободного пространства в куче по умолчанию.Указатель на заголовок связанного списка куч процесса.
Таблица дескрипторов.
Таблица дескрипторов содержит не только дескрипторы файлов, но и объектов ядра. Структу-ра таблицы дескрипторов:
| Количество записей | 4байта |
| Флаг 1 | 8 байт |
| Объект 1 | |
| … | |
| Флаг N | 8 байт |
| Объект N |
Первые 4 байта определяют количество записей в таблице дескрипторов (30h). Если таблица заполнена, то Windows создаёт кучу, делая прибавление 10h и так далее, то есть для Windows ограничения в 255 дескрипторов не существует. После количества записей идёт массив 8 байтных структур. Каждая структура состоит из двух полей.
1 поле. Флаг управления доступом к объекту. Назначение флагов различно для различных типов объекта. Например объект – процесс. Флаг – процесс завершён. Следующее DWORD – указатель базы данных соответствующего объекта.
Переменная ядра, связанная с процессами.PsActiveProcessHead. Заголовок списка блоков PDB. CreateProcess(…) открывет ехе файл, который будет выполняться в процессе, то есть PDB. Создаёт первичный поток, то есть стек потока, контекст потока (содержимое всех регистров) и объект поток, то есть TDB.
15. Потоки. Состояния потоков. Свойства потоков. Объект ядра поток. Функции для работы с потоками.
Потоки отвечают за исполнение программного кода. При создании процесса всегда создаётся первичный поток. По желанию программиста создаются дополнительные потоки. CreateThread(…). Для чего создаются потоки?
Выделив различные задачи, выполняемые процессом в отдельном потоке позволяет избежать цикла опросов.
Поток может находится в одном из 3-х состояний:
1. Поток фактически работает, при этом в регистре процессора переписывается содержимое структуры CONTEXT. Все остальные потоки процесса приостанавливаются в случае одного процессора в системе.
2. Поток готов к выполнению. Отсутствуют все причины, препятствующие работе потока, за исключением того, что процессор занят выполнением другого потока.
3. Заблокированное состояние. Поток ожидает некоторого события, например, ожидание завершения работы другого потока или какого-либо процесса. До наступление этого события планировщик не позволит этому процессу выполнится.
Объектами синхронизации являются потоки процессы, критические секции, семафоры, события, мьютексы.
Потоки владеют набором регистров.
Все потоки процесса имеют общий доступ к тому, чем этот процесс владеет, т.е. к адресному пространству процесса (различным регионам адресного пространства). Все потоки процесса совместно используют одни и те же значения дескрипторов, следовательно они могут обращаться к файлам, событиям, файлам проецируемым в память, которые принадлежат процессу.
Каждый поток обладает собственным стеком, собственной очередью оконных сообщений, собственным набором значений локальной памяти потока и собственной цепочкой обработки структу-рированных исключений.
Поток может завладеть или освободить синхронизирующими объектами процесса. Дескриптор потока – это индекс в таблице дескрипторов процесса. Идентификатор потока – это закодированный указатель на базу данных потока (PDB).
Структура ОЯ «поток».
1) TDB (ETHREAD). Начинается со стандартного заголовка, который содержит идентификатор объекта (от 0 до 27) и счётчик числа обращений к данному объекту. Далее следует указатель на структуру KTHREAD – блок потока ядра, указатель на PDB (EPROCESS), откуда поток может извлекать, структура CONTEXT – содержит описание регистров, время создания и завершения потока, стартовый адрес потока, и так далее.
2) KTHREAD. Содержит информацию необходимую ядру Windows для планирования и синхронизации одних потоков с другими.
· суммарное время работы в пользовательском режиме,
· суммарное время работы в режиме ядра,
· базовый и текущий приоритеты потока,
· значение кванта (для Windows 2000),
· маска привязки к процессорам, то есть в многопроц. системе - информация, на каких процессорах выполняется данный поток.
· список объектов, ожидаемых данным потоком, например, поток ждёт завершения какого-либо другого потока.
· указатель на блок окружения потока, который находится в пользовательском адресном пространстве.
3) TEB. В нём содержится информация о стеке потока, базовый адрес.
| ///////////////////////// |
старший адрес
текущий адрес стека
базовый адрес стека младший адрес
В блоке TEB содержится локальная память потока TLS, значение кода последней ошибки, то есть LastError. Даные необходимые для работы модулей user32.dll и GDI32. В том случае, если поток работает в сети в TEB содержится указатель на данные WinSock.
4) W32THREAD. Дублирует данные, необходимые для работы user32 и gdi32.
Алгоритм работы функции CreateThread(…) (kernel32.dll).
1. Создаёт стек пользовательского режима в адресном пространстве процесса.
2. Инициализирует аппаратный процесс потока, то есть структуру CONTEXT.
3. Вызывает функцию ядра NtCreateThread(…), которая создаёт все упр. структуры, которые находятся в сист-ой части адр. пр-ва.
4. Создаёт блок TEB.
5. Уведомляется подсистема Win32, которая создаёт блок W32THREAD.
6. Возвращает дескриптор и идентификатор вызывающей программе вновь созданного потока.
7. Вновь созданный поток ставится в очередь на выполнение.
16. Распределение времени между потоками. Классы приоритета. Уровни приоритета. Относительный уровень приоритета потока. Функции для работы с приоритетами потоков.
1) Планирование потоков. 2)Синхронизация потоков.
В Windows реализована подсистема вытесняющего планирования на основе уровней приоритета. Всегда выполняется поток с наивысшим приоритетом к выполнению. Выбор потока для выполнения может быть ограничен набором процессоров. Это называется привязкой к процессору (processor affinity).
Выбранный для выполнения поток работает в течение некоторого периода называемого квантом. После того, как истёк квант времени ОС будет искать другой поток с таким же уровнем приоритета или выше. Если таких нет, то ищет с меньшим приоритетом. В Windows 2000 потокам могут выделяться разные кванты времени. Поток также может не полностью использовать свой квант.
Как только другой поток с более высоким приор-ом готов к вып-нию, текущий поток вытесняется даже если его квант не истёк.
Код Windows, отвечающий за планирование реализован в ядре ОС. Этот код рассредоточен по ядру, поэтому нет единого модуля или процедуры с названием планировщик. Совокупность процедур, выполняющих планирование - диспетчер ядра.
Диспетчер ядра инициализируется следующими событиями.
1) Поток готов к выполнению, например, он только что создан или вышел из состояния ожидания.
2) Поток прекращает выполнение, когда его квант истёк или поток завершается, или поток переходит в состояние ожидания.
3) Приоритет потока изменяется, например, в результате вызова системного сервиса.
4) Изменяется привязка к процессорам выполняемого потока.
В любом из этих четырёх случаев Windows должна определить, какой поток должен выполняться следующим.
Выбрав новый поток Windows включает CONTEXT, текущее содержание регистров процессора переписывается в структуру CONTEXT, которая находится в TDB (ETHREAD).
Планирование в Windows осуществляется на уровне потоков, то есть не важно какому процессу принадлежит поток.
Пример. Если у процесса А – 12 потоков, а у В – 2 потока, и все 14 потоков имеют один и тот же приоритет, то каждый поток получит 1/14 времени процессора. Windows не будет делить поровну время процессора между двумя процессами.
Уровни приоритета.
В Windows поддерживается 32 уровня приоритета от 0 до 31. Все приоритеты делятся на четыре класса. Класс приоритета присваивается процессу с помощью одного из флагов функции CreateProcess. Рассмотрим связь уровней приоритета с классами.
| Класс | Описание | Флаг | Уровень приоритета |
| Idle | приостановлен | IDLE_PRIORITY_CLASS |