Файловая система Windows 2000
Понятие, суть операционной системы Windows 2000. Взаимосвязь между заданиями, процессами и потоками, их особенности и характеристика. Вызовы API для управления заданиями, потоками и волокнами. Межпроцессное взаимодействие и реализация процессов и потоков.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | реферат |
Язык | русский |
Дата добавления | 08.02.2009 |
Размер файла | 1002,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Процессы и потоки в Windows 2000
В операционной системе Windows 2000 есть множество концепций для управления центральным процессором и объединения ресурсов. Мы их обсудим, рассмотрим некоторые соответствующие вызовы Win32 API, а так же покажем, как эти концепции реализованы.
Основные понятия
В операционной системе Windows 2000 поддерживаются традиционные процессы, способные общаться и синхронизироваться друг с другом так же, как это делают процессы в UNIX. Каждый процесс содержит по крайней мере один поток, содержащий, в свою очередь, как минимум одно волокно (облегченный поток). Более того, для управления определенными ресурсами процессы могут объединяться в задания. Все вместе -- задания, процессы, потоки и волокна -- образует общий набор инструментов для управления ресурсами и реализации параллелизма как на однопроцессорных, так и на многопроцессорных машинах. Краткое описание этих четырех понятий.
Рассмотрим по очереди эти понятия, начиная с самого крупного и заканчивая самым маленьким. Задание в Windows 2000 представляет собой набор, состоящий из одного или нескольких процессов, управляемых как единое целое. В частности, с каждым заданием ассоциированы квоты и лимиты ресурсов, хранящиеся в соответствующем объекте задания. Квоты включают такие пункты, как максимальное количество процессов (не позволяющее процессам задания создавать бесконтрольное количество дочерних процессов), суммарное время центрального процессора, доступное для каждого процесса в отдельности и для всех процессов вместе, а также максимальное количество используемой памяти для процесса и для всего задания. Задания также могут ограничивать свои процессы в вопросах безопасности, на пример, запрещать им получать права администратора (суперпользователя) даже при наличии правильного пароля.
Процессы являются более интересными, чем задания, а также более важными. Как и в системе UNIX, процессы представляют собой контейнеры для ресурсов. У каждого процесса есть 4-гигабайтноеадресноепространство, в котором пользователь занимает нижние 2 Гбайт (в версиях Windows 2000 Advanced Server и Datacenter Server этот размер может быть пожеланию увеличен до 3 Гбайт), а операционная система занимает остальную его часть. Таким образом, операционная система присутствует в адресном пространстве каждого процесса, хотя она и защищена от изменений с помощью аппаратного блока управления памятью MMU. У процесса есть идентификатор процесса, один или несколько потоков, список дескрипторов (управляемых в режиме ядра) и маркер доступа, хранящий информацию защиты. Процессы создаются с помощью вызова Win32, который принимает на входе имя исполняемого файла, определяющего начальное содержимое адресного пространства, и создает первый поток.
Каждый процесс начинается с одного потока, но новые потоки могут создаваться динамически. Потоки формируют основу планирования центрального процессора, так как операционная система всегда для запуска выбирает поток, а не процесс. Соответственно, у каждого потока есть состояние (готовый, работающий, блокированный и т. д.), тогда как у процессов состояний пет. Потоки могут динамически создаваться вызовом Win32, которому в адресном пространстве процесса задается адрес начала исполнения. У каждого потока есть идентификатор потока, выбираемый из того же пространства, что и идентификаторы процессов, поэтому один и тот же идентификатор никогда не будет использован одновременно для процесса и для потока. Идентификаторы процессов и потоков кратны четырем, поэтому они могут использоваться в роли байтовых индексов в таблицах ядра, как и другие объекты.
Как правило, поток работает в пользовательском режиме, но когда он обращается к системному вызову, то переключается в режим ядра, после чего продолжает выполнять тот же поток, с теми же свойствами и ограничениями, которые были у него в режиме пользователя. У каждого потока есть два стека, один используется в режиме ядра, а другой в режиме пользователя. Помимо состояния, идентификатора и двух стеков, у каждого потока есть контекст (в котором сохраняются его регистры, когда он не работает), приватная область для локальных переменных, а также может быть свой собственный маркер доступа. Если у потока есть свой маркер доступа, то он перекрывает маркер доступа процесса, чтобы клиентские потоки могли передать свои права доступа серверным потокам, выполняющим работу для них. Когда поток завершает свою работу, он может прекратить свое существование. Когда прекращает существование последний активный поток, процесс завершается.
Важно понимать, что потоки представляют собой концепцию планировании, а не концепцию владения ресурсами. Любой поток может получить доступ ко всем объектам его процесса. Все, что ему для этого нужно сделать, -- это заполучить дескриптор и обратиться к соответствующему вызову Win32. Для потока нет никаких ограничений доступа к объекту, связанных с тем, что этот объект создан или открыт другим потоком. Система даже не следит затем, какой объект каким потоком создан. Как только дескриптор объекта помещен в таблицу дескрипторов процесса, любой поток процесса может его использовать.
Помимо нормальных потоков, работающих в процессах пользователя, в операционной системе Windows 2000 есть множество процессов-демонов, не связанных ни с каким пользовательским процессом (они ассоциированы со специальной системой или простаивающими процессами). Некоторые демоны выполняют административные задачи, как, например, запись «грязных» страниц на диск, тогда как другие формируют пул, и ими могут пользоваться компоненты исполняющей системы или драйверы, которым нужно выполнить какие-либо асинхронные задачи в фоновом режиме. Некоторые из этих потоков будут рассмотрены позднее, когда мы дойдем до темы управления памятью.
Переключение потоков в операционной системе Windows 2000 занимает довольно много времени, так как для этого необходимо переключение в режим ядра, а затем возврат в режим пользователя. Для предоставления сильно облегченного псевдопараллелизма в Windows 2000 используются волокна, подобные потокам, но планируемые в пространстве пользователя создавшей их программой (или ее системой поддержки исполнения). У каждого потока может быть несколько волокон, также как у процесса может быть несколько потоков, с той разницей, что когда волокно логически блокируется, оно помещается в очередь блокированных волокон, после чего для работы выбирается другое волокно в контексте того же потока.
Операционная система не знает о смене волокон, так как все тот же поток продолжает работу. Так как операционная система ничего не знает о волокнах, то с ними, в отличие от заданий, процессов и потоков, не связаны объекты исполняющей системы. Для управления волокнами нет и настоящих системных вызовов. Однако для этого есть вызовы Win32 API. Они относятся к тем вызовам Win32 API, которые не обращаются к системным вызовам, о чем уже рассказывалось при обсуждении рис. 11.6. Взаимосвязь между заданиями, процессами и потоками показана на рис. 11.7. (Несколько волокон могут объединяться в одном потоке, что не показано на рисунке.)
Рис.11.7. Взаимосвязь между заданиями, процессами и потоками.
Хотя мы не будем подробно обсуждать эту тему, следует сказать, что операционная система Windows 2000 может работать на симметричных многопроцессорных системах. Это означает, что код операционной системы должен быть полностью реентерабельным, то есть каждая процедура должна быть написана таким образом, чтобы два или более центральных процессора могли поменять свои переменные без особых проблем. Во многих случаях это в режиме ожидания, пока первый центральный процессор не выполнит свою работу (при помощи последовательного доступа к критическим областям). Количество поддерживаемых системой процессоров управляется лицензионными ограничениями. Эти значения приведены в табл.
11.2. Нет никаких технических причин, по которым система Windows Professional не может работать на мультипроцессоре с 32 узлами -- в конце концов, у нее тот же самый двоичный код, что и у версии Datacenter Server.
Верхний предел в 32 центральных процессора является жестким пределом, так как во многих местах операционной системы для учета использования центральных процессоров используются битовые массивы размером в 32-разрядное машинное слово. Например, один однословный битовый массив используется для того, чтобы следить, какой из центральных процессоров свободен в данный момент, а другой массив используется в каждом процессе для перечисления центральных процессоров, на которых этому процессу разрешено работать. 64-разрядная версия Windows 2000 должна будет без особых усилий поддерживать до 64 центральных процессоров. Для превышения этого ограничения потребуется существенная переделка программы (с использованием по несколько слов для битовых массивов).
Вызовы API для управления заданиями, процессами, потоками и волокнами
Новые процессы создаются при помощи функции Win32 API CreateProcess. У этой функции 10 параметров, каждый из которых может задаваться в различных вариантах. Такая схема, очевидно, значительно сложнее схемы, применяемой в UNIX, в которой системный вызов fork вообще не имеет параметров, а у системного вызова exec их всего три: указатели на имя исполняемого файла, массив параметров командной (проанализированной) строки и строки окружения. Если не вдаваться в подробности, то у вызова CreateProcess следующие 10 параметров:
1. Указатель на имя исполняемого файла.
2. Сама командная строка (непроанализированная).
3. Указатель на описатель защиты процесса.
4. Указатель на описатель защиты для начального потока.
5. Бит, управляющий наследованием дескрипторов.
6. Разнообразные флаги(например, режим ошибки, приоритет, отладка, консоли).
7. Указатель на строки окружения.
8. Указатель на имя текущего рабочего каталога нового процесса.
9. Указатель на структуру, описывающую начальное окно на экране.
10. Указатель на структуру, возвращающую вызывающему процессу 18 значений.
В операционной системе Windows 2000 не поддерживается какой-либо иерархии процессов, например «родительский-дочерний». Все созданные процессы равны (не существует процессов, более равных, чем другие). Однако, поскольку один из 18 параметров, возвращаемых вызывающему процессу, представляет собой дескриптор нового процесса (что предоставляет контроль над новым процессом), существует негласная иерархия, заключающаяся в том, кто чьим дескриптором владеет. Хотя эти дескрипторы не могут напрямую передаваться другим процессам, у процесса есть способ создать дубликат дескриптора. Дубликат дескриптора может быть передан другому процессу и использоваться им, поэтому не явная иерархия процессов может просуществовать недолго.
Каждый процесс в Windows 2000 создается с одним потоком, но процесс может позднее создать дополнительные потоки. Создание потока проще создания процесса -- у вызова CreateThread всего шесть параметров вместо десяти:
1. Описатель защиты(необязательный).
2. Начальный размер стека.
3. Адрес запуска.
4. Параметр, задаваемый пользователем.
5. Начальное состояние потока (готовый или блокированный).
6. Идентификатор потока.
Созданием потоков занимается ядро, поэтому оно имеет полное представление о потоках (потоки не реализуются полностью в пространстве пользователя, как это делается в некоторых других системах).
Межпроцессное взаимодействие
Для общения друг с другом потоки могут использовать широкий спектр возможностей, включая каналы, именованные каналы, почтовые ящики, вызов удаленной процедуры и совместно используемые файлы. Каналы могут работать в одном из двух режимов, выбираемом при создании канала: байтовом и режиме сообщений. Байтовые каналы работают так же, как и в системе UNIX. Каналы сообщений в чем-то похожи на байтовые каналы, но сохраняют границы между сообщениями, так что четыре записи по 128 байт будут читаться с другой стороны канала как четыре сообщения по 128 байт, а не как одно 512-байтовое сообщение, как это может случиться с байтовыми каналами. Также имеются именованные каналы, для которых существуют те же два режима. Именованные каналы, в отличие от обычных каналов, могут использоваться по сети.
Почтовые ящики представляют собой особенность системы Windows 2000, которой нет в UNIX. В некоторых аспектах они подобны каналам, но не во всем. Во-первых, почтовые ящики являются однонаправленными, тогда как каналы могут работать в обоих направлениях. Они также могут использоваться по сети, но не предоставляют гарантированной доставки. Наконец, онипозволяютотправляющемупроцессуиспользоватьшироковещаниедлярассылки сообщения не одному, а сразу многим получателям.
Сокеты подобны каналам с тем отличием, что они при нормальном использовании соединяют процессы на разных машинах. Например, один процесс пишет в сокет, а другой процесс на удаленной машине читает из него. Сокеты также могут использоваться для соединения процессов на одной машине, но поскольку их использование влечет за собой большие накладные расходы, чем использование каналов, то, как правило, они применяются в контексте сети.
Вызов удаленной процедуры представляет собой тот способ, которым процесс А просит процесс В вызвать процедуру в адресном пространстве процесса В от имени процесса А и вернуть результат процессу А. Существуют различные ограничения на параметры. Например, нетсмыслапередаватьуказательдругомупроцессу.
Наконец, процессы могут совместно использовать память для одновременного отображения одного и того же файла. Все, что один процесс будет писать в этот файл, будет появляться в адресном пространстве других процессов. С помощью такого механизма можно легко реализовать общий буфер, применяемый в задаче производителя и потребителя.
Помимо многочисленных механизмов межпроцессного взаимодействия, операционная система Windows 2000 также предоставляет множество механизмов синхронизации, включая семафоры, мьютексы, критические регионы и события. Все эти механизмы работают с потоками, а не процессами, так что когда поток блокируется на семафоре, другие потоки этого процесса(если такие есть) не затрагиваются и могут продолжать работу.
Семафор создается при помощи API-функции CreateSemaphore, которая может задать для него начальное значение, а также установить максимальное значение. Семафоры представляют собой объекты в ядре и, таким образом, обладают дескрипторами или дескрипторами защиты. Копия дескриптора может быть получена с помощью функции DuplicateHandle и передана другому процессу, в результате чего несколько процессов могут синхронизироваться, используя один семафор. Существуют вызовы для выполнения на семафоре операций up и down, они имеют несколько странные имена: ReleaseSemaphore (up) и WaitForSingleObject (down). Функции WaitForSingleObject также можно задать интервал времени, поистечениикоторогождущийизменениясостояниясемафорапотокбудетотпущен, дажееслисемафоростанетсяравным0 (хотя использование таймеров приводит к конфликтам).
Мьютексы также представляют собой объекты ядра, используемые для синхронизации, но они проще семафоров, так как не содержат счетчиков. По существу, они являются блокировками, для работы с которыми используются функции API WaitForSingleObject и ReleaseMutex. Как и дескрипторы семафоров, дескрипторы мьютексов можно скопировать и передать другому процессу, так что потоки различных процессов смогут иметь доступ к одному и тому же мьютексу.
Третий механизм синхронизации основан на критических секциях (которые назывались иногда критическими областями). Критические секции подобны мьютексам, но отличаются тем, что они связаны с адресным пространствомс оздавшего их потока. Поскольку критические секции не являются объектами ядра, у них нет дескрипторов или дескрипторов защиты и они не могут передаваться от одного процесса другому. Блокирование и разблокирование выполняется функциями EnterCriticalSection и LeaveCriticalSection соответственно. Поскольку эти функции API в основном выполняются в пространстве пользователя и обращаются к системным вызовам в ядро, только когда требуется блокирование потока, они работают быстрее, чем мьютексы.
В последнем механизме синхронизации используются объекты ядра, называемые событиями, которые бывают двух видов: сбрасываемые вручную и сбрасываемые автоматически. Каждое событие может находиться водном из двух состояний: установленном и сброшенном. Поток может ждать какого-либо события с помощью функции WaitForSingleObject. Если другой поток вызывает событие при помощи функции SetEvent, результат зависит от типа события. Если событие является сбрасываемым вручную, то все ждущие его потоки отпускаются, а событие остается в установленном состоянии, пока его кто- либо не сбросит при помощи функции ResetEvent. В случае сбрасываемого автоматически события отпускается только один ожидающий его поток, а событие тут же сбрасывается. Кроме функции SetEvent существует также функция PulseEvent, отличающаяся от первой функции тем, что если этого события никто не ждет, событие все равно само сбрасывается и, таким образом, пропадает в пустую. При использовании функции SetEvent событие, которого никто не ждет, напротив, остается в установленном состоянии, так что как только какой-либо поток обратится к функции WaitForSingleObject, он будет тут же отпущен, после чего событие сбросится.
События, мьютексы и семафоры могут иметь имена и храниться в файловой системе, подобно именованным каналам. Несколько процессов могут синхронизироваться друг с другом, открывая одно и тоже событие, мьютекс или семафор, что проще, чем создание такого объекта одним процессом и передача другим процессам дубликата дескриптора, хотя такой способ, конечно, также возможен.
Интерфейс. Win32 API содержит около 100 вызовов, работающих с процессами, потоками и волокнами. Значительное количество этих вызовов в той или иной мере имеет отношение к межпроцессному взаимодействию. Некоторые из обсуждавшихся выше функций, а также некоторые другие важные функции.
Большинство вызовов из табл. 11.10 либо обсуждались выше, либо должны говорить сами за себя. Снова обращаю ваше внимание, что не все они являются системными вызовами. Как уже упоминалось, операционная система Windows 2000 ничего не знает о волокнах. Они полностью реализованы в пространстве пользователя. Поэтому функция CreateFiber выполняет свою работу целиком в пространстве пользователя, не обращаясь к системным вызовам (разве что только с просьбой выделить ей память). Многие другие вызовы Win32 также обладают подобным свойством, включая уже упомянутые функции EnterCriticalSection и LeaveCriticalSection.
Реализация процессовипотоков
Процессы и потоки имеют большее значение и являются более сложными, чем задания и волокна, поэтому мы сконцентрируем наше внимание на них. Процесс создается другим процессом при помощи вызова интерфейса Win32 CreateProcess. Этот вызов обращается (в режиме пользователя) к процедуре в динамической библиотеке kemel32.dll, которая в несколько этапов создает процесс, используя при этом множество системных вызовов и других действий.
1 Указанный в качестве параметра исполняемый файл изучается и открывается. Если это корректный исполняемый файл формата POSIX, OS/2,16-разрядной системы Windows или MS-DOS, то для него устанавливается специальное окружение. Если это корректный .ехе файл 32-разрядного интерфейса Win32, в реестре проверяется, не является ли этот файл особенным в каком-либо смысле (например, должен выполняться под контролем отладчика). Все эти действия выполняются в режиме пользователя внутри kemel32.dll.
2 Выполняется обращение к системному вызову NtCreateProcess, чтобы создать пустой объект процесса и поместить его в пространство менеджера объектов. Создаются объект ядра и объект исполняющей системы. Кроме того, менеджер процессов создает для объекта управляющий блок процесса и инициализирует его идентификатором процесса, квотами, маркером доступа и различными другими полями. Также создается объект секции, чтобы следить за адресным пространством процесса.
3 Когда динамическая библиотека kernel32.dll снова получает управление, она обращается к еще одному системному вызову, NtCreateThread, чтобы создать начальный поток. Для потока создаются стек режима пользователя и стек режима ядра. Размер стека указан в заголовке исполняемого файла.
4 Затем библиотека kernel32.dll посылает подсистеме окружения Win32 сообщение, в котором содержится информация о новом процессе, и передает ей дескрипторы процесса и потока. Данные о процессе и потоке помещаются в таблицы подсистемы, в результате чего у нее оказывается полный список всех процессов и потоков. Затем подсистема отображает курсор в виде стрелки с песочными часами, чтобы сообщить пользователю, что что-то происходит, но курсор может использоваться. Когда процесс обращается к своему первому вызову графического интерфейса пользователя, как правило, чтобы создать окно, курсор удаляется (если обращения к вызову не поступает, курсор удаляется через 2 с).
5 В этот момент поток готов к работе. Он начинается с запуска процедуры системы поддержки исполнения программ для завершения инициализации.
6 Процедура системы поддержки исполнения программ устанавливает приоритет потока, сообщает загруженным библиотекам DLL о появлении нового потока, а также выполняет другую рутинную работу. Наконец, она запускает код основной программы потока.
Создание потока также состоит из нескольких этапов, но мы не будем вдаваться в эти подробности. Сначала работающий процесс обращается к функции CreateThread, которая вызывает процедуру внутри kernel32.dll. Эта процедура выделяет в вызывающем процессе память для стека режима пользователя, а затем обращается к системному вызову NtCreateThread, чтобы создать объект потока для исполняющей системы, проинициализировать его, а также создать и проинициализировать блок управления потоком. И в этом случае уведомляется подсистема Win32, а информация о потоке помещается в ее таблицы. Затем поток начинает работу с собственной инициализации.
Когда создается процесс или поток, исходному процессу возвращается дескриптор, который можно использовать для запуска, остановки, уничтожения и проверки созданного процесса или потока. Владелец дескриптора может передать его другому процессу защищенным способом. Эта техника применяется, чтобы отладчики могли иметь полный контроль над управляемыми ими процессами.
Планирование
В операционной системе Windows 2000 нет центрального потока планирования. Вместо этого, когда какой-либо поток не может более выполняться, этот поток сам переходит в режим ядра и запускает планировщика, чтобы определить, на какой поток переключиться. Текущий поток выполняет программу планировщика при одном из следующих условий:
1) поток блокируется на семафоре, мьютексе, событии, операции ввода-вывода и т. д;
2) поток сигнализирует каким-либо объектом (например, выполняет операцию up на семафоре);
3) истекает квант времени работающего потока.
В случае 1 поток уже работает в режиме ядра, чтобы выполнить операцию с объектом диспетчера или ввода-вывода. Возможно, он не может продолжать работу, поэтому он должен сохранить свой контекст, запустить программу планировщика, чтобы выбрать своего преемника, и загрузить контекст этого потока, чтобы запустить его.
В случае 2 поток так же находится в ядре. Однако после сигнализирования объектом он, определенно, может продолжать работу, так как эта операция никогда не приводит к блокированию. Тем не менее поток должен запустить процедуру планировщика, чтобы посмотреть, нет ли среди готовых к работе потока с более высоким приоритетом. Если такой поток есть, происходит переключение на этот поток, так как операционная система Windows 2000 является системой с приоритетным прерыванием (то есть переключение потока может произойти в любой момент, а не только тогда, когда у текущего потока закончится выделенный ему квант времени).
В случае 3 происходит эмулированное прерывание с передачей управления в ядро. При этом поток также запускает процедуру планировщика, чтобы определить, какой поток следует запустить после текущего потока. Если все остальные потоки в данный момент окажутся заблокированными, планировщик может продолжить выполнение текущего потока, выделив ему новый квант времени. В противном случае происходит переключение потока.
Планировщик так же вызывается при еще двух условиях:
1. Завершается операция ввода-вывода.
2. Истекает ожидание таймера.
В первом случае какой-нибудь поток, возможно, ожидал окончания этой операции ввода-вывода и теперь может продолжить свою работу. Необходимо определить, должен ли этот поток прервать выполнение текущего потока, так как потокам не гарантируется минимальныйрабочийинтервалвремени. Планировщикнезапускаетсявовремяработысамой процедуры обработки прерываний (так как при этом прерывания могут оказаться запрещенными на слишком долгий срок). Вместо этого отложенный вызов процедуры DPC устанавливается в очередь и выполняется немного позднее, после того как процедура обработки прерываний закончит свою работу. Во втором случае поток выполнил операцию down на семафоре или блокировался на каком-либо другом объекте, но установленное время ожиданияистекло. Ивэтомслучаеобработчикпрерыванийдолженустановить DPC вочередь, чтобы она не была запущена во время работы обработчика прерываний. Если в результате тайм-аута поток оказался готовым к работе, будет запущен планировщик, и если ничего более важноговданныймоментнет, будетвыполненотложенныйвызовпроцедуры.
Теперь мы подходим к самому алгоритму планирования. Интерфейс Win32 API содержит два вызова, предоставляющих процессам возможность влиять на планирование потоками. Алгоритм планирования в большой степени определяется этими вызовами. Во-первых, есть вызов SetPriorityClass, устанавливающий класс приоритета всех потоков вызывающего процесса. К допустимым значениям приоритета относятся: реального времени, высокий, вышенормы, нормальный, ниженормыинеработающий.
Во-вторых, имеется вызов SetThreadPriority, устанавливающий относительный приоритет некоторого потока (возможно, но не обязательно, потока, обращающегося к этому вызову) по сравнению с другими потоками данного процесса. Приоритет может иметь следующиезначения: критичныйковремени, самыйвысокий, вышенормы, нормальный, ниже нормы, самый низкий и неработающий, Таким образом, шесть классов процессов и семь классов потоков могут образовать 42 комбинации. Эта информация поступает на вход алгоритмапланирования.
Планировщик работает следующим образом. В системе существует 32 уровня приоритета, пронумерованныеот 0 до 31. 42 комбинацииотображаютсянаэти 32 приоритетав соответствии с табл. 11.11. Число в таблице определяет базовый приоритет потока. Кроме того, у каждого потока есть текущий приоритет, который может быть выше (но не ниже) базовогоприоритетаиокотороммыскажемнесколькослов.
Чтобы использовать эти приоритеты для планирования, система содержит массив из 32 элементов, соответствующих приоритетам от 0 до 31, полученных из табл. 11.11. Каждый элемент массива указывает на начало списка готовых потоков с соответствующим приоритетом. Следует отметить, что при планировании не учитывается, какому процессу принадлежит тот или иной поток. То есть планировщик не выбирает сначала процесс, а затем поток в этом процессе. Он смотрит только на потоки. Он даже не знает, какой поток какому процессу принадлежит. На многопроцессорной системе каждый центральный процессор сам занимается планированием своих потоков при помощи массива приоритетов. Чтобы гарантировать, что в каждый момент времени лишь один центральный процессор работает с массивом, используетсяспин-блокировка.
Массив заголовков очередей показан на рис.11.8. существует четыре категории приоритетов: реального времени, пользовательские, нулевой и бездействующий, равный -1. Об этом следует сказать несколько слов. Приоритеты с 16 по 31 называются приоритетами реального времени, но они таковыми не являются. Выполняющимся с этими приоритетами потокам не дается никаких гарантий и никакие сроки исполнения не учитываются. Это просто более высокие приоритеты, чем приоритеты с 0 по 15. Однако приоритеты с 16 по 31 зарезервированы для самой системы и для потоков, которым такой высокий приоритет явно задаст системный администратор. Обычные пользователи не могут запускать потоки со столь высокими приоритетами, и существует веская причина для этого. Если бы пользовательский процесс мог работать с приоритетом более высоким, чем, скажем, поток клавиатуры или мыши, то длительная работа такого высокоприоритетного потока без операцийввода-вывода(например, вцикле) повесилабывсюсистему.
Рис. 11.8. Windows 2000 поддерживает32 приоритетадляпотоков
Пользовательские потоки работают с приоритетами от 1 до 15. Устанавливая приоритеты процесса и потока, пользователь может отдавать преимущество тому или иному потоку. Нулевой поток работает в фоновом режиме и съедает все процессорное время, на которое больше никто не претендует. Его работа заключается в обнулении страниц для менеджера памяти.
Со временем для улучшения производительности системы в базовом алгоритме планирования было сделано несколько усовершенствований. При определенных условиях текущий приоритет пользовательского потока может быть поднят операционной системой вышебазовогоприоритета, ноникогданеможетбытьустановленвышеприоритета 15. Таккак массив на рис. 11.8 основан на текущем приоритете, изменение этого приоритета изменяет поведение алгоритма планирования. Для потоков с приоритетами 15 и выше никогда не делаетсяникакихизмененийприоритета.
Эти увеличения приоритета не вечны. Они незамедлительно вступают в силу, но если поток использует весь свой следующий квант времени, он теряет один пункт и перемещается на одну очередь вниз в массиве приоритетов. Если он использует еще один полный квант, он перемещается еще на один уровень ниже и т. д., пока он не достигнет своего базового уровня, где останется до тех пор, пока ему снова не будет прибавлен приоритет. Очевидно, если поток претендуетнахорошееобслуживание, ондолжендействоватьоченьактивно.
Естьещеодинслучай, прикоторомсистемаизменяетприоритетыпотоков. Представьте, что два потока работают вместе в задаче типа «производитель-потребитель». Работа производителя труднее, поэтому он получает более высокий приоритет, например 12, а потребительполучаетприоритет4. Вопределенныймоментпроизводительзаполняетдоотказа общийбуфериблокируетсянасемафоре, какпоказанонарис.11.9,а.
Рис. 11.9. Примеринверсииприоритета
Прежде чем потребитель снова получит шанс поработать, посторонний процесс с приоритетом 8 приходит в состояние готовности и получает управление, (рис. 11.9, б). Этот поток сможет работать столько, сколько захочет, так как его приоритет выше приоритета потребителя, а производитель, хоть и с большим приоритетом, заблокирован. При таких условиях производитель никогда снова неполучитуправления, пока потоксприоритетом 8 не остановится.
В операционной системе Windows 2000 эта проблема решается при помощи большой кувалды. Система следит, сколько времени прошло с тех пор, когда готовый к работе поток запускалсявпоследнийраз. Есликакой-либопотокпревыситопределенныйинтервалвремени, он получает на два кванта времени приоритет 15. Это может помочь разблокировать производителя. После двух квантов прибавка приоритета резко убирается. Вероятно, лучшим решением было бы наказывать потоки, которые полностью используют свои кванты снова и снова. Вконцеконцов, проблемусоздаетнепоток, умирающийотголода, ажадныйпоток. Эта проблемахорошоизвестнаподназваниеминверсииприоритетов.
Аналогичная проблема возникает в том случае, когда поток с приоритетом 16 захватывает мьютекс и долго не получает управления, в результате чего более важные системные потоки, ждущие этого мьютекса, умирают от истощения. Эту проблему можно устранить, если разрешить потоку, которому на короткое время требуется мьютекс, просто запрещать планирование на время использования мьютекса. На многопроцессорных системах следуетприменятьспин-блокировку.
Напоследок следует сказать пару слов о кванте. В системе Windows 2000 Professional длительность кванта по умолчанию равна 20 мс; на однопроцессорных серверах его значение равно 120 мс; на многопроцессорных системах используются различные другие варианты в зависимости от частоты процессора. Более короткий квант улучшает работу интерактивных процессов, тогда как более длинный квант снижает количество переключений контекста и тем самым увеличивает производительность. Именно в этом смысл правой колонки табл. 11.2. Значения поумолчаниюприжеланиимогутбытьувеличеныв 2, 4 или 6 раз. Кстати, величина кванта была выбрана более десяти лет назад и не менялась с тех пор, хотя компьютеры за это время стали быстрее более чем на порядок. Вероятно, эти числа можно было бы без ущерба уменьшить в 5 или 10 раз и, возможно, получить при этом лучшее время отклика для интерактивныхпотоковвсильнозагруженнойсистеме.
Последняя модификация алгоритма планирования заключается в том, что когда окно становится окном переднего плана, все его потоки получают более длительные кванты времени. Величинаприбавкиинтервалавременихранитсявсистемномреестре. Такимобразом, поток получает больше процессорного времени, и, соответственно, достигается лучшее обслуживаниедляокна, перемещенногонапереднийплан.
Эмуляция MS-DOS
Одна из задач проектирования системы Windows 2000 была унаследована от NT: постаратьсяподдержатьповозможностибольшое (вразумныхпределах) количествопрограмм для MS-DOS. Эта цель принципиально отличалась от задачи, поставленной перед создателями системы Windows 98: внейдолжныбылиработатьвсестарыепрограммыдля MS-DOS (отсебя добавим: неважно, насколькоплохоониработали).
Операционная система Windows 2000 запускает старые программы в полностью защищенном окружении. Когда запускается программа, написанная для системы MS-DOS, запускается нормальный процесс Win32, в который загружается эмулятор MS-DOS ntvdm (NT Virtual DOS Machine -- виртуальнаямашина DOS для NT), сканирующийпрограмму MS-DOS и выполняющий ее системные вызовы. В системе MS-DOS всего лишь 1 Мбайт оперативной памятинапроцессоре Intel 8088 идо 16 Мбайтспереключениембанковидругимитрюкамина процессоре Intel 80286. Поэтому можно без особого риска поместить процесс ntvdm встаршие адреса виртуального адресного пространства, где программа не сможет к нему адресоваться. Этаситуацияпоказананарис. 11.10.
Рис. 11.10. ЗапускстарыхпрограммдляMS-DOS всистемеWindows 2000
Когда программа MS-DOS выполняет обычные команды процессора, она может работать на голой аппаратуре, так как процессор Pentium полностью поддерживает наборы команд процессоров Intel 8088 и Intel 80286. Самое интересное начинается, когда программа MS-DOS собирается выполнить операцию ввода-вывода или обратиться к операционной системе. Корректно написанная программа просто выполняет системный вызов. Рассчитывая на корректное поведение, эмулятор ntvdm инструктирует систему Windows 2000 перенаправлять все системные вызовы ему. В результате системный вызов просто «отскакивает» от операционной системы и перехватывается эмулятором (шаги 1 и 2 на рис. 11.10). Такойметодиногданазываютиспользованиемтрамплина(батута).
Неприятность в том, что некоторые старые программы, написанные для работы в системе MS-DOS, обходят операционную систему и напрямую обращаются к видеопамяти, напрямую читают порты клавиатуры и т. д., то есть выполняют действия, недопустимые в защищенной среде. Если такое некорректное поведение программы приводит к прерываниям, есть надежда, что эмулятор сумеет определить, чего хочет программа, и сможет эмулировать это действие.
Загрузка Windows 2000
Прежде чем операционная система Windows 2000 сможет начать работу, она должна загрузиться. Процесс загрузки создает начальные процессы. Мы кратко обсудим процесс загрузки операционной системы Windows 2000. С точки зрения аппаратного обеспечения, процесс загрузки состоит из чтения первого сектора первого диска (главной загрузочной записи), послечегопрочитаннойпрограммепередаетсяуправление. Этакороткаяпрограммана ассемблере считывает таблицу разделов, чтобы определить, в каком разделе содержится загружаемая операционная система. Найдя раздел с операционной системой, начальный загрузчик считывает первый сектор этого раздела, называемый загрузочным сектором, и передает управление ему. Программа, содержащаяся в загрузочном секторе, считывает корневой каталог своего дискового раздела, находит в нем файл ntldr (еще одно археологическоесвидетельствотого, что Windows 2000 насамомделепредставляетсобой NT). Если этот файл удается найти, он загружается в память и ему передается управление. Программа ntldr загружает операционную систему Windows 2000. Существует несколько версий загрузочного сектора в зависимости от формата раздела (FAT-16, FAT-32 или NTFS). При установке Windows 2000 на диск записываются соответствующие версии главной загрузочнойзаписиизагрузочногосектора.
Затем программа ntldr считывает файл Boot.ini, представляющий собой единственный файл с информацией о конфигурации, не содержащейся в реестре. Он хранит в себе списки всех версий файлов hal.dll и ntoskernl.exe, которые могут быть загружены с данного раздела диска. В этом файле также содержатся такие параметры, как количество центральных процессоров и оперативной памяти, сколько памяти отводить процессу пользователя (2 или 3 Гбайт), а также на какой частоте работают часы реального времени. Затем программа ntldr выбирает и загружает файлы hal.dll и ntoskernl.exe, а также файл bootvid.dll, представляющий собой видеодрайвер по умолчанию. Он обеспечивает вывод на дисплей во время процесса загрузки. После этого программа ntldr считывает реестр, чтобы найти драйверы, необходимые для завершения загрузки (например, драйверы клавиатуры и мыши, а также десятки других драйверов, требуемых для управления различными микросхемами на материнской плате). Наконец, загрузчиксчитываетвсеэтидрайверыипередаетуправлениепрограммеntoskernl.exe.
После запуска операционная система выполняет некоторые общие процедуры инициализации, а затем вызывает компоненты исполняющей системы, чтобы те также выполнили собственную инициализацию. Например, менеджер объектов подготавливает свое пространство имен, чтобы другие компоненты могли обращаться к нему и добавлять свои объекты в пространство имен. Многие компоненты также выполняют определенные действия, относящиеся кихфункциям, так, менеджер памятинастраивает начальные таблицы страниц, а менеджер plug-and-play определяет, какие устройства ввода-вывода присутствуют, и загружает их драйверы. Вся загрузка состоит из десятков этапов, в течение которых на экране отображается полоса прогресса, растущая по мере выполнения очередных этапов. Последний этап заключается в создании первого настоящего пользовательского процесса, сеансового менеджера smss.exe. Как только этот процесс начинает работу, загрузка считается законченной.
Сеансовый менеджер представляет собой «родной» процесс операционной системы Windows 2000. Он обращается к истинным системным вызовам и не пользуется вызовами подсистемы окружения Win32, которая в тот момент еще даже не работает. Одной из его первоочередныхобязанностейявляетсязапускэтойподсистемы (csrss.exe). Онтакжесчитывает с диска ульи реестра и узнает из них, что еще он должен сделать. Как правило, его работа заключается в помещении множества объектов в пространство имен менеджера объектов, создании дополнительных файлов подкачки и открытии нужных DLL. Завершив свою работу, сеансовыйменеджерсоздаетдемонрегистрацииwinlogon.exe.
В этот момент операционная система загружена и работает. Теперь пора запустить служебные процессы (демоны в пространстве пользователя) и позволить пользователям регистрироваться в системе. Сначала winlogon.exe создает менеджера аутентификации (lsass.exe), а затем запускает родительский процесс всех служебных процессов (services.exe). Последний процесс по информации, хранящейся в реестре, определяет, какие демоны в пространстве пользователя нужно запустить и в каких файлах они находятся. После этого он приступает к их созданию. Такие демоны показаны на рис. 11.2. Как правило, уже после того, как первый пользователь зарегистрировался всистеме, но еще до того, как он успел вней что-либо сделать, в операционной системе Windows 2000 наблюдается высокая активность с большим количеством обращений к диску. Это программа services.exe создает системные службы. Кроме того, она загружает все оставшиеся, еще не загруженные, драйверы устройств.
Программа winlogon.exe также отвечает за регистрацию всех пользователей в системе. Диалоговое окноотображается отдельной программой msgina.dll, чтобы другиепроизводители программного обеспечения могли заменить стандартную процедуру регистрации с вводом имени и пароля идентификацией отпечатков пальцев или еще чем-нибудь. После успешного входа пользователя в систему программа winlogon.exe получает из реестра профиль пользователя и определяет по нему, какую оболочку запустить. Многие пользователи этого не осознают, но стандартный рабочий стол Windows представляет собой просто программу explorer.exe (Проводник), у которой настроены некоторые параметры. При желании пользователь может выбрать в качестве оболочки другую программу, включая командную строку или даже редактор Word, для чего ему нужно просто отредактировать реестр. Однако редактирование реестра -- занятие не для слабых духом. Одна ошибка может сделать систему незагружаемой.
Подобные документы
Семейство ОС Windows 2000. Windows 2000 Server. Windows 2000 Advanced Server. Windows 2000 Datacenter Server. ОС Windows Server 2003. Организация сети на основе Windows 2000. Службы каталогов, DHCP, DNS, WINS. Конфигурирование сервера.
курсовая работа [307,1 K], добавлен 06.10.2006Windows как посредник пользователя и операционной системы, облегчая процесс общения между ними, история становления и развития ее первых версий. Функциональные особенности и отличия Windows 95/98/ME и Windows NT/2000/XP/Vista/7, их архитектурные решения.
презентация [12,7 K], добавлен 23.10.2013Хранение файлов, доступ к ним, установка и изменение атрибутов. Операционные системы DOS, Windows 95/98/Me, Windows NT/2000/XP. Файловая система FAT 16. Уменьшение потерь дискового пространства. Количество секторов в кластере. Главная загрузочная запись.
реферат [72,9 K], добавлен 19.01.2012Прикладные программы и утилиты. Простейшие функции операционной системы. История разработки корпорацией Microsoft Corporation графической операционной оболочки Windows. Версия семейства сетевых ОС Windows NT (Millennium Edition, 2000, XP, Vista, Seven)
презентация [965,2 K], добавлен 12.10.2013Операционная система в роли связующего звена между аппаратурой компьютера и выполняемыми программами. Управление процессами операционной системы. Операционная система Windows. Различные виды Windows для определенных задач пользователей, их отличия.
реферат [28,5 K], добавлен 23.01.2012Программирование в операционной системе Windows. Работа с потоками и процессами ОС. Методы их создания. Основы вызова API-функций. Пример создания диалогового окна без использования файла ресурсов. Разработка программы с помощью 32-битного ассемблера.
курсовая работа [107,6 K], добавлен 18.05.2014Появление операционной системы Windows 95. Правила присвоения имен файлам. Порядок хранения файлов на диске. Система хранения файлов и организации каталогов. Многоуровневая иерархическая файловая система. Полное имя файла. Иерархия папок Windows.
презентация [103,0 K], добавлен 11.03.2015Характеристика операционной системы. История развития Windows. Сравнительная характеристика версий Windows. Элементы и инструменты Windows XP. Прикладные программы в Windows XP. Работа настольных и портативных компьютеров под управлением Windows.
доклад [19,1 K], добавлен 16.10.2011Написание автоматизированной информационной системы "Контроль и реализация товара для автосалона" в операционной системе Windows 2000 или Windows XP. Проектирование подсистемы на базе программы "1С:Предприятие", программная реализация ряда функций.
дипломная работа [3,1 M], добавлен 29.04.2011Администрирование дисков в WINDOWS 2000. Новые концепции в Windows 2000. Использование возможностей Disk Management. Двойная загрузка. Приложения в системе с двойной загрузкой. Усложненная процедура установки.
реферат [15,7 K], добавлен 14.06.2007