Подсистема Win32
Взаимодействие между приложением и операционной системой осуществляется при помощи системных вызовов (системных сервисов в терминологии Microsoft). Однако приложение не может вызвать системный вызов напрямую (более того, системные вызовы не документированы). Вместо этого приложение должно воспользоваться программным интерфейсом ОС - Win32 API.Win32 API (Application Programming Interface)- основной интерфейс программирования в семействе операционных систем Microsoft Windows. Функции Win32 API , например,CreateProcessилиCreateFile, - документированные, вызываемые подпрограммы, реализуемые Win32 подсистемой.В состав Win32 подсистемы (см.рис. 1.4) входят: cерверный процесс подсистемы окружения csrss.exe, драйвер режима ядра Win32k.sys, dll - модули подсистем (kernel32.dll, advapi32.dll, user32.dll и gdi32.dll), экспортирующие Win32-функции и драйверы графических устройств. В процессе эволюции структура подсистемы претерпела изменения. Например, функции окон и рисования с целью повышения производительности были перенесены из серверного процесса, работающего в режиме пользователя, в драйвер режима ядра Win32k.sys. Однако это и подобные изменения никак не отразились на работоспособности приложений, поскольку существующие вызовы Win32 API не изменяются с новыми выпусками системы Windows, хотя их состав постоянно пополняется. Приложение, ориентированное на использование Win32 API, может работать практически на всех версиях Windows, несмотря на то, что сами системные вызовы в различных системах различны (см.рис. 1.5). Таким путем корпорация Microsoft обеспечивает преемственность своих операционных систем.
Рис. 1.5. Поддержка единого программного интерфейса для различных версий Windows
При запуске процесса все требуемые динамические библиотеки отображаются на его виртуальное адресное пространство, а для быстрого вызова библиотечной процедуры используется специальный вектор передачи.
Рис. 1.6. Различные маршруты выполнения вызовов Win32 API.
При вызове приложением одной из Win32-функций dll-подсистем может возникнуть одна из трех ситуаций (см. рис. 1.6).
Функция полностью выполняется внутри данной dll (шаг 1).
Для выполнения функции привлекается сервер csrss, для чего ему посылается сообщение (шаг 2a, за которым обычно следуют шаги 2b и 2c).
Данный вызов транслируется в системный сервис (системный вызов), который обычно обрабатывается в модуле ntdll.dll (шаги 3a и 3b). Например, Win32-функция ReadFileвыполняется с помощью недокументированного сервисаNtReadFile.Некоторые функции (например,CreateProcess) требуют выполнения обоих последних пунктов.В первых версиях ОС Windows практически все вызовы Win32 API выполнялись, следуя маршруту 2 (2a, 2b, 2c). После того, как существенная часть кода системы для увеличения производительности была перенесена в ядро (начиная с Windows NT 4.0), вызовы Win32 API, как правило, идут напрямую по 3-му (3a, 3b) пути, минуя подсистему окружения Win32. В настоящее время лишь небольшое число вызовов выполняется по длинному 2-му маршруту.Помимо перечисленных, наиболее важных dll-библиотек, в системном каталогеsystem32имеется большое количество других dll-файлов. В настоящее время количество вызовов API составляет несколько десятков тысяч. Список экспортируемых каждой конкретной dll функций можно посмотреть с помощью утилитыdepends, входящей в пакет Platform SDK. Так, нарис. 1.7приведена информация о структуре библиотеки kernel32.dll ОС Windows XP, экспортирующей 949 функций.
Рис. 1.7. Окно утилиты depends.exe
DLL (динамически подключаемая библиотека)
Набор вызываемых подпрограмм, включенных в один двоичный файл, который приложения, использующие эти подпрограммы, могут динамически загружать в процессе своего выполнения. В качестве примера можно привести модули Msvcrt.dll (библиотека исполняющей Си подсистемы) и Kernel32.dll (одна из библиотек подсистемы Win32). DLL активно используются компонентами и приложениями ОС Windows пользовательского режима. Преимущество DLL перед статическими библиотеками состоит в том, что приложения могут разделять DLL-модули, при этом ОС Windows гарантирует, что в памяти будет находиться лишь по одному экземпляру используемых DLL.
Процессы и потоки
Под процессомпонимается контейнер ресурсов, используемыхпотоками. Процесс включает: закрытое адресное пространство, в котором располагаются код, данные и стеки потоков; список открытых описателей ресурсов; контекст защиты; идентификатор процесса.Поток команд исполняемой программы, или простопоток- сущность внутри процесса, получающая процессорное время. Поток характеризуется набором регистров (состоянием), идентификатором потока, стеками режимов ядра и пользователя.
Основные компоненты ядра Windows NT. Подсистемы Win32,POSIX,OS/2. Библиотека NTdll.dll.
Основные компоненты ядра Windows NT. Подсистемы Win32,POSIX,OS/2. Библиотека NTdll.dll.
В режиме ядра выполняются следующие компоненты ОС:
исполняемая часть NT, которая включает управление памятью, процессами, потоками, безопасностью, вводом/выводом, межпроцессорными обменами;
ядро Windows NTвыполняет низкоуровневые функции операционной системы: диспетчеризация потоков, прерываний и исключений, синхронизация процессоров. Ядро также включает набор процедур и базовых объектов, используемый исполняемой частью для создания высокоуровневых конструкций;
слой абстракции от оборудования (HAL - Hardware Abstraction Layer), изолирует ядро, драйверы устройств и исполняемую часть NT от аппаратных платформ, на которых должна работать операционная система;
драйверы устройстввключают как файловую систему, так и аппаратные драйверы, которые транслируют пользовательские вызовы функций ввода/вывода в запросы физических устройств ввода/вывода;
функции графического интерфейса пользователяработают с окнами, элементами управления и рисунками.
Подсистемы среды и библиотеки DLL
Как видно из рис. 1, Windows NT имеет три подсистемы среды (Win32, Posix и OS/2 2.1), которые работают только на платформе х86. Подсистема Win32 специфична для Windows NT и не может работать вне ее.
Каждая из подсистем обеспечивает пользовательским приложениям доступ к разным поднаборам служб Windows NT. Это означает, что некоторые вещи могут быть сделаны из приложения, построенного на одной подсистеме, и не возможны из приложения, построенного в другой подсистеме. Так, приложение для Win32 не может использовать функцию fork подсистемы Posix.
Каждый исполняемый модуль связывается с одной и только одной подсистемой. Когда начинается выполнение модуля, изучается тип кода его заголовка, что позволяет определить подсистему среды для создания новых процессов.
Пользовательские процессы не вызывают службы NT напрямую, а используют библиотеки динамических связей (DLL) соответствующей подсистемы среды. Роль библиотек, принадлежащих подсистеме среды, в том, чтобы транслировать документированные функции среды в соответствующие вызовы недокументированных служб NT. Эти библиотеки DLL экспортируют документированный интерфейс, который могут вызывать связанные с подсистемой программы. Например, библиотеки DLL подсистемы Win32 используют функции Win32 API. Библиотека DLL подсистемы Posix использует функции Posix 1003.1 API.
Подсистема Win32. Главные компоненты подсистемы Win32 - процесс подсистемы среды и драйвер режима ядра. Процесс подсистемы среды поддерживает:
консольные (текстовые) окна;
создание и удаление процессов и потоков;
работу виртуальной 16-разрядной DOS машины;
иные функции (GetTempFile, DefineDosDevice, ExitWindowsEx и др.).
Драйвер режима ядра поддерживает:
менеджер окон, который управляет отображением окон, выводом на экран, вводом с клавиатуры, от мыши и других устройств, а также передачей пользовательских сообщений приложениям;
интерфейс графических устройств GDI (Graphical Device Interface), библиотека функций для вывода на графические устройства, для рисования текста, линий, фигур и манипуляций графическими объектами;
зависимые от устройств драйверы графики, принтера и видеопорта;
несколько библиотек DLL, которые транслируют документированные функции Win32 API в соответствующие недокументированные вызовы NTOSKRNL.EXE и WIN32K.SYS.
Приложения вызывают стандартные функции для создания окон и кнопок на дисплее. Менеджер окон передает эти запросы драйверам графических устройств через интерфейс графических устройств GDI, где они форматируются для вывода средствами конкретных устройств. GDI обеспечивает набор стандартных функций, позволяющих приложениям общаться с графическими устройствами, включая дисплеи и принтеры, без конкретных знаний о них. GDI интерпретирует запросы приложений на графический вывод и посылает их драйверам графических дисплеев. Этот интерфейс позволяет создавать код приложения, независимый от конкретных устройств и их драйверов.
NTDLL.DLL - это специальная система поддержки DLL - библиотек. Она содержит два типа функций.
Первая группа функций обеспечивает интерфейс к службам NT, которые могут быть вызваны из пользовательского режима. Существует более 200 таких функций, например NtCreateFile, NtSetEvent и т.д. Для каждой из них имеется точка входа в NTDLL.DLL с тем же именем. Внутренний код функции содержит специфичные для архитектуры команды, которые вызывают переход в режим ядра для обращения к реальным службам NT, код которых содержится в NTOSKRNL.EXE.
Вторая группа функций содержит большое количество функций поддержки: загрузчик исполняемых модулей, коммуникационные функции для процессов подсистемы Win32, библиотека функций реального времени пользовательского режима, диспетчер вызовов асинхронных процедур АРС (Asynchronous Procedure Call) пользовательского режима, диспетчер исключений.
___________________________________________________
Компоненты ядра
Компоненты пользовательского режима
Подсистема пользовательского интерфейса в Windows NT реализует оконный интерфейс, подобный интерфейсу предыдущих версий Windows. Двумя типами объектов этой подсистемы, отсутствовавшими в 16-битных версиях Windows и в Windows 9x, являются оконные станции и рабочие столы. Оконная станция соответствует одному сеансу пользователя Windows NT — например, при подключении через службу удалённого рабочего стола создаётся новая оконная станция. Каждый запущенный процесс принадлежит к одной из оконных станций; службы, кроме помеченных как способные взаимодействовать с рабочим столом, запускаются в отдельных, невидимых оконных станциях.
Каждая оконная станция имеет собственный буфер обмена, набор глобальных атомов (используемых для операций DDE), и набор рабочих столов. Рабочий стол является контекстом всех глобальных операций подсистемы пользовательского интерфейса, таких как установка хуков и широковещательная рассылка сообщений. Каждый запущенный поток принадлежит к одному из рабочих столов — тому, где расположены обслуживаемые им окна; в частности, один поток не может создать несколько окон, принадлежащих к различным рабочим столам. Один из рабочих столов может быть активным (видимым пользователю и способным реагировать на его действия), остальные рабочие столы спрятаны. Возможность создать для одного сеанса работы несколько рабочих столов и переключаться между ними до настоящего времени не предоставлялась стандартными средствами пользовательского интерфейса Windows, хотя существуют сторонние программы, дающие доступ к этой функциональности.
Оконными станциями и рабочими столами исчерпываются объекты подсистемы пользовательского интерфейса Windows NT, которым могут быть назначены права доступа. Оставшиеся типы объектов — окна и меню — предоставляют полный доступ любому процессу, который находится с ними в одной оконной станции. Поэтому службы Windows NT по умолчанию запускаются в отдельных оконных станциях: они работают с повышенными привилегиями, и возможность процессов пользователя неограниченно манипулировать окнами служб могла бы привести к сбоям и/или проблемам безопасности.
Программные интерфейсы
Native API
Для прикладных программ системой Windows NT предоставляется несколько наборов API. Самый основной из них — так называемый «родной» API (NT Native API), реализованный в динамически подключаемой библиотеке ntdll и состоящий из двух частей: системные вызовы ядра NT (функции с префиксами Nt и Zw, передающие выполнение функциям ядра ntoskrnl с теми же названиями) и функции, реализованные в пользовательском режиме (с префиксом Rtl). Часть функций второй группы используют внутри себя системные вызовы; остальные целиком состоят из непривилегированного кода, и могут вызываться не только из кода пользовательского режима, но и из драйверов. Кроме функций Native API, в ntdll также включены функции стандартной библиотеки языка Си.
Официальная документация на Native API весьма скудна, но сообществам энтузиастов удалось методом проб и ошибок собрать достаточно обширные сведения об этом интерфейсе. В частности, в феврале 2000 г. опубликована книга Гэри Неббета «Справочник по базовым функциям API Windows NT/2000» (ISBN 1-57870-199-6); в 2002 г. она была переведена на русский язык (ISBN 5-8459-0238-X). Источником информации о Native API может служить Windows DDK, где описаны некоторые функции ядра, доступные посредством Native API, а также изучение кода Windows (обратный инжиниринг) — посредством дизассемблирования, либо используя исходные тексты Windows 2000, ставшие доступными в результате утечки, либо используя исходные тексты Windows 2003, доступные в рамках программы Windows Research Kernel.
Программы, выполняющиеся до загрузки подсистем, обеспечивающих работу остальных API ОС Windows NT, ограничены использованием Native API. Например, программа autochk, проверяющая диски при загрузке ОС после некорректного завершения работы, использует только Native API.
Win32 API
Чаще всего прикладными программами для Windows NT используется Win32 API — интерфейс, созданный на основе API ОС Windows 3.1, и позволяющий перекомпилировать существующие программы для 16-битных версий Windows с минимальными изменениями исходного кода. Совместимость Win32 API и 16-битного Windows API настолько велика, что 32-битные и 16-битные приложения могут свободно обмениваться сообщениями, работать с окнами друг друга и т. д. Кроме поддержки функций существовавшего Windows API, в Win32 API был также добавлен ряд новых возможностей, в т.ч. поддержка консольных программ, многопоточности, и объектов синхронизации, таких как мутексы и семафоры. Документация на Win32 API входит в состав Microsoft Platform SDK (англ.) и доступна на веб-сайте http://msdn2.microsoft.com/en-us/library/
Библиотеки поддержки Win32 API в основном названы так же, как системные библиотеки Windows 3.x, с добавлением суффикса 32: это библиотеки kernel32, advapi32, gdi32, user32, comctl32, comdlg32, shell32 и ряд других. Функции Win32 API могут либо самостоятельно реализовывать требуемую функциональность в пользовательском режиме, либо вызывать описанные выше функции Native API, либо обращаться к подсистеме csrss посредством механизма LPC (англ.), либо осуществлять системный вызов в библиотеку win32k, реализующую необходимую для Win32 API поддержку в режиме ядра. Четыре перечисленных варианта могут также комбинироваться в любом сочетании: например, функция Win32 API WriteFile обращается к функции Native API NtWriteFile для записи в дисковый файл, и вызывает соответствующую функцию csrss для вывода в консоль.
Поддержка Win32 API включена в семейство ОС Windows 9x; кроме того, она может быть добавлена в Windows 3.1x установкой пакета Win32s. Для облегчения переноса существующих Windows-приложений, использующих для представления строк MBCS-кодировки, все функции Win32 API, принимающие параметрами строки, были созданы в двух версиях: функции с суффиксом A (ANSI) принимают MBCS-строки, а функции с суффиксом W (wide) принимают строки в кодировке Unicode. В Win32s и Windows 9x поддерживаются только A-функции, тогда как в Windows NT, где все строки внутри ОС хранятся исключительно в Юникоде, каждая A-фунция просто преобразует свои строковые параметры в Юникод и вызывает W-версию той же функции. Когда имя функции в исходном тексте программы указано без суффикса, использование A- либо W-версии этой функции определяется опциями компиляции. При этом важно отметить, что большинство новых функций, появившихся в Windows 2000 или более поздних ОС семейства Windows NT, существуют только в Unicode-версии, потому что задача обеспечения совместимости со старыми программами и с ОС Windows 9x уже не стоит так остро, как раньше.
POSIX и OS/2
Подсистема окружения POSIX поддерживает приложения написанные в соответствии со стандартом POSIX.1. В отличие от большинства «свободных» Unix-подобных ОС, Windows NT сертифицирована институтом NIST на совместимость со стандартом POSIX.1, и даже с более строгим стандартом FIPS 151-2. Библиотекой psxdll экспортируются стандартные функции POSIX, а также некоторые функции Native API, не имеющие аналогов в POSIX — например, для работы с кучей, со структурными исключениями, с кодировкой Unicode. Внутри этих функций используются как Native API, так и LPC-вызовы в подсистему psxss, являющуюся обычным Win32-процессом. Для загрузки этой подсистемы и выполнения POSIX-программы используется консольная программа-оболочка posix.Поддержка POSIX, включённая в Windows NT, не содержит расширений для работы с графикой или многопоточными приложениями.
Для выполнения 16-битных программ, написанных для OS/2 1.x, в состав Windows NT включены две системных библиотеки OS/2 (doscalls и netapi) и консольная программа-эмулятор os2, которая загружает и использует посредством LPC-вызовов подсистемы os2srv и os2ss. Остальные системные библиотеки OS/2, кроме двух названных (kbdcalls, mailslot, moncalls, nampipes, quecalls, viocalls и ещё десяток), не хранятся как отдельные файлы, а эмулируются.Программы, написанные для OS/2 2.0 и выше, а также оконные программы и программы, напрямую работающие с устройствами компьютера, в том числе драйвера, системой Windows NT не поддерживаются.
Обе эти подсистемы, необязательные для работы большинства приложений, были удалены в Windows XP и последующих выпусках Windows. При помощи манипуляций с реестром их можно было отключить и в предыдущих версиях Windows NT, что рекомендовалось специалистами по компьютерной безопасности в целях сокращения поверхности атаки компьютерной системы.
Ядро и модуль поддержки оборудования. Драйверы устройств, типы. Усовершенствования в драйверах устройств в Windows NT 2000.
Ядро Windows NT представляет собой следующий уровень после уровня аппаратных абстракций, который обеспечивает работу выполняемого модуля Windows NT и других подсистем. Ядро системы выполняет следующие основные функции:
помощь в синхронизации данных;
планирование выполнения потоков и процессов;
управление прерываниями и исключениями;
восстановление системы после аварийных ситуаций, например после отказа питания.
Данные ядра всегда находятся в оперативной памяти и никогда не выгружаются на диск, как это происходит с пользовательскими приложениями. Данные ядра не могут быть вытеснены другими данными. Это значит, что выполнение кода ядра не может быть прервано ради другого кода, если только ядро не выполняет это самостоятельно.
Ядро представляет собой объектно-ориентированную систему, в которой используется два класса объектов. 1. Объекты-диспетчеры, которые позволяют управлять потоками и процессами и применяются для синхронизации различных потоков/процессов. В число объектов-диспетчеров входят мьютекс-флаги (mutex — это сокращение от "mutual exclusion", т.е. взаимное исключение), семафоры (semaphore) и таймеры (timer). Мьютекс-флаги являются объектами синхронизации и используются для синхронизации данных между двумя компонентами. 2. Объекты управления, например асинхронные вызовы процедур (asynchronous procedure calls — АРС) и процедуры обслуживания прерываний (interrupt service routines — ISR).
Драйверы устройств– модули в режиме ядра, которые могут подгружаться во время работы ОС.
Дра́йвер(англ.driver, мн. ч.дра́йверы[1]) —компьютерная программа, с помощью которой другие программы (операционная система) получают доступ каппаратному обеспечениюнекоторого устройства. Обычно с операционными системами поставляются драйверы для ключевых компонентов аппаратного обеспечения, без которых система не сможет работать.
Операционная система управляет некоторым «виртуальным устройством», которое понимает стандартный набор команд. Драйвер переводит эти команды в команды, которые понимает непосредственно устройство. Эта идеология называется «абстрагирование от аппаратного обеспечения».
Задача образуют интерфейс между устройством и диспетчером ввода/вывода. Драйвер может выполняться в режиме ядра в одном из контекстов
1). В контексте пользовательского потока, инициировавшего процедуру ввода/вывода.
2). В контексте системного потока режима ядра.
3). Реализуется как результат прерывания.
Типы драйверов устройств
1). Драйверы аппаратных устройств, которые управляют устройствами оборудования через HAL(другие шины, интерфейсы и т.д.).
2). Драйверы файловой системы – принимают запросы ввода/вывода от пользовательских приложений и транслировать их к виду, в котором их воспримет конкретное устройство.
3). Драйвер фильтров файловой системы – обеспечивают зеркалирование, объединение устройств, шифрование устройств, т.е. нужный драйвер загружается в нужный момент в нужной последовательности(плюс скорость и безопасность).
4). Драйвер протоколов – реализует сетевые протоколы.
5). Драйверы потоковых фильтров ядра – действуют по цепочке для обработки потоковых данных(запись, воспроизведение видео).
Существует 3 типа драйверов
1). Драйвер шин – задача обслужить контроллер шины, адаптерный мост или другие устройства, имеющие дочерние устройства.
2). Функциональный драйвер оснащает другие устройства, предоставляющие его функциональный интерфейс.
3). Драйвер фильтра – фильтрация информации, дополнять функциональные устройства дополнительными, фильтрация информации, передаваемой между устройствами, увеличивает функциональность драйверов устройств.
Планирование потоков. Сценарии планирования. Кванты.
Планирование процессов и потоков
Одной из основных подсистем мультипрограммной ОС, непосредственно влияющей на функционирование вычислительной машины,является подсистема управления процессами и потоками, которая занимается их созданием и уничтожением, поддерживает взаимодействие между ними, а также распределяет процессорное время между несколькими одновременно существующими в системе процессами и потоками.
Подсистема управления процессами и потоками ответственна за обеспечение процессов необходимыми ресурсами. ОС поддерживает в памяти специальные информационные структуры, в которые записывает, какие ресурсы выделены каждому процессу. Она может назначить процессу ресурсы в единоличное пользование или в совместное пользование с другими процессами. Некоторые из ресурсов выделяются процессу при его создании, а некоторые — динамически по запросам во время выполнения. Ресурсы могут быть приписаны процессу на все время его жизни или только на определенный период. При выполнении этих функций подсистема управления процессами взаимодействует с другими подсистемами ОС, ответственными за управление ресурсами, такими как подсистема управления памятью, подсистема ввода-вывода, файловая система.
Когда в системе одновременно выполняется несколько независимых задач, то возникают дополнительные проблемы. Хотя потоки возникают и выполняются асинхронно, у них может возникнуть необходимость во взаимодействии, например при обмене данными. Согласование скоростей потоков также очень важно для предотвращения эффекта «гонок» (когда несколько потоков пытаются изменить один и тот же файл), взаимных блокировок или других коллизий, которые возникают при совместном использовании ресурсов. Синхронизация потоков является одной из важных функций подсистемы управления процессами и потоками.
Каждый раз, когда процесс завершается, ОС предпринимает шаги, чтобы «зачистить следы» его пребывания в системе. Подсистема управления процессами закрывает все файлы, с которыми работал процесс, освобождает области оперативной памяти, отведенные под коды, данные и системные информационные структуры процесса. Выполняется коррекция всевозможных очередей ОС и списков ресурсов, в которых имелись ссылки на завершаемый процесс.
Алгоритмы планирования, основанные на квантовании
В основе многих вытесняющих алгоритмов планирования лежит концепция квантования. В соответствии с этой концепцией каждому потоку поочередно для выполнения предоставляется ограниченный непрерывный период процессорного времени — квант. Смена активного потока происходит, если:
поток завершился и покинул систему;
произошла ошибка;
поток перешел в состояние ожидания;
исчерпан квант процессорного времени, отведенный данному потоку.
Поток, который исчерпал свой квант, переводится в состояние готовности и ожидает, когда ему будет предоставлен новый квант процессорного времени, а на выполнение в соответствии с определенным правилом выбирается новый поток из очереди готовых. Граф состояний потока, изображенный на рис. 4.6, соответствует алгоритму планирования, основанному на квантовании.
Рис. 4.6. Граф состояний потока в системе с квантованием
Кванты, выделяемые потокам, могут быть одинаковыми для всех потоков или различными. Рассмотрим, например, случай, когда всем потокам предоставляются кванты одинаковой длины q (рис. 4.7). Если в системе имеется п потоков, то время, которое поток проводит в ожидании следующего кванта, можно грубо оценить как q(n-l). Чем больше потоков в системе, тем больше время ожидания, тем меньше возможности вести одновременную интерактивную работу нескольким пользователям. Но если величина кванта выбрана очень небольшой, то значение произведения q(n-l) все равно будет достаточно мало для того, чтобы пользователь не ощущал дискомфорта от присутствия в системе других пользователей. Типичное значение кванта в системах разделения времени составляет десятки миллисекунд.
Рис. 4.7.Иллюстрация расчета времени ожидания в очереди
Если квант короткий, то суммарное время, которое проводит поток в ожидании процессора, прямо пропорционально времени, требуемому для его выполнения (то есть времени, которое потребовалось бы для выполнения этого потока при монопольном использовании вычислительной системы). Действительно, поскольку время ожидания между двумя циклами выполнения равно q(n-l), а количество циклов B/q, где В — требуемое время выполнения, то W*B(n-l). Заметим, что эти соотношения представляют собой весьма грубые оценки, основанные на предположении, что В значительно превышает q. При этом не учитывается, что потоки могут использовать кванты не полностью, что часть времени они могут тратить на ввод-вывод, что количество потоков в системе может динамически меняться и т. д.
Чем больше квант, тем выше вероятность того, что потоки завершатся в результате первого же цикла выполнения, и тем менее явной становится зависимость времени ожидания потоков от их времени выполнения. При достаточно большом кванте алгоритм квантования вырождается в алгоритм последовательной обработки, присущий однопрограммным системам, при котором время ожидания задачи в очереди вообще никак не зависит от ее длительности.
Кванты, выделяемые одному потоку, могут быть фиксированной величины, а могут и изменяться в разные периоды жизни потока. Пусть, например, первоначально каждому потоку назначается достаточно большой квант, а величина каждого следующего кванта уменьшается до некоторой заранее заданной величины. В таком случае преимущество получают короткие задачи, которые успевают выполняться в течение первого кванта, а длительные вычисления будут проводиться в фоновом режиме. Можно представить себе алгоритм планирования, в котором каждый следующий квант, выделяемый определенному потоку, больше предыдущего. Такой подход позволяет уменьшить накладные расходы на переключение задач в том случае, когда сразу несколько задач выполняют длительные вычисления.
Потоки получают для выполнения квант времени, но некоторые из них используют его не полностью, например из-за необходимости выполнить ввод или вывод данных. В результате возникает ситуация, когда потоки с интенсивными обращениями к вводу-выводу используют только небольшую часть выделенного им процессорного времени. Алгоритм планирования может исправить эту «несправедливость». В качестве компенсации за неиспользованные полностью кванты потоки получают привилегии при последующем обслуживании. Для этого планировщик создает две очереди готовых потоков (рис. 4.8). Очередь 1 образована потоками, которые пришли в состояние готовности в результате исчерпания кванта времени, а очередь 2 — потоками, у которых завершилась операция ввода-вывода. При выборе потока для выполнения прежде всего просматривается вторая очередь, и только если она пуста, квант выделяется потоку из первой очереди.
Многозадачные ОС теряют некоторое количество процессорного времени для выполнения вспомогательных работ во время переключения контекстов задач. При этом запоминаются и восстанавливаются регистры, флаги и указатели стека, а также проверяется статус задач для передачи управления. Затраты на эти вспомогательные действия не зависят от величины кванта времени, поэтому чем больше квант, тем меньше суммарные накладные расходы, связанные с переключением потоков.
Рис. 4.8. Квантование с предпочтением потоков, интенсивно обращающихся к вводу-выводу
ПРИМЕЧАНИЕ
В алгоритмах, основанных на квантовании, какую бы цель они не преследовали (предпочтение коротких или длинных задач, компенсация недоиспользованного кванта или минимизация накладных расходов, связанных с переключениями), не используется никакой предварительной информации о задачах. При поступлении задачи на обработку ОС не имеет никаких сведений о том, является ли она короткой или длинной, насколько интенсивными будут ее запросы к устройствам ввода-вывода, насколько важно ее быстрое выполнение и т. д.
Вытесняющие и невытесняющие алгоритмы планирования
С самых общих позиций все множество алгоритмов планирования можно разделить на два класса: вытесняющие и невытесняющие алгоритмы планирования.
Невытесняющие (non-preemptive) алгоритмы основаны на том, что активному потоку позволяется выполняться, пока он сам, по собственной инициативе, не отдаст управление операционной системе для того, чтобы та выбрала из очереди другой готовый к выполнению поток.
Вытесняющие (preemptive) алгоритмы — это такие способы планирования потоков, в которых решение о переключении процессора с выполнения одного потока на выполнение другого потока принимается операционной системой, а не активной задачей.
5. Состояния потока. Уровни приоритета.
Состояния потока
ОС выполняет планирование потоков, принимая во внимание их состояние. В мультипрограммной системе поток может находиться в одном из трех основных состояний:
выполнение — активное состояние потока, во время которого поток обладает всеми необходимыми ресурсами и непосредственно выполняется процессором;
ожидание — пассивное состояние потока, находясь в котором, поток заблокирован по своим внутренним причинам (ждет осуществления некоторого события, например завершения операции ввода-вывода, получения сообщения от другого потока или освобождения какого-либо необходимого ему ресурса);
готовность — также пассивное состояние потока, но в этом случае поток заблокирован в связи с внешним по отношению к нему обстоятельством (имеет все требуемые для него ресурсы, готов выполняться, однако процессор занят выполнением другого потока).
ПРИМЕЧАНИЕ
Состояния выполнения и ожидания могут быть отнесены и к задачам, выполняющимся в однопрограммном режиме, а вот состояние готовности характерно только для режима мультипрограммирования.
В течение своей жизни каждый поток переходит из одного состояния в другое в соответствии с алгоритмом планирования потоков, принятым в данной операционной системе.
Рассмотрим типичный граф состояния потока (рис. 4.3). Только что созданный поток находится в состоянии готовности, он готов к выполнению и. стоит в очереди к процессору. Когда в результате планирования подсистема управления потоками принимает решение об активизации данного потока, он переходит в состояние выполнения и находится в нем до тех пор, пока либо он сам освободит процессор, перейдя в состояние ожидания какого-нибудь события, либо будет принудительно «вытеснен» из процессора, например вследствие исчерпания отведенного данному потоку кванта процессорного времени. В последнем случае поток возвращается в состояние готовности. В это же состояние поток переходит из состояния ожидания, после того как ожидаемое событие произойдет.
Рис. 4.3.Граф состояний потока в многозадачной среде
В состоянии выполнения в однопроцессорной системе может находиться не более одного потока, а в каждом из состояний ожидания и готовности — несколько потоков. Эти потоки образуют очереди соответственно ожидающих и готовых потоков. Очереди потоков организуются путем объединения в списки описателей отдельных потоков. Таким образом, каждый описатель потока, кроме всего прочего, содержит по крайней мере один указатель на другой описатель, соседствующий с ним в очереди. Такая организация очередей позволяет легко их переупорядочивать, включать и исключать потоки, переводить потоки из одного состояния в другое. Если предположить, что на рис. 4.4 показана очередь готовых потоков, то запланированный порядок выполнения выглядит так: А, В, Е, D, С.
Рис. 4.4.Очередь потоков
Алгоритмы планирования, основанные на приоритетах
Другой важной концепцией, лежащей в основе многих вытесняющих алгоритмов планирования, является приоритетное обслуживание. Приоритетное обслуживание предполагает наличие у потоков некоторой изначально известной характеристики — приоритета, на основании которой определяется порядок их выполнения. Приоритет — это число, характеризующее степень привилегированности потока при использовании ресурсов вычислительной машины, в частности процессорного времени: чем выше приоритет, тем выше привилегии, тем меньше времени будет проводить поток в очередях.
Приоритет может выражаться целым или дробным, положительным или отрицательным значением. В некоторых ОС принято, что приоритет потока тем выше, чем больше (в арифметическом смысле) число, обозначающее приоритет. В других системах, наоборот, чем меньше число, тем выше приоритет.
В большинстве операционных систем, поддерживающих потоки, приоритет потока непосредственно связан с приоритетом процесса, в рамках которого выполняется данный поток. Приоритет процесса назначается операционной системой при его создании. Значение приоритета включается в описатель процесса и используется при назначении приоритета потокам этого процесса. При назначении приоритета вновь созданному процессу ОС учитывает, является этот процесс системным или прикладным, каков статус пользователя, запустившего процесс, было ли явное указание пользователя на присвоение процессу определенного уровня приоритета. Поток может быть инициирован не только по команде пользователя, но и в результате выполнения системного вызова другим потоком. В этом случае при назначении приоритета новому потоку ОС должна принимать во внимание значение параметров системного вызова.
Во многих ОС предусматривается возможность изменения приоритетов в течение жизни потока. Изменение приоритета могут происходить по инициативе самого потока, когда он обращается с соответствующим вызовом к операционной системе, или по инициативе пользователя, когда он выполняет соответствующую команду. Кроме того, ОС сама может изменять приоритеты потоков в зависимости от ситуации, складывающейся в системе. В последнем случае приоритеты называются динамическими в отличие от неизменяемых, фиксированных, приоритетов.
От того, какие приоритеты назначены потокам, существенно зависит эффективность работы всей вычислительной системы. В современных ОС во избежание разбалансировки системы, которая может возникнуть при неправильном назначении приоритетов, возможности пользователей влиять на приоритеты процессов и потоков стараются ограничивать. При этом обычные пользователи, как правило, не имеют права повышать приоритеты своим потокам, это разрешено делать (да и то в определенных пределах) только администраторам. В большинстве же случаев ОС присваивает приоритеты потокам по умолчанию.
В качестве примера рассмотрим схему назначения приоритетов потокам, принятую в операционной системе Windows NT (рис. 4.9). В системе определено 32 уровня приоритетов и два класса потоков — потоки реального времени и потоки с переменными приоритетами. Диапазон от 1 до 15 включительно отведен для потоков с переменными приоритетами, а от 16 до 31 — для более критичных ко времени потоков реального времени (приоритет 0 зарезервирован для системных целей).
Рис. 4.9. Схема назначения приоритетов в Windows NT
При создании процесса он в зависимости от класса получает по умолчанию базовый приоритет в верхней5или нижней части диапазона. Базовый приоритет процесса в дальнейшем может быть повышен или понижен операционной системой. Первоначально Поток получает значение базового приоритета из диапазона базового приоритета процесса, в котором он был создан. Пусть, например, значение базового приоритета некоторого процесса равно К. Тогда все потоки данного процесса получат базовые приоритеты из диапазона [К-2, К+2]. Отсюда видно, что, изменяя базовый приоритет процесса, ОС может влиять на базовые приоритеты его потоков.
В Windows NT с течением времени приоритет потока, относящегося к классу потоков с переменными приоритетами, может отклоняться от базового приоритета потока, причем эти изменения могут быть не связаны с изменениями базового приоритета процесса. ОС может повышать приоритет потока (который в этом случае называется динамическим) в тех случаях, когда поток не полностью использовал отведенный ему квант, или понижать приоритет, если квант был использован полностью. ОС наращивает приоритет дифференцирование в зависимости от того, какого типа событие не дало потоку полностью использовать квант. В частности, ОС повышает приоритет в большей степени потокам, которые ожидают ввода с клавиатуры (интерактивным приложениям) и в меньшей степени — потокам, выполняющим дисковые операции. Именно на основе динамических приоритетов осуществляется планирование потоков. Начальной точкой отсчета для динамического приоритета является значение базового приоритета потока. Значение динамического приоритета потока ограничено снизу его базовым приоритетом, верхней же границей является нижняя граница диапазона приоритетов реального времени.
Существуют две разновидности приоритетного планирования: обслуживание с относительными приоритетами и обслуживание с абсолютными приоритетами.
В обоих случаях выбор потока на выполнение из очереди готовых осуществляется одинаково: выбирается поток, имеющий наивысший приоритет. Однако проблема определения момента смены активного потока решается по-разному. В системах с относительными приоритетами активный поток выполняется до тех пор, пока он сам не покинет процессор, перейдя в состояние ожидания (или же произойдет ошибка, или поток завершится). На рис. 4.10, а показан граф состояний потока в системе с относительными приоритетами.
В системах с абсолютными приоритетами выполнение активного потока прерывается кроме указанных выше причин, еще при одном условии: если в очереди готовых потоков появился поток, приоритет которого выше приоритета активного потока. В этом случае прерванный поток переходит в состояние готовности (рис. 4.10, б).
В системах, в которых планирование осуществляется на основе относительных приоритетов, минимизируются затраты на переключения процессора с одной работы на другую. С другой стороны, здесь могут возникать ситуации, когда одна задача занимает процессор долгое время. Ясно, что для систем разделения времени и реального времени такая дисциплина обслуживания не подходит: интерактивное приложение может ждать своей очереди часами, пока вычислительной задаче не потребуется ввод-вывод. А вот в системах пакетной обработки (в том числе известной ОС OS/360) относительные приоритеты используются широко.
Рис. 4.10. Графы состояний потоков в системах с относительными и абсолютными приоритетами
В системах с абсолютными приоритетами время ожидания потока в очередях может быть сведено к минимуму, если ему назначить самый высокий приоритет. Такой поток будет вытеснять из процессора все остальные потоки (кроме потоков, имеющих такой же наивысший приоритет). Это делает планирование на основе абсолютных приоритетов подходящим для систем управления объектами, в которых важна быстрая реакция на событие.
Уровни приоритета
Существует 32 уровня приоритета от 0 до 31. Они разделены на 3 группы.
1 группа(с 16 по 31) – 16 уровней реального времени.
2 группа(с 1 по 15) – 15 динамических уровней.
3 группа(0) – системный уровень(для потока обнулениястраниц).
Управление памятью. Резервирование и передача страниц. Защита памяти.
Управление памятью.
В WindowsNTза управление памятью отвечает диспетчер виртуальной памяти. Содержится вNTOSkernel.exeи включает следующие компоненты
1) Набор сервисов исполнительной системы для выделения, освобождения и управления виртуальной памятью.
2) Обработчики ловушек трансляций недействительных адресов и решение доступа для разрешения аппаратно обнаруживаемых исключений.
Виртуальная память в Windows NT имеет страничную организацию, принятую во многих современных операционных системах. В общем виде схема страничной организации описывается следующим образом: линейный адрес разбивается на несколько частей. Старшая часть адреса содержит в себе номер элемента в корневой таблице. Этот элемент содержит адрес таблицы следующего уровня. Следующая часть линейного адреса содержит номер элемента уже в этой таблице и так далее, до последней таблицы, которая содержит номер физической страницы. А самая младшая часть адреса уже является номером байта в этой физической странице.
Процессоры Intel начиная с Pentium Pro позволяют операционным системам применять одно-, двух- и трехступенчатые схемы. И даже разрешается одновременное использование страниц различного размера. Эта возможность, конечно, повысила бы эффективность страничного преобразования, будь она внедрена в Windows NT. Увы, эта ОС возникла раньше и поддерживает только двухступенчатую схему преобразования с фиксированным размером страниц. Размер страниц для платформы Intel составляет 4 Кбайт, а для DEC Alpha - 8 Кбайт. Схема страничного преобразования (рис. 1) выглядит так:
Каждый раз, когда поток использует адрес, менеджер ВП вместе с аппаратными средствами транслирует виртуальный адрес в физический. Подсистема виртуальной памяти, управляя процессом трансляции виртуальных адресов, гарантирует, что нить одного процесса не сможет получить доступ к физической странице памяти, относящейся к другому процессу.
Каждый процесс NT executive имеет большое виртуальное адресное пространство размером в 4Гб, из которых 2 Гб резервируются для системных нужд. Младшие адреса виртуального адресного пространства доступны для потоков, работающих и в пользовательском, и в привилегированном режимах, они указывают на области памяти, уникальные для каждого процесса. Старшая часть адресов доступна для потоков только тогда, когда они выполняются в привилегированном режиме.
Резервирование и передача страниц.
Три состояния страниц.
Свободное.
Зарезервированное
Переданное
В WindowsNTпредусмотрены 4 основные способа защиты памяти.
Доступ ко всем общесистемным структурам данных и пулам памяти используемых системными компонентами режима ядра возможен лишь в режиме ядра.
У каждого процесса имеется индивидуальное адресное пространство защищённое от доступа потоков других процессов
Все процессоры поддерживаемые в WindowsNTпредоставляют ту или иную форму аппаратной защиты памяти.
Совместное используемый объект имеет стандартный для winntсписки контроля доступа (accesscontrollist) проверяемый при попытках процессов открыть эти страницы
В большинстве современных операционных систем виртуальная память организуется с помощью страничной адресации. Оперативная память делится на страницы: области памяти фиксированной длины (например, 4096 байт), которые являются минимальной единицей выделяемой памяти (то есть даже запрос на 1 байт от приложения приведёт к выделению ему страницы памяти). Процесс обращается к памяти с помощью адреса виртуальной памяти, который содержит в себе номер страницы и смещение внутри страницы. Процессор преобразует номер виртуальной страницы в адрес соответствующей ей физической страницы при помощи буфера ассоциативной трансляции. Если ему не удалось это сделать, то требуется обращение ктаблице страниц(так называемыйPage Walk), что может сделать либо сам процессор, либо операционная система (в зависимости от архитектуры)[10]. Если страница выгружена из оперативной памяти, то операционная система подкачивает страницу с жёсткого диска (см.свопинг). При запросе на выделение памяти операционная система может «сбросить» на жёсткий диск страницы, к которым давно не было обращений. Критические данные (например, код запущенных и работающих программ, код и памятьядрасистемы) обычно находятся в оперативной памяти (исключения существуют, однако они не касаются тех частей, которые отвечают за обработку аппаратных прерываний, работу с таблицей страниц и использование файла подкачки).