38. Конструктивные изменения.

MS DOS/Windows — это маленькая, простая ОС. Она предназначалась для рабо­ты на персональных компьютерах с небольшим объемом памяти и, конечно, не имевших быстрых современных процессоров Intel и RISC. На маленьких компь­ютерах, где имеет значение каждый байт и каждый цикл процессора, было бы непрактично делать Windows полностью надежной средой, так как обеспечение этого требует определенной платы — размером и скоростью выполнения кода.

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

Чтобы защитить ОС от приложений, диспетчер окон Win32 должен рабо­тать несколько иначе, нежели старый диспетчер окон. Группа разработчиков диспетчера окон должна была сделать 32-разрядную версию более устойчивой и надежной сре­дой, чем 16-разрядный диспетчер окон. Основные изменения были следующими:

Рис. 5-14. Модель ввода 16-разрядной Windows.

• десинхронизация модели ввода Windows;

• схема вытесняющего планирования потоков;

• добавление проверки описателей объектов и блокировок объектов.

Первое изменение связано с тем, как подсистема Win32 обрабатывает пользовательский ввод (с нажатиями клавиш и кнопок мыши). Модель ввода 16-разрядного диспетчера окон была синхронной, т. е. весь пользовательский ввод помещался в одну очередь ("первым пришел, первым обслужен") и посылался приложениям тогда, когда они его запрашивали. После ввода пользователь дол­жен был ждать, пока приложение его обработает, прежде чем мог быть обрабо­тан последующий ввод. Так как в данный момент времени выборку ввода могло осуществлять только одно приложение, каждое из них должно было своевре­менно выбирать ввод из очереди, чтобы все приложения выполнялись без по­мех. Синхронная модель ввода показана на рис. 5-14.

Иногда при использовании этой модели возникали проблемы. Какое-ни­будь приложение могло "зависнуть" и перестать выбирать ввод или не имело возможности выбирать его быстро из-за сильной занятости. В таких случаях работа других приложений останавливалась, так

Рис. 5-15. Модель ввода Win32.

как они не получают данных , необходимых для продолжения. С точки зрения пользователя это выглядело как "зависание" ОС'.

Потребовалась значительная переделка модели ввода 16-разрядного дис­петчера окон, но в результате устойчивость подсистемы Win32 сильно повыси­лась. В новой модели ввода каждое приложение имеет отдельную очередь ввода, как показано на рис. 5-15.

При получении пользовательского ввода подсистема Win32 немедленно определяет, для какого приложения он предназначен (проверяя, какое окно явля­ется в данный момент активным, и где расположен указатель мыши), 32-разряд­ный диспетчер окон помещает ввод в соответствующую очередь ввода, и прило­жение выбирает его по мере своей готовности. Если по некоторой причине при­ложение прекратило выборку ввода, то на других программах это не отражается.

Вторым существенным изменением в подсистеме Win32, по сравнению с 16-разрядной Windows, является полная поддержка вытесняющей многозадач­ности. В устойчивой ОС неприемлема ситуация, когда одно приложение пере­стает работать, и у ОС нет способа вмешаться или завершить исполнение при­ложения. 16-разрядная Windows рассчитывает на то, что приложения время от времени сами освобождают процессор, позволяя выполняться другим програм­мам, но это не всегда имеет место в действительности. В Windows NT подсисте­ма Win32 (опираясь на существенную поддержку ядра NT) вынуждает приложе­ния освобождать процессор. Каждый поток приложения может выполняться только на протяжении выделенного ему кванта времени. После этого ядро NT прерывает выполнение потока и проверяет, есть ли необходимость исполнения потока с более высоким приоритетом.

Используя вытеснение, подсистема Win32 не только вынуждает приложе­ния освобождать процессор, но может и принудительно завершить приложение Win32. Например, если приложение зависло из-за ошибки в нем или если пользователь просто не хочет больше ждать, он может воспользоваться кнопкой End Task (Завершить задачу) в Windows Task Manager. Работая в 16-разрядной Windows, ошибочное приложение может не допустить своего завершения или, в особо тяжелых случаях, даже не дать Task Manager отобразить свое окно на эк­ране. В Windows NT, однако, подсистема Win32 обращается для принудительно­го завершения приложения к исполнительной системе NT, и это обращение всегда успешно. Поскольку поток приложения построен на основе объекта-потока NT, диспетчер процессов посылает сообщения в порт завершения пото­ка. Подсистема среды, отвечающая за данное приложение, получает это сообще­ние и освобождает любую поддерживаемую ею глобальную информацию отно­сительно завершенного приложения.

Кроме десинхронизации модели ввода и реализации вытеснения, подсис­тема Win32 выполняет проверку описателей объектов. В 16-разрядной Windows описатели объектов иногда вызывали проблему, так как ОС предполагала, что приложения всегда передают ей правильные описатели — т. е. такие, которые на самом деле являются ссылками на те объекты, на которые должны указывать. Если же вместо описателя окна приложение передавало нечто постороннее, системное программное обеспечение могло сбоить.

В противоположность этому, подсистема Win32 проверяет содержимое описателей, передаваемых приложениями. Как и описатель объекта NT, описа­тель объекта Win32 — это индекс в таблице. Описатель и соответствующий ему элемент таблицы содержат определенную информацию об объекте, на который ссылается описатель. Подсистема Win32 в состоянии проверить, что описатель указывает на объект именно того типа, который требуется. Она даже может оп­ределить, что описатель указывает на нужный экземпляр данного типа. В добав­ление к проверке описателей, Win32 реализует разновидность удержания объек­тов, аналогичную той, что используется исполнительной системой NT. В 16-раз­рядной Windows приложение могло уничтожить объект, который все еще ис­пользуется ОС, что вело к системным ошибкам. Подсистема же Win32 поддерживает для необходимых ей объектов счетчик ссылок. Приложение по-прежнему может "удалить" объект, но система не уберет его из памяти до тех пор, пока он продолжает использоваться.

Компонент GDI Win32 не является просто модернизацией 16-разрядной версии — он полностью переписан. Первой задачей для компонента GDI подсистемы Win32 была замена ассемблерного кода переносимым кодом на С, а также реорганизация внутренней работы для поддержки некоторых продвинутых возможностей. В состав новых средств GDI входят кривые Безье, дающие пользователям графических пакетов более тонкие средства рисования дуг; траектории (paths), позволяющие создавать объекты про­извольной формы при помощи последовательности команд рисования; транс­формация объектов, дающая возможность приложениям выполнять отображе­ние из одного координатного пространства в другое; и наконец, корреляция объектов, средство, при помощи которого приложение может легко определить, перекрывается ли данный объект или область с другими. Другим конструктивным изменением в GDI Win32 является новый интер­фейс драйвера устройства. Этот интерфейс превосходит по своим возможностям обоих предшественников, давая более тонкие способы контроля драйверам графических уст­ройств Win32 (которые отвечают за создание изображений в аппаратно-зависимом формате и посылку их на устройства вывода). В частности, GDI настраивает данные, которые он посылает драйверу устройства, в зависимости от набора по­нятных драйверу операций. Например, если данный драйвер "понимает" кривые Безье, то GDI передает их ему целиком. В противном случае GDI разбивает кривую на простые линейные сегменты, прежде чем послать ее драйверу. Кроме того, в GDI включены новые мощные функции создания битовых изображений, которые программисты могут, в частности, использовать при создании драйверов диспле­ев и принтеров вместо того, чтобы писать свои собственные функции. Благодаря этой поддержке значительно сокращается время написания и отладки драйверов устройств. Разработчики могут возложить на GDI большую часть работы, добавляя в драйвер устройства только аппаратно-зависимые расширения и оптимизации.

Несмотря на все упомянутые выше улучшения, возможно, самым большим изменением как в диспетчере окон, так и в GDI, была реализация Win32 в виде защищенной подсистемы, т. е. в виде серверного процесса. Разработчики каждой из подсистем среды Windows NT разделили процедуры своих API на две группы — те, которые используют только локальные данные, и те, которые используют глобальные данные. Первая группа в целях повышения производительности может быть реализована в DLL клиентской стороны. Вторая же должна быть реализована в адресном пространстве подси­стемы, чтобы глобальные данные оставались защищенными, но по-прежнему доступными всем клиентам подсистемы. Это изменение повлияло на выбор спо­соба написания приложения Win32, особенно в случае вызова функций GDI.

Хотя GDI рассматривает почти все данные как локальные в клиентском процессе, при прорисовке объектов все процессы совместно используют одно устройство вывода — экран. Таким образом, экран фактически относится к "гло­бальным данным", и функции GDI, изменяющие его состояние, должны быть реализованы в сервере Win32, а не в DLL клиентской стороны. Чтобы обеспе­чить для этих функций максимальную скорость работы, GDI применяет не­сколько оптимизаций. Например, чтобы изменить цвета на экране, приложение может вызвать функцию GDI для установки цвета переднего плана, затем снова вызвать GDI для установки цвета фона, после чего выполнить еще несколько операций, прежде чем рисовать что-либо на экране. Вместо того, чтобы вызы­вать подсистему при каждом вызове функции GDI, DLL сохраняет измененную информацию в собственном буфере. Когда приложение рисует что-нибудь на экране, DLL посылает подсистеме все измененные данные одним сообщением. В представленном здесь примере подсистема обновила бы цвета экрана в DLL, подождав с посылкой информации об изменениях серверу до тех пор, пока не будет выдан первый запрос на рисование. Кэширование атрибутов (attribute cashing), как называется этот метод буферизации, минимизирует количество переключении контекста и объем времени, затраченный на передачу сообще­ний между клиентом и сервером.

Для уменьшения числа переключений контекста между клиентом и серве­ром GDI использует аналогичный способ оптимизации, пакетирование (batching). Пакетирование — это метод, при использовании которого, например, DLL GDI сохраняет несколько вызовов функций в очереди и посылает их на сервер од­ним сообщением, когда очередь переполняется или когда пользователь выпол­няет ввод. При получении такого сообщения сервер Win32 последовательно выполняет все функции, прежде чем управление возвращается клиенту. Прежде чем использовать эту технику, разработчики GDI провели тесты и проверили, не будет ли вывод на экран прерывистым или неравномерным. Тесты показали, что вызовы функций посылаются серверу достаточно часто, и вывод на экран про­ходит плавно и ровно.

Авторам прикладных программ следует иметь в виду эти методы оптими­зации производительности при создании новых многопоточных приложений. Если два потока работают вместе, то их исполнение должно быть синхронизи­ровано, чтобы гарантировать выполнение действий в надлежащем порядке. На­пример, нужно учитывать, что результат не появится на экране сразу же после вызова потоком функции API. Вызов функции может сохранен в буфере потока, ожидая своего вывода на экран. GDI предоставляет функцию GdiFlush(), при помощи которой поток может осуществить принудительную посылку кэшированных вызовов функций на сервер Win32.

Другим результатом использования модели клиент-сервер является то, что приложения, которые постоянно изменяют и перерисовывают большие бито­вые поля, могут работать медленно, в сравнении с прорисовкой аппаратно-независимых образов с использованием вызовов GDI. Так как каждый объект или битовый образ являются локальными для клиентского приложения, они должны пересылаться в составе сообщения на сервер при всякой перерисовке экрана. Для обеспечения оптимальной производительности приложениям следует либо перерисовывать, по возможности, только измененные фрагменты битового об­раза, либо рисовать при помощи функций GDI, что позволяет реализовывать преимущества методов кэширования и пакетирования. Новый Win32 GDI API предоставляет более полный, чем GDI API 16-разрядной Windows, набор средств рисования, необходимый сложным приложениям.