Глава 7. Операционныесистемы «тонких» клиентов
7.1 Карманныеперсональные компьютеры
Под «тонкими»клиентами понимают вычислительные устройства, обладающие неполнойфункциональностью. Вообще говоря, спектр таких устройств достаточно велик — отспециализированных вычислителей, встраиваемых в бытовую аппаратуру, до«сетевых» компьютеров, обладающих практическими всеми аппаратнымивозможностями ПК, кроме жесткого диска. Мы в этой главе рассматриваем восновном класс тонких клиентов, называемых карманными персональнымикомпьютерами или PDA — Personal Digital Assistant (персональный цифровойпомощник). Такие устройства используются в качестве интеллектуальныхорганайзеров или/и в качестве мобильных устройств доступа к сервераминформационных систем. По оценкам некоторых экспертов число мобильных клиентовво всем мире к 2003 г. достигнет 80 млн. Производство карманных ПК являетсяперспективным направлением, и на этом направлении действует большое число фирм.Многие из них разрабатывают собственные ОС для своих PDA, однако многиеиспользуют и ОС от других производителей. Практически каждая фирма — производителькарманных ПК придает своей модели некоторые уникальные свойства, дающие ейкакие-то конкурентные преимущества. Однако все многообразие карманных ПК,по-видимому, можно свести к двум типам: ПК без клавиатуры, ввод данных вкоторых — рукописный или с виртуальной клавиатуры, в обоих случаях — при помощисветового пера, и ПК с клавиатурой. Второй тип приближается к настольным ПК, вчастности, в его функциональность включается и обработка мультимедийнойинформации. Первый тип беднее (точнее говоря, специфичнее) по функциональности,однако отличается меньшими размерами и энергопотреблением. Задача ОС для ПКпервого типа — обеспечить максимальную экономию ресурсов, задача ОС для ПКвторого типа — обеспечить максимальную функциональность. Среди универсальных ОСдля карманных ПК первого типа лидирует PalmOS, для второго типа — Windows CE.
7.2 Операционная системаPalmOS
Операционная системаPalmOS [31] предназначена для управления PDA на базе микропроцессора MotorollaDragon Ball VZ, за которыми закрепилось название PalmPilot (хотя правильноеназвание их — просто Palm). Однако архитектура устройства Palm — открытая, имногие фирмы выпускают собственные PDA, подобные Palm, но с теми или инымиотличиями — Sony, HandEra, Kyocera, Symbol и другие. Все эти PDA работают подуправлением PalmOS.
Спецификафункционирования приложений в PalmOS, а, следовательно, и самой PalmOSзаключается в следующем:
малый размер экрана(160х160 точек) не позволяет приложению иметь сложный интерфейс; припроектировании интерфейса следует соблюдать баланс между информационнойдостаточностью и перегруженностью экрана;
приложение должно иметьпростую и быструю навигацию, выбор требуемого действия должен производитьсяодной-двумя операциями пользователя, а не длинным диалогом, как бывает внастольных ПК;
ОС и приложенияфункционируют в условиях очень ограниченного объема ресурсов, прежде всего — памяти;
одним из важнейшихтребований является эффективное управление питанием.
ОС должна быть рассчитанана быстрый рост вычислительных возможностей — как собственных базовыхвозможностей PDA, так и расширения номенклатуры, возможностей и форматовподключаемых к PDA карт.
Обязательным компонентомплатформы Palm является синхронизационная приставка (cradle), котораяобеспечивает соединение с настольным ПК и синхронизацию данных, находящихся наПК и на PDA. Многие приложения для PalmOS имеют аналоги для настольного ПК. Длясинхронизации данных, разделяемых ПК и PDA, используется технология HotSync,которая предусматривает создание специальных каналов (conduit) длясинхронизации данных. Существуют специальные инструментальные средства дляпрограммирования таких каналов, и многие популярные программные продукты(Netscape Communicator, Oracle, IBM DB2, etc.) имеют в своем составе такиеканалы.
Архитектура PalmOSпоказана на рисунке 7.1.
/>
PalmOS базируется намикроядре. Вокруг микроядра построены системные службы — менеджеры PalmOS,представляющие собой наборы модулей, обеспечивающих определенные функции. Ктаким менеджерам относятся, например:
Менеджер Graffiti — система рукописного ввода;
Менеджер Событий;
Менеджер Памяти;
Менеджер Данных;
Менеджер Ресурсов;
Менеджер Звука;
и т.д.
Библиотеки (системные илиот других производителей) обеспечивают высокоуровневый доступ к системнымфункциям. Хотя для PalmOS и существуют стандартные библиотеки языка C, всистемных библиотеках имеются собственные функциональные аналоги стандартныхфункций C, которые оптимизированы для PalmOS, поэтому их использованиепредпочтительнее.
Микроядро и управлениезадачами
Само микроядро неявляется собственностью фирмы Palm, используется микроядро AMX RTOS [13],разработанное фирмой Kadak. Микроядро AMX RTOS представляет собой микроядрореального времени, адаптированное для нескольких аппаратных платформ иприспособленное для размещения в ПЗУ. Микроядро обеспечивает вытесняющуюмногозадачность с абсолютными приоритетами. В каждый момент времени выполняетсятолько задача с наивысшим приоритетом. Переключение задач может происходить
по инициативе самойзадачи — задача переходит в состояние ожидания или запраштвает выполнениеоперации, вызывающей выполнение задачи с более высоким приоритетом;
по внешнему событию — прерыванию, обработка которого может запустить или «разбудить» задачис более высоким приоритетом;
по событию таймера,которое также может «разбудить» задачи с более высоким приоритетом.
Микроядро AMX RTOSоптимизировано с целью минимизации времени переключения задач и минимизациинереентерабельных участков кода. Как правило, прерывания могут обрабатыватьсядаже во время переключения задач. Служба обработки прерывания микроядраобеспечивает прием прерывания и вызов пользовательской процедуры обработкипрерывания. AMX RTOS обеспечивает также вложенную обработку прерываний для техаппаратных платформ, на которых вложенные прерывания поддерживаютсяпроцессором.
Микроядро обеспечиваеттакже богатые средства синхронизации процессов:
события — события могутобразовывать группы до 16 событий, и ожидаться может любая заданнаяконфигурация совершенности событий в группе;
семафоры — традиционныеобщие семафоры, используемые как счетчики ресурсов;
очереди сообщений — «почтовые ящики» (одна очередь) и «коммуникационные каналы»(4 очереди с разными приоритетами).
Также микроядрообеспечивает ряд сервисных функций, таких как выделение/освобождение памяти,работу с пулом буферов и работу со связными списками.
Микроядро написано наязыке C и, следовательно, может быть реализовано для любой аппаратной платформы.Средства конфигурирования позволяют включать в микроядро только те функции,которые необходимы заказчику.
Микроядро само по себеобеспечивает вытесняющую многозадачность. Но по условиям лицензионногосоглашения на использование микроядра API микроядра является закрытым, иразработчики не могут создавать программы, напрямую использующие функциимикроядра, в том числе и многозадачность. Поэтому приложения PalmOS — однозадачные. В PalmOS в каждый момент времени может выполняться только одноприложение, имеющее доступ к пользовательскому интерфейсу, это приложение — главное, приоритетное. Параллельно с ним может быть запущено фоновое (неимеющее доступа к интерфейсу) приложение, которое получает процессорное времятолько, когда главное приложение бездействует. Поскольку главное приложениеработает во взаимодействии с пользователем, фоновое приложение занимает почтивсе процессорное время, но оно немедленно прерывается, при появлении событий,требующих активизации главного приложения.
Обработка событий
Интерфейсные приложенияPalmOS управляются событиями. Такое приложение представляет собой единственныйцикл, каждая итерация которого начинается с получения очередного события.Системный вызов EvtGetEvent обеспечивает ожидание и прием события. Полученноесобытие передается ряду обработчиков в такой последовательности:
обработчик системныхсобытий;
обработчик событий меню;
обработчик событийприложения;
обработчикдиспетчеризации экранных форм;
обработчик экранных форм.
Если вызванный обработчикраспознает событие как подлежащее его обработке, он эту обработку выполняет. Впроцессе этой обработки он может генерировать и направлять в очередь другиесобытия. Если обработчик выполнил полную обработку события, то он возвращаетtrue, и тогда приложение прерывает цепочку вызовов обработчиков. Алгоритмфункционирования приложения, таким образом, выглядит примерно так, как показанона рисунке 7.2.
/>
Рисунок 7.2 Обработкасобытий в приложении PalmOS
Управлениеэнергопотреблением
PDA Palm являютсярекордсменами среди устройств такого типа по низкому энергопотреблению, чтообеспечивается. аппаратными средствами совместно с ОС. Это достигается наличиемв PDA нескольких режимов энергопотребления и их управлением со стороны ОС.Режимы эти следующие:
Рабочий режим. В рабочемрежиме процессор выполняет инструкции. Процессор и вся аппаратура ввода-выводапотребляют энергию в полном объеме. Типичное приложение, переводящее систему врабочий режим, использует около 5% процессорного времени.
Ждущий режим. PDAвыглядит включенным, процессорные часы активны, но инструкции не выполняютcя.Процессор работает на пониженном энергопотреблении. Когда процессор получаетпрерывание, он переходит из ждущего режима в рабочий. Также переключениепроисходит, когда пользователь начинает вводить информацию световым пером.PalmOS программно переводит устройство в ждущий режим в системном вызовеEvtGetEvent, если очередь событий пуста. Поступление нового события начнется спрерывания, которое вернет PDA в рабочий режим.
Спящий режим. PDAвыглядит выключенным: дисплей пуст, процессор неактивен, а главные часыостановлены. Активны только часы реального времени и генератор прерываний.PalmOS включает этот режим, когда нет активных действий пользователя в течениенекоторого интервала времени или когда пользователь нажимает кнопку выключения.Вход из спящего режима происходит по прерыванию, например, если пользовательнажал на любую кнопку или сработали часы реального времени по заданнойпрограмме. Когда система получает одно из этих прерываний в спящем режиме, онапереходит в рабочий режим.
Управление памятью иданными
Память является одним изнаиболее критических ресурсов PDA, и в то же время — наиболее быстронаращиваемым. За время существования PDA Palm и PalmOS доступные объемы памятив устройстве возросли от 512 Кбайт до 8 Мбайт. Память в устройстве Palm естьоперативная (RAM) и постоянная (ROM). Вся память расположена на карте памяти,на карте может размещаться как ROM, так и RAM-память или обе вместе. Содержимоеобоих видов памяти сохраняется даже при «выключении» PDA (переводеего в спящий режим). Архитектура памяти Palm 32-битная. Каждой карте памятиотводится адресное пространство 256 Мбайт. ROM и RAM-память карты разбита на«кучи», размер каждой кучи — не менее 64 Кбайт. Деление памяти накучи — условное, оно производится ОС и никак не отражается на аппаратнойархитектуре памяти. В каждой куче содержится либо ROM, либо RAM-память, но необе вместе. В RAM-памяти на внутренней карте памяти PDA реализована«динамическая куча». Фактически, это и есть оперативная память. Вэтой куче ОС размещает динамические данные: глобальные переменные, динамическиесистемные области памяти, стек, кучу приложения и сами коды приложений,загружаемых из дополнительных карт. Размер динамической кучи зависит от объемапамяти на внутренней карте PDA и от предустановленного программногообеспечения. Каждая куча имеет свой номер-идентификатор. Динамическая кучаимеет номер 0. Эта куча инициализируется автоматически всякий раз при рестартесистемы. Все другие кучи инициализируются собственными циклами переустановки.
Память распределяетсяпорциями (chunk) переменной длины. Порция располагается в одной куче,выравнивается по границе 2-байтного слова и занимает непрерывную область памяти- от 1 байта до 64 Кбайт. Порции в RAM-памяти бывают динамическими илихранимыми, перемещаемыми или неперемещаемыми. Порции в ROM-памяти бывают тольконеперемещаемыми и хранимыми.
Управление памятью(прежде всего — динамической, перемещаемой памятью) ведется Менеджером ПамятиОС. Управление хранимой памятью ведется надстройкой над Менеджером Памяти,называемой Менеджером Данных.
Когда Менеджер Памятивыделяет неперемещаемую порцию, он возвращает указатель на нее. Этот указательсохраняет свое начальное значение все время существования порции. КогдаМенеджер Памяти выделяет перемещаемую порцию, он возвращает ее манипулятор(handle). Манипулятор является номером элемента в Главной таблице указателей.Главная таблица указателей содержит указатели на порции. Поскольку обращения кперемещаемым порциям происходит через манипуляторы, ОС имеет возможностьпереместить порцию в памяти и изменить указатель на нее в Главной таблице,манипулятор же порции, которым оперирует приложение, не изменяется.Перемещение, однако, возможно только в те моменты, когда это«позволяет» приложение. Поскольку в системе не предусматриваетсяаппаратное преобразование виртуальных адресов в реальные, для того, чтобыработать с данными памяти, приложение должно иметь указатель на данные.Системный вызов MemHandeLock фиксирует порцию в памяти, то есть запрещает ееперемещение. Этот вызов возвращает указатель на начало порции, через которыйприложение осуществляет доступ к данным порции. После окончания работы с даннымиприложение должно снять фиксацию с порции. ОС применяет перемещение порций дляборьбы с фрагментацией памяти (внешними дырами). Процедура сжатия памятивызывается всякий раз при нехватке памяти. Естественно, что чем больше порцийбудет зафиксировано в памяти, тем менее эффективна будет такая процедура.Поэтому эффективность управления памятью в значительной степени зависит от«грамотного» поведения приложения. В целях снижения фрагментации ОСвыделяет память для перемещаемых порций в начале кучи, а для неперемещаемых — вконце кучи.
Каждая порция памятиимеет свой локальный (в пределах данной карты памяти) идентификатор. Длянеперемещаемой порции этот идентификатор — ее смещение относительно началакарты, для перемещаемой — смещение относительно начала карты соответствующегоей элемента Главной таблицы указателей. Таким образом, обработка данных независит от того, в какой слот будет вставляться карта. Специальный системныйвызов превращает номер слота и локальный идентификатор порции в указатель или манипулятор.
Каждая куча начинается сзаголовка кучи, который содержит размер кучи и информацию о ее состоянии.Главная таблица указателей располагается сразу вслед за заголовком. Еслиразмера таблицы недостаточно, выделяется память для ее расширения. Последнееполе таблицы содержит указатель на расширение. Таким образом может бытьвыделено сколько угодно расширений, и они связываются в однонаправленныйлинейный список. Расширения Главной таблицы указателей размещаются в концекучи. Память, выделяемая для перемещаемых порций, находится сразу за Главнойтаблицей.
Заголовок кучи неподлежит изменению, поэтому куча может располагаться в ROM-памяти. Посколькупорции в ROM-памяти не могут быть перемещаемыми, Главная таблица кучи вROM-памяти содержит 0 элементов.
Каждой порции памятипредшествует 8-байтный заголовок, в котором содержится признаксвободной/занятой порции, размер порции, счетчик фиксаций и обратная ссылка наГлавную таблицу указателей. Свободные участки памяти также имеют формат порций,таким образом, ОС может отследить все распределение памяти, начиная от первойпорции и прибавляя к ее адресу размер. Каждая порция может быть зафиксирована впамяти до 16 раз, каждая новая фиксация просто прибавляет единицу к счетчикуфиксаций, а снятие фиксации — вычитает единицу. Порция становится перемещаемойтолько, когда ее счетчик фиксаций обнулится. Для порций хранимой памяти счетчикфиксаций сразу устанавливается в максимальное значение и не уменьшается припопытках снять фиксацию.
Хранимые области памяти вPalm играют ту же роль, что файлы на внешней памяти в других вычислительныхсистемах. Однако в отличие от «традиционных» вычислительных систем, вкоторых данные для обработки перемещаются в буфер в оперативной памяти, вPalmOS хранимые данные обрабатываются на месте, прямо в постоянной памяти.Работа с хранимыми данными обеспечивается Менеджером Данных, представляющимсобой надстройку над Менеджером Памяти.
Данные хранятся в памятив виде записей. Каждая запись представляет собой порцию памяти. Для выделения,освобождения, изменения размера записи Менеджер Данных обращается к МенеджеруПамяти. Логически связанные записи объединяются в базу данных, база данныхявляется аналогом файла как именованная совокупность данных. Записи базы данныхне обязательно располагаются в смежных порциях памяти, они могут быть дажерассредоточены по разным кучам в пределах одной карты памяти.
Каждая база данных имеетзаголовок, в котором записано имя базы данных, количество записей в ней идругая управляющая информация. В заголовке же находится и план размещения базыданных, представляющий собой массив дескрипторов записей, входящих в базу. Есливесь массив не помещается в заголовке, то последний его элемент содержитуказатель (локальный идентификатор) продолжения списка. Каждый дескрипторзаписи представляет собой 4-байтную структуру, в первом байте которой находятсяатрибуты записи (признаки: защиты, удаления, изменения, занятости), а воставшихся трех — локальный идентификатор — адрес записи.
API Менеджера Данныхпредставляет собой как бы «гибрид» традиционного файлового API и APIпамяти. Для того, чтобы работать с базой данных, приложение должно сначала ее«найти» — по символьному имени базы данных определить ееидентификатор (локальный идентификатор заголовка базы данных). Этообеспечивается специальным системным вызовом DmFindDatabase(). Затем базаданных открывается, при этом в динамической куче создается для нее структураданных — аналог дескриптора открытого файла. С открытой базой данных приложениеможет работать. Основной системный вызов доступа к данным — DmGetRecord() — возвращает указатель на данные записи с заданным номером, выборка и изменениеданных записи производится через этот указатель.
Особый вид базы данныхназывается ресурсом. Ресурсы служат для хранения специальных данных — программных кодов, изображений, интерфейсных элементов и т.д. Структура ресурсаотличается от структуры обычной базы данных только тем, что дескриптор записиресурса имеет размер 10 байтов, два дополнительных байта описывают свойства ресурса.Еще одна надстройка над Менеджером данных — Менеджер Ресурсов — обеспечиваетработу с этой дополнительной информацией. API Менеджера Ресурсов функциональноаналогичен API Менеджера Данных.
Кроме того, PalmOSобеспечивает интерфейс файлового потока. При использовании этого API хранимыеданные представляются в виде потока байтов, не разделенного на записи.Ограничение 64 Кбайт на размер порции отсутствует. Системные вызовы этогоинтерфейса (FileOpen(), FileClose(), FileRead(), FileWrite(), etc.) аналогичныфункциям стандартной библиотеки языка C. Файловый поток является толькоинтерфейсной надстройкой, с одними и теми же данными можно работать и как сфайловым потоком, и как с базой данных.
Расширения и файловаясистема
Начиная с версии 4.0,PalmOS содержит единообразную поддержку новых карт, которые могут расширятьвозможности PDA. В предыдущих версиях карты, вставляемые в слоты расширения,должны были обязательно соответствовать спецификациям памяти Palm ирассматривались OS как дополнительная память. В слоты расширения могутвставляться:
карты RAM-памяти (необязательно соответствующие спецификациям Palm), содержащие приложения и данныек ним или используемые для специальных целей (например, для создания архивныхкопий);
карты ROM-памяти (необязательно соответствующие спецификациям Palm), содержащие приложения и данныек ним;
карты ввода-вывода дляспециальных устройств (например, модема);
комбинированные карты,содержащие как возможности ввода вывода, так и RAM и ROM-память.
Новая версия ОС рассматриваетвсе эти карты расширения как вторичную память и обеспечивает единообразнуюработу с ними. Основными компонентами архитектуры расширения PalmOS являются:
драйверы слота;
файловые системы;
Менеджер Виртуальнойфайловой системы (VFS);
Менеджер Расширения.
Драйвер слота аналогичентрадиционному драйверу устройства, он инкапсулирует детали управленияоборудованием карты расширения данного типа и предоставляет МенеджеруРасширения единый интерфейс для управления картами разных типов. Добавление поддержкинового аппаратного расширения требует включения в системную библиотеку новогодрайвера слота.
Файловые системыаналогичны драйверам файловых систем в ОС с инсталлируемыми файловымисистемами, они обеспечивают работу с конкретными файловыми системами ПК илидругих устройств. Обычно в PalmOS предустанавливается файловая система FAT,другие файловые системы могут быть добавлены при необходимости.
Менеджер VFS обеспечиваетединый интерфейс системных вызовов (VFSFileOpen(), VFSFileClose(),VFSFileRead(), VFSFileWrite(), etc.) для всех файловых систем. Он обеспечиваеттакже возможность работы с памятью на картах расширения с использованием API,подобного тому, который применяется для работы с базами данных в основнойпамяти.
Наконец, МенеджерРасширения обеспечивает отслеживание вставки/удаления карт расширения иуправление драйверами слота.
Взаимодействие спользователем
Три менеджера в составеPalmOS поддерживают взаимодействие с пользователем «по инициативесистемы»:
Менеджер Внимания(attention);
Менеджер Тревоги (alarm);
Менеджер Извещения(notification).
Менеджер Вниманияотвечает за взаимодействие с пользователем в тех случаях, когда требуетсяпривлечь его внимание. Этот менеджер обеспечивает выдачу сигнала пользователю(звуком, вибрацией, другими специальными эффектами), индикацию события,требующего внимания, на экране (в виде всплывающего окна или маленькогоиндикатора события), управление со стороны пользователя списком таких событий.
Менеджер Тревоги посылаетсобытие приложению при достижении определенного момента времени. Приложениезатем может обратиться к Менеджеру Внимания, чтобы привлечь вниманиепользователя.
Менеджер Извещенияинформирует приложения о наступлении некоторого события. Извещение получают теприложения, которые зарегистрировали свой интерес к данному событию. Приложениезатем может обратиться к Менеджеру Внимания.
Пользовательскийинтерфейс PalmOS позволяет увеличить производительность, благодаря уменьшениюнавигации между окнами, открытию новых диалогов. Размещение структур управленияприложением (меню, кнопки и т. д.) упрощено настолько, что пользователь можетбыстро и эффективно управлять ими. Всего интерфейс обеспечивает 10 основныхуправляющих структур: формы, диалоги, кнопки, триггеры, переключатели,ползунки, поля, меню, списки, линейки прокрутки. Система также дает возможностьразработчикам создавать свои собственные компактные пользовательские интерфейсыразмером 160x160 пикселов (размер экрана Palm).
Упрощение навигациидостигается также за счет упрощения структуры каталогов VFS PalmOS.Пользователь в большинстве случаев просто не видит этой структуры, он видит наэкране иконки доступных для запуска приложений. Эти приложения размещаются вкаталоге \PALM\Launcher. Обеспечена автоматическая установка приложения в этомкаталоге при добавлении новой карты. Имеется также возможность автоматическогозапуска приложения при вставке его карты в слот.
Хотя «девизом»PDA Palm и PalmOS является экономия ресурсов, существуют и PDA других фирм,также работающие под управлением PalmOS, которые предоставляют своим владельцамгораздо более широкие возможности, прежде всего — в части обработкимультимедийной информации (лидером в этом отношении, по-видимому, являетсяфирма Cassio). «Карманная» работа с мультимедийной информацией являетсяобъективной тенденцией, и игнорировать ее фирма Palm не сможет. Возможно, вскором времени и облик PalmOS претерпит значительные изменения.
7.3. Операционная системаWindows CE
Управление процессами ипамятью
ОС Windows CE [39]рассчитана на значительно большие объемы ресурсов, чем PalmOS, но,соответственно, обеспечивает гораздо больший объем возможностей. Windows CEявляется членом семейства ОС Windows и в большей части функций обеспечиваетобщий cтандартный API Win32 этого семейства и общий с остальными членамисемейства интерфейс пользователя, но в некоторых случаях принятые в Windows CEрешения являются специфичными.
Windows CE являетсямногозадачной системой с вытесняющей многозадачностью. Определенные свойстваWindows CE дают основание говорить о ней как о системе реального времени. Всистеме обеспечиваются абсолютные приоритеты, выполняется только процесс (нить)с наивысшим приоритетом. Если два или более процессов имеют высший приоритет,то квант времени (по умолчанию размер кванта — 100 мсек) делится между нимипоровну. Всего имеется 256 градаций приоритета, но только 8 самых низших из нихвозможны для пользовательских процессов, остальные зарезервированы засистемными процессами. Windows CE поддерживает вложенные прерывания и «инверсию»приоритетов — повышение приоритета нити, если она захватывает критическийресурс. Windows CE является 32-разрядной системой и обеспечивает в основном тотже API Win32, что и другие ОС Windows. Ядро Windows CE может адресовать до 256Мбайт физической памяти, но в виртуальном адресном пространстве объем которого- 4 Гбайт, физическая память отображается в младшие 2 Гбайт, как показано нарисунке 7.3.
/>
Рисунок 7.3 Виртуальноеадресное пространство Windows CE
В старшей части памятиадресное пространство от 2 до 3 Гбайт отводится для совместно используемойпамяти (в терминологии Windows — файлов, отображаемых в память), а пространствоот 3 до 4 Гбайт делится на «слоты» с номерами от 1 до 32, каждый изкоторых представляет адресное пространство одного из процессов. Таким образом,в системе может выполняться одновременно до 32 процессов, частное адресноепространство каждого процесса — 32 Мбайт (не считая файлов, отображаемых впамять). «Слот» 0 отображается на физическую память, он отдаетсяактивному в текущий момент процессу. В адресном пространстве каждого процесса,помимо кодов процесса, создаются области памяти для статических данных, куча истек для каждой нити процесса. Для статических данных выделяются отдельныеобласти памяти — для изменяемых и для неизменяемых данных. Для каждого процессасоздается куча по умолчанию (384 страницы по 1 Кбайт), но процесс можетсоздавать новые кучи в пределах своего адресного пространства. Выделенные в кучеблоки памяти не перемещаются, что может приводить к фрагментации памяти в куче.Размер стека для нити — 1 Мбайт, и он не может быть изменен. Количество нитей впроцессе ограничено только возможностью выделения памяти для стеков нитей.Память для стека выделяется по мере необходимости, постранично. Если длярастущего стека нити не хватает страниц памяти, нить блокируется.
Программы, выполняемые вWindows CE, могут находиться в RAM- или в ROM-памяти. Если программа находитсяв ROM-памяти, но не содержит изменяемых данных, она выполняется «наместе». Если же программа содержит изменяемые данные, она для выполнениякопируется в RAM-память. Копирование происходит постранично, по требованию.
Общие области памяти,называемые в Windows файлами, отображаемыми в память, в адресное пространствопроцесса не входят. Они могут использоваться для получения процессомдополнительной памяти сверх лимита 32 Мбайт.
Управление внешнимиданными
Управление внешнимиданными в Windows CE основывается на концепции «хранилища объектов»(object store). Хранилище объектов играет ту же роль, что и дисковая память внастольных вычислительных системах: оно обеспечивает постоянную память дляхранения приложений и их сохраняемых данных. Хранилища объектов могут быть трехтипов: файловые системы, базы данных и реестры (registry), причем все они могутразделять одну и ту же физическую память. Однако, первые два типа могут такжеразмещаться и в ROM-памяти, на внешних устройствах или в отдельных системах,реестры же — только в RAM-памяти. Объектами, находящимися в хранилище, могутбыть:
ключ реестра;
значение реестра;
файл (метаинформацияфайла);
порция (chunk) данныхфайла (размер порции — 4 Кбайт);
запись базы данных (до 4Кбайт);
расширение записи базыданных (до 4 Кбайт);
база данных(метаинформация базы данных).
Каждый объект имеетуникальный (в пределах тома) идентификатор, который используется для доступа кобъектам.
Windows CE работает стремя типами файловых систем: файловая система в ROM-памяти, файловая система вRAM-памяти и файловая система FAT на внешних устройствах, картах расширенияпамяти и PC Card. Разработчики могут создавать и регистрировать и другиефайловые системы. Независимо от того, на каком физическом типе памятирасполагается файловая система, работа с нею выполняется через стандартныйфайловый API Win32. Для упрощения операций с памятью Windows CE не применяетконцепцию текущего каталога, но все ссылки на объекты содержат полный маршрут.
База данных в Windows CEпредставляет собой нечто, являющееся упрощенным вариантом СУБД. API баз данныхв Windows CE оригинальный. База данных состоит из записей. Каждая записьсостоит из полей (свойств). Запись может состоять из переменного количестваполей, память выделяется только под реально существующие поля. Каждое поле предваряется4-байтным заголовком, в котором содержится идентификатор поля и код типа данныхв поле. Каждая запись предваряется 20-байтным заголовком, содержащим метаданныезаписи. Вся база данных имеет символьное имя (до 32 символов) и тип (целоечисло).
Для базы данных можетбыть создано до 4 индексов быстрого поиска — каждый по значению какого-либоодного поля. При открытии базы данных (системный вызов CeOpenDatabaseEx) можетбыть указан один из этих четырех индексов, и в течение этого сеанса работы с базойданных используется только индекс, заданный при открытии. Прежде, чем читатьили писать запись базы данных, ее следует найти. Системный вызов CeSeekDatabaseищет в базе данных запись, поиск может задаваться: по абсолютному илиотносительному значению поля, по абсолютному или относительному номеру взаданном при открытии базы данных индексе, по идентификатору объекта-записи.Если запись найдена, указатель поиска устанавливается на эту запись.Последующие операции чтения или записи оперируют с той записью, на которуюустановлен указатель поиска. Работа с содержимым базы данных выполняется припомощи системных вызовов CeReadRecordPropsEx и CeWriteRecordProps. Эти вызовыпозволяют соответственно читать поля записи или записывать поля в запись. Дляопределения того, с какими именно полями работает системный вызов, должен бытьопределен массив идентификаторов полей. Чтение значений полей записи можетвыполняться не только в локальную кучу программы, но и в любую доступнуюпрограмме область памяти.
Реестры Windows CE хранятконфигурационные установки: данные о приложениях, драйверах, настройкипользователей и т.п. Реестры организованы в иерархическую структуру с ключами изначениями. Ключ может содержать значение или другие ключи — в этом ключподобен каталогу файловой системы. В иерархической структуре ключей возможно неболее 16 уровней. Windows CE поддерживает три «корневых» ключа, вкоторые записываются другие ключи, задающие параметры соответствующего типа:
HKEY_LOCAL_MACHINE — данные о конфигурации аппаратуры и о драйверах;
HKEY_CURRENT_USER — конфигурационные данные пользователя;
HKEY_CLASSES_ROOT — конфигурационные данные приложений.
Ограничение на длинуключа — 255 символов, ограничение на размер значения — 4 Кбайт. Для работы среестрами используется API Win32.
Windows CE продолжаетразвиваться, но наряду с этой ОС фирма Microsoft предлагает также Windows NTEmbedded. Последняя обеспечивает примерно ту же функциональность, ноориентированную не на карманные ПК, а на вычислительные устройства, встраиваемыев различную аппаратуру и строится на ядре Windows NT. Эта технологияразвивается в новой версии ОС для встроенных применений — Windows XP Embedded.Эта ОС строится на базе ядра Windows 2000 (Windows NT 5) и обеспечиваетфункциональность, аналогичную Windows CE и Windows NT Embedded. Основноенововведение в Windows XP Embedded — развитая библиотека компонентов и средстваразработки приложений.
7.4 Новые тенденциивстроенных ОС
Ограниченность ресурсовтонких клиентов определила то обстоятельство, что ОС таких устройств,во-первых, чрезвычайно экономны в потреблении ресурсов, во-вторых, являются ОСреального времени. Основным признаком ОС реального времени является иерархияприоритетов прерываний и возможность приостанова обработки текущего прерывания припоступлении прерывания с более высоким приоритетом. Поскольку прерываниясигнализируют о внешних событиях, указанное свойство позволяет ОС реальноговремени своевременно реагировать на такие события. И PalmOS, и Windows CEявляются ОС реального времени. Большинство других ОС, используемых каквстроенные, также подходят под это определение (например, QNX). Однако,развитие аппаратных средств — увеличение быстродействия, разрядности, объемовпамяти приводит к тому, что в качестве встроенных начинают использоваться«облегченные» версии стандартных ОС [33]. При высоком быстродействииаппаратуры эти ОС позволяют обеспечить приемлемое время реакции даже не дляприоритетных прерываний. Использование большей ОС и большего количества памяти,чем требует ОС реального времени, обходится дороже, но, во-первых, позволяетдобавлять в системы больше возможностей, а во-вторых, позволяет сократить срокиразработки за счет применения инструментальных средств стандартных ОС ипривлечения разработчиков, не обладающих специфическим опытом разработок для ОСреального времени.
Например, технологияMicrosoft Windows NT Embedded для встроенных ОС развивается в новой версии ОСдля встроенных применений — Windows XP Embedded. Эта ОС строится на базе ядраWindows 2000 (Windows NT 5) и обеспечивает функциональность, аналогичнуюWindows CE и Windows NT Embedded. Основное нововведение в Windows XP Embedded — развитая библиотека компонентов и средства разработки приложений. Хотя понекоторым сообщениям от фирмы Microsoft Windows XP Embedded должна бытьосновным предложением фирмы для мобильных и встроенных систем, еще до конца2002 года фирма планирует выпустить ОС Windows CE .Net.
Заметной фигурой на рынкевстроенных ОС стала также ОС Linux. ОС Linux модульная в своей основе. Ядро(фундаментальные элементы ОС, такие как управление памятью и файлами) занимаетпримерно один 1 Мбайт. Оно может быть легко выделено и дополнено модулями,подходящими для встроенных систем. Linux как ОС Открытого Кода предоставляетмножество привлекательных возможностей для производителей и разработчиков и,конечно же, рассматривается ими как альтернатива Microsoft.
Таким образом, можноуказать на две тенденции в развитии встроенных ОС. Одна, представляемая PalmOS,характеризуется прежде всего экономичностью и некоторым аскетизмом ввозможностях, другая, представляемая, например, Windows XP, — более затратнымотношением к ресурсам, но и большими возможностями для пользователя,выражающимися прежде всего в широком использовании мультимедийных средств.Естественно, развитие аппаратных средств делает более перспективной вторуютенденцию. Очевидно, что фирма Palm также не собирается оставаться в стороне отобщего потока, о чем свидетельствует, например, приобретение ею в 2001 г. технологии BeOS, известной своими мультимедийными возможностями, апробированными также и вовстроенных применениях. Однако, как бы интенсивно не развивались аппаратныересурсы, всегда на рынке будет сохраняться устойчивый спрос на более дешевые иболее экономичные решения, таким образом, опыт и технологии PalmOS не останутсяневостребованными.
Глава 8. Операционныесистемы фирмы Apple
8.1 Фирма Apple икомпьютеры Macintosh
История Apple являетсяхрестоматийным примером того, как талант и предприимчивость приносят успех.Персональный компьютер, собранный в гараже Стивом Возняком и Стивом Джобсом,послужил основой для создания в 1976 г. фирмы Apple Computer Company икомпьютера Macintosh. Хотя более чем 25-летняя история фирмы далеко небезоблачна, она переживала взлеты и падения, можно утверждать, что во всепериоды своей деятельности фирма имела собственную концепцию персональныхвычислений, и продукция Apple по качеству и по функциональным возможностямопережала конкурентов. Фирма выжила в конкурентной борьбе как с супергигантамикомпьютерной индустрии, так и с конкурентами, чей стиль борьбы на рынке никакнельзя назвать честным, и в настоящее время компьютеры Apple являютсяединственной реальной альтернативой платформе Wintel в настольных вычислениях.
Хотя компьютеры Appleявляются компьютерами универсального назначения, их аппаратное и программноеоснащение средствами обработки мультимедийной информации всегда было несколькоизбыточным для «рядового» покупателя. Конечно, это утверждение можнооспаривать, но то, что большинство таких пользователей предпочли более дешевуюплатформу Intel+Windows — очевидный факт. Как и то, что пользователи,профессионально работающие в области дизайна, издательской деятельности и вдругих областях, связанных с обработкой мультимедийной информации, предпочитаютMacintosh. Следует отметить, что при более высокой стартовой цене компьютерыApple в итоге обходятся своим покупателям дешевле, так как дольше сохраняютсвою пригодность, и их пользователи избавлены от того беличьего колесанепрерывных модернизаций, в котором вынуждены крутиться пользователи Wintel.
Компьютеры Macintoshпервоначально базировались на процессорах Motorola 680x0 (M68K), внедряя новыепоколения этих процессоров. В 1992 г. в результате совместного проекта фирмApple, IBM и Motorola был разработан процессор PowerPC, и семейство компьютеровMacintosh разделилось на две ветви — одна на процессорах M68K, другая — процессорах PowerMac, также выпускаемых фирмой Motorolla. В настоящее время всеновые модели Macintosh базируются на PowerMac.
Программное обеспечениеMacintosh, как и аппаратное, в значительной степени ориентировано напредоставление пользователям развитых мультимедийных возможностей. Графическийпользовательский интерфейс компьютеров Apple служит образцом для всех другихсистем. Операционная система Mac OS эволюционировала на протяжении долгих лет илишь в 1998 г. уступила место ОС Mac OS X.
8.2 Mac OS
Хотя в оригинальнойдокументации [28] нам не удалось найти определения архитектуры Mac OS, мывозьмем на себя смелость определить ее как модульно-иерархическую, какпредставлено на рисунке 8.1.
/>
Рисунок 8.1 АрхитектураMac OS
Систему, по-видимому,можно разделить на несколько подсистем, каждая из которых выполняет управлениеопределенным видом ресурсов (памятью, задачами, файлами, средствамикоммуникаций и т.д.). Подсистема состоит из нескольких Менеджеров, каждый ихкоторых обеспечивает более высокий уровень абстракции ресурсов. Менеджеры болеевысокого уровня используют средства Менеджеров низкого уровня своей подсистемы,а также и других подсистем. API же системы предоставляет доступа к возможностямпрактически любого уровня абстракции. На рисунке 8.2, например, показанаструктура подсистемы управления взаимодействием процессов.
Управление памятью
При работе с реальнойпамятью Mac OS обеспечивает работу с адресным пространством размером 16 Мбайт(24-разрядный адрес). Разумеется, все адресное пространство не обязательноподдерживается реальной памятью, заполнение адресного пространства реальнойпамятью может быть фрагментировано. До 8 Майт в верхней части адресногопространства составляет пространство ввода-вывода.
Память в такой моделивыделяется разделами. Нижняя часть памяти (от адреса 0) составляет системныйраздел. В нем размещены глобальные переменные системы и системная куча. Всистемной куче выделяется память для буферов, системных структур данных исистемных кодовых сегментов.
Каждому приложениювыделяется раздел приложения. В разделе приложения содержится:
управляющая информацияприложения, так называемый «мир A5» (A5 world);
стек приложения;
куча приложения.
«Мир A5»(название происходит от имени регистра микропроцессора M 68К, которыйиспользуется для адресации) содержит:
глобальные переменныеприложения;
глобальные переменныеQuickDraw (подсистемы экранного отображения);
параметры приложения;
таблицу переходов.
Стек приложения используетсядля сохранения адресов возврата и выделения памяти для локальных переменных. Вкуче размещаются коды и данные приложения. Кроме того, приложению могутвыделяться по запросу блоки памяти вне его раздела.
Память в куче выделяетсяблоками переменной длины. Блоки могут быть перемещаемыми или неперемещаемыми.Обращение к неперемещаемому блоку производится по прямому адресу. Обращение кперемещаемому блоку производится с применением косвенной адресации через, такназываемый, главный блок указателей (master pointer block). Для каждогоприложения система создает такой блок определенного по умолчанию размера,размер блока может быть увеличен самим приложением. Такой способ выделенияпамяти приводит к образованию «внешних дыр», которые могут уменьшатьобъем доступной для приложения памяти. Для борьбы с этим явлением системапроизводит (при нехватке памяти) дефрагментацию кучи — переписывает в памятивсе перемещаемые блоки таким образом, чтобы внешние дыры слились в однусвободную область в верхней части кучи. При переносе блоков корректируетсяглавный блок указателей, таким образом, перенос остается прозрачным дляприложения. Наличие в куче неперемещаемых блоков снижает эффективность сжатиякучи, поэтому система стремится разместить все перемещаемые блоки в нижнейчасти кучи. Если при размещении перемещаемого блока оказывается, что то место внижней части кучи, на которое он претендует, занято перемещаемым блоком,система переносит перемещаемый блок в другое место и освобождает место длянеперемещаемого.
Перемещаемый блок можеттакже быть объявлен удаляемым: системе разрешается удалять его при нехваткепамяти в куче приложения. Работая с удаляемым блоком, программист должен всякийраз, начиная работу с ним, проверить его наличие в памяти и отменить признак, разрешающийудаление.
Введение в компьютерыфирмы Apple динамической трансляции адресов позволило перейти к 32-разрядномуразмеру адреса и, таким образом, обеспечивать виртуальное адресное пространстворазмером в 4 Гбайт. Динамическая трансляция адресов использует страничнуюмодель виртуальной памяти для расширения адресного пространства. Страничныйобмен использует алгоритм LRU. Структура нижней части адресного пространства(до границы 16 Мбайт) — такая же, как и в 24-разрядной модели, что обеспечиваетпрозрачное выполнение 24-разрядных приложений в новой среде. Для 32-разрядныхприложений могут выделяться дополнительные разделы выше 16-Мбайтной границы.
В описанной выше моделиреальной памяти, расширенной затем за счет динамической трансляции адресов,сложилась сегментная архитектура выполнения приложений, которую называют«классической» архитектурой 68K. Приложение в этой архитектуресостоит из сегментов размером до 32 Кбайт каждый. Сегментная архитектураподдерживается Менеджером Сегментов в составе Mac OS. Для каждого приложенияавтоматически создается и загружается при запуске Сегмент 0, остальные сегментызагружаются по требованию.
Связь между сегментамиобеспечивается через таблицу переходов (jump table), которая размещается вместес «миром A5». Таблица переходов содержит адреса входных точек всегментах, таким образом, обращения к процедурам в других сегментахпроизводятся через таблицу переходов. Сегменты размещаются в перемещаемыхблоках памяти в куче приложения и, таким образом, могут быть перемещены впамяти с коррекцией содержимого таблицы переходов. Загрузка сегментовпроизводится автоматически при первом обращении к любой входной точке сегмента.Сегмент может быть также и выгружен из памяти, но это приложение должно сделатьявным образом: выполнить системный вызов, помечающий сегмент как удалаямый.Помеченный таким образом сегментный блок может быть удален из памяти принехватке памяти.
Архитектура CFM
В новых версиях Mac OS наM68K и PowerMac введена иная архитектура выполнения приложений. Она поддерживаетсяМенеджером Кодовых Фрагментов — CFM (Code Fragments Manager) в составе ОС,поэтому называется архитектурой CFM. Архитектура CFM в максимальной степенииспользует концепцию динамической компоновки. Программа (кодовый ресурс) втерминах Mac OS состоит из двух ответвлений (fork) — ресурса (кодов) и данных(статических данных). Приложение в архитектуре CFM загружается системнымзагрузчиком (Finder). Другой вид кодовых ресурсов составляют разделяемыебиблиотеки и подключения (plug-in). Эти ресурсы CFM подключает к приложению вовремя выполнения и обеспечивает возможность совместного использования ихразными приложениями. При этом они не используют память приложения, азаписываются отдельно. Разница между библиотеками и дополнениями состоит в том,что первые подключаются автоматически, а вторые — специальным системнымвызовом. Подключения могут содержать собственную главную процедуру (функциюmain). Установленная связь процесса с фрагментом называется соединением(connection). Приложение может иметь соединения с несколькими фрагментами,также и фрагмент может быть соединен с несколькими приложениями одновременно.При обработке фрагментов CFM использует концепцию «застежек»(closure). Застежка является набором соединений процесса с фрагментами.Застежка представляет собой «корневой фрагмент», к которому CFMобращается для выполнения связывания с любыми разделяемыми библиотеками. Какправило, процесс имеет одну застежку, но для связывания с подключением(plug-in) создается отдельная застежка подключения.
Как упоминалось выше, дляфрагмента может быть создано несколько соединений — как с одним процессом, таки с несколькими. При этом ответвление кода и ответвление данных соединяютсяотдельно и не обязательно в одной застежке. Если для кодового ответвления создаетсянесколько соединений, то все соединения совместно используют один экземпляркода. Для ответвления данных возможена глобальная реализация (один и тот жеэкземпляр данных используется всеми соединениями в системе) или реализация дляпроцесса (CFM создает отдельную копию данных для каждого процесса). Возможностьглобальной реализации или реализации для процесса определяется при созданииразделяемых библиотек. Установление связи между процессом и библиотечнымфрагментом осуществляется при помощи таблицы связываний, помещаемой редакторомсвязей в каждое приложение. В этой таблице предусматриваются строки для всехбиблиотечных входных точек, к которым обращается приложение. В кодах приложенияобращения к внешним точкам имеют вид косвенных обращений к таблице связываний.При создании соединения CFM находит нужную библиотеку и заполняет таблицусвязываний приложения ссылками на адреса входных точек в оглавлении библиотеки.
Динамическая компоновкаявляется средством, обеспечивающим возможность модификации разделяемых(например, системных) библиотек прозрачно для приложения. Для обеспечениясовместимости версий приложений и библиотек в таблицу связываний приложениявключаются граничные номера версий библиотеки, с которыми приложение можетработать. CFM при создании соединения выполняет сопоставление этой информации сверсией найденной библиотеки.
Управление процессами инитями
Mac OS во всех своихверсиях являлась системой с кооперативной многозадачностью. Процессом в системеявляется запущенное приложение или, в некоторых случаях, открытый аксессуаррабочего стола. В каждый момент только один процесс находится на переднем плане- тот, с которым взаимодействует пользователь, остальные являются фоновыми.Возможны также только-фоновые процессы, разработанные без пользовательскогоинтерфейса. Переключение процессов происходит только в том случае, если процесспереднего плана приостанавливается, если он выдает системный вызовWaitNextEvent или EventAvail, но в системной очереди событий нет для негосообщений. Только при выполнении этих системных вызовов возможно переключениеконтекста. Различается переключение контекста значительное (major) инезначительное (minor). Первое происходит в том случае, если фоновый процессстановится процессом переднего плана. В этом случае ОС посылает процессупереднего плана «событие приостанова». Обрабатывая это событие,процесс переднего плана может выполнить требуемые прикладные операции,связанные с переходом на задний план. Когда процесс переднего плана в следующийраз выдаст системный вызов WaitNextEvent или EventAvail, он будет задержан.Фоновый процесс в этом случае получает от ОС «событие возобновления».Незначительное переключение происходит, когда фоновый процесс получаетпроцессорное обслуживание, не переходя на передний план, например, когдапроцесс переднего плана ожидает действий пользователя. В этом случае, когдапроисходит событие, которого ожидает процесс переднего плана, фоновый процессприостанавливается при следующей выдаче им системного вызова WaitNextEvent илиEventAvail, независимо от того, есть ли для него сообщения в системной очередисобытий.
Другой формой,использующей процессорный ресурс, являются в Mac OS задачи (task). Задачипредставляют собой обработчики прерываний. Приложение имеет возможностьустановить собственную обработку некоторых прерываний. Пользовательскаяобработка прерываний поддерживается:
Менеджером Времени,который позволяет приложению выполнять задачи через заданные интервалы времени;
Менеджером Регенерации(Vertical Retrace Task), который позволяет выполнять задачи между цикламивосстановления изображения на экране;
Менеджером Уведомления(Notification Manager), который обеспечивает как для процессов, так и для задачавральную сигнализацию пользователю (например, в случае ошибки);
Менеджером Устройств,который дает возможность драйверам обрабатывать прерывания от устройств.
Все эти менеджерыиспользуют установленную приложениями информацию о задачах, помещаемую всистемные очереди.
Когда задача получаетуправление, она не обязательно выполняется в контексте приложения, создавшегоданный обработчик прерывания. Поэтому действия, выполняемые в составе задачи,существенно ограничены, и для установления связи обработчика прерывания ссоздавшим его приложением должны быть выполнены определенные специальныедействия. Некоторые обработчики прерываний не деинсталлируются автоматическипри завершении установивших их приложений.
Mac OS обеспечивает такжемеханизм нитей. Нить, как и в большинстве других систем, имеет собственныйвектор состояния процессора и собственный стек. Нити могут создаваться поотдельности или же может быть сначала создан пул нитей, а затем новые нитисоздаются из пула. Второй вариант обеспечивает более рациональное использованиересурсов, в частности, меньшую фрагментацию памяти. В первой реализацииМенеджера Нитей поддерживалась вытесняющая многопоточность в рамкахневытесняющей многозадачности, но затем дисциплину управления нитями сделалитакже кооперативной. Нить, получившая процессорное обслуживание, может отдатьего либо уступив процессор любой нити (в этом случае готовые к выполнению нитивыбираются из очереди по дисциплине FCFS), либо уступив процессор какой-токонкретной нити, либо просто изменив свое состояние на ожидание. Отличиепоследнего случая от первых двух состоит в том, что выполнение нитиприостанавливается даже если нет других готовых нитей. Пользователь имеетвозможность также определить свою процедуру диспетчеризации нитей, котораявыполняется перед выполнением системного планировщика.
Хотя при невытесняющеймногозадачности в этом нет необходимости, предусмотрены специальные системныевызовы — скобки критической секции. Внутри критической секции простоигнорируются выдаваемые нитью системные вызовы, уступающие процессор.
Интересной особенностьюMac OS является возможность создания также пользовательских процедурпереключения контекста для нитей. Для каждой нити может быть создано две такихпроцедуры, одна из них выполняется перед переключением контекста на другуюнить, вторая — при переключении контекста на данную нить.
Поскольку Mas OS работаетна двух разных аппаратных платформах, имеются некоторые различия в форматахструктур данных для платформ M68K и PowerMac (например, в PowerMac рольрегистра A5 играет другой регистр), но эти различия не касаются качественнойструктуры и алгоритмов обработки. Системы программирования для Mac OS позволяютсоздавать программы в кодах той или другой платформы, системой поддерживаетсятакже программные ресурсы «толстого» (fat) формата, содержащие кодпрограммы для обеих платформ и, следовательно, переносимые без каких-либодополнительных действий.
Средства взаимодействия
Mac OS предусматриваетвесьма развитые механизмы взаимодействия между процессами, основанные преждевсего на очередях сообщений (в Apple они называются событиями) и одинаковоприменимые для локального и для удаленного взаимодействия. Эти механизмыобеспечиваются набором менеджеров в составе ОС, которые выстраиваются виерархическую структуру: менеджер более высокого уровня пользуется услугамименеджеров нижних уровней (см. рисунок 8.2).
/>
Рисунок 8.2 Средствавзаимодействия приложений в Mac OS
Приложение можетпользоваться услугами менеджеров любого уровня иерархии, что обеспечиваетширокий спектр возможностей взаимодействия, включающий в себя:
Динамическое разделениеданных, обеспечиваемое Менеджером Публикации (Edition Manager). Позволяетприложению копировать данные из одного документа (издателя) в другой документ(подписчик) с автоматическим обновлением данных у подписчика, если они измененыу издателя.
Обмен «событиямиApple». События Apple — высокоуровневые события, которые соответствуютпротоколу AEIMP (Apple Event Interprocess Messaging Protocol), обеспечиваемомуМенеджером Событий Apple. Средства Менеджера Событий Apple позволяют приложению-клиентуформировать и посылать события Apple, представляющие собой обычно некоторыйзапрос на обслуживание, а приложению-серверу — принимать события и отвечать наних. Имеется несколько стандартных комплектов событий Apple (обязательныйкомплект, комплект ядра, комплекты текста и базы данных), применение которыхобеспечивает взаимодействие несвязанных приложений. Наряду с событиямистандартных комплектов пользователями могут вводиться собственные событияApple, интерпретируемые самими приложениями.
Обмен другими событиями.Менеджер Событий обеспечивает для приложений обмен событиями, несоответствующими протоколу AEIMP.
Обмен блоками сообщений.Средства PPC (Program-to-Program Communications) позволяют приложениямобмениваться большими блоками данных на низком уровне управления. Приприменении этих средств приложения, участвующие в диалоге, должны выполнятьсяодновременно и обмениваться данными через общий коммуникационный порт.
Отдельно следует назватьскрипты, функциональность которых выходит за рамки только взаимодействия междупроцессами. Скрипт представляет собой, фактически, программу, написанную наинтерпретирующем языке высокого уровня AppleScript. Скрипты могут быть записаныв приложения, в документы или в отдельные файлы, загружаемые системным загрузчикомFinder. С точки зрения использования скриптов различаются следующие свойстваприложений.
Приложения, выполняющиескрипты (scriptable). Такое приложение способно реагировать на стандартныесобытия Apple, посылаемые интерпретатором AppleSkript, и, следовательно,выполнять действия, определенные в скрипте. При посылке сообщения такомуприложению интерпретатор использует специальный ресурс типа «aete»(Apple event terminology extention), в котором описывается соответствиевысокоуровневого описания терминов, используемых в скрипте, кодам событийApple, которые обрабатывает приложение.
Регистрирующие приложения(recordable). Такое приложение посылает события самому себе. Обычно черезсобытия обеспечивается связь вычислительной части приложения с частью, обеспечивающейпользовательский интерфейс. Параллельно с передачей события между частямирегистрирующего приложения копия события поступает интерпретатору, который,пользуясь ресурсом типа «aete», записывает действия, определяемыеданным событием, в виде скрипта.
Приложения, выполняющиескрипты и манипулирующие ими. Приложение может записывать и выполнять скрипты,устанавливая соединение с интерпретатором языка скриптов как с подключением(plug-in).
В одном приложении могутобъединяться все три описанные свойства.
Мы говорили о языкеAppleScript, однако на самом деле механизм скриптов более гибок. Он строится попринципу Открытой Архитектуры Скриптов OSA (Open Scripts Architecture). OSAдопускает использование любых языков для написания скриптов. Интерпретатор тогоили иного языка скриптов является выбираемым компонентом. Менеджер Компонентоввыбирает заданный компонент для выполнения того или иного скрипта.Интерпретатор AppleScript, таким образом, является лишь одним из возможныхкомпонентов в системе OSA.
Ввод-вывод и файловаясистема
Корневой структурой вуправлении вводом-выводом является Таблица Устройств, неперемещаемая всистемной куче. Каждый элемент Таблицы Устройств адресует один Блок УправленияДрайвером. Блок Управления Драйвером является перемещаемым в системной куче исодержит адрес тела драйвера и адрес начала очереди запросов к драйверу.Драйверы бывают синхронные и асинхронные. Первые обслуживают обычно символьныеустройства и полностью завершают транзакцию ввода-вывода до возвращения управления.Вторые применяются для блочных устройств и только инициируют операциюввода-вывода; эти драйверы используют прерывания от устройств для того, чтобывновь получить управление и завершить транзакцию.
Запросы на ввод-выводимеют стандартную форму и выстраиваются в очереди к устройствам. Очередиуправляются Менеджером Устройств по дисциплине FCFS. Различают запросыасинхронные, синхронные и неотложные. Асинхронный запрос просто ставится вочередь, после чего управление возвращается выдавшему его приложению.Синхронный запрос переводит приложение в ожидание до выполнения запроса.(Синхронный/асинхронный тип запроса не связан с синхронным/асинхронным типомдрайвера.) Неотложный запрос передается Менеджером Устройств прямо на драйвер вобход очереди. Поскольку это может произойти в тот момент, когда драйверобрабатывает другой запрос, драйвер, которому могут посылаться неотложныезапросы, должен быть реентерабельным.
Все операции, выполняемыедрайвером, сводятся к нескольким видам, и каждый драйвер должен иметь входныеточки в процедуры обработки следующих видов запросов:
открытие — выделениепамяти и инициализация устройства;
закрытие — деактивизациядрайвера и устройства;
управление — выполнениеспецифических для устройства функций
статус — получение информацииот драйвера, эта процедура специфична для устройства и может бытьнеобязательной;
базисные (prime) операции- ввод и вывод, эта процедура также необязательна и может обеспечивать либоввод, либо вывод, либо и то и другое.
Файловые системы Mac OSназываются Иерархическими Файловыми Системами — HFS (Hierarchical File System)и HFS Plus. Как и файл программы, любой файл состоит из двух ответвлений (fork)- ресурсов и данных. В частном случае одно из ответвлений может быть пустым.Ответвление данных не структурировано, ответвление ресурсов содержит картуресурсов и сами ресурсы, файл может иметь до 2700 ресурсов. Если, например,файл является файлом приложения, ресурсы описывают меню и диалоговые окнаприложения, его иконки, события и т.д. и содержат исполняемый код приложения;если файл является, например, документом, ответвление ресурсов содержитразмещение окна документа, иконки, шрифты и т.д. Строго говоря, граница междуресурсами и данными не очень четкая. Информация файла может быть помещена как вответвление данных, так и в ответвление ресурсов. В ответвление ресурсовпомещаются те данные, которые ограничены по размеру и количеству значений.
Дисковое пространствосостоит из секторов размером по 512 байт каждый, но распределение дисковойпамяти ведется кластерами (в Mac OS они называются блоками распределения). Блокраспределения содержит целое число смежных секторов. Размер блока распределенияфиксирован для данного тома.
Каждый том физическойфайловой системы HFS имеет заголовок тома, содержащий общую информацию о томе,такую как: дата создания и общий размер тома, число файлов на томе, а такжерасположение остальных управляющих структур файловой системы. Заголовок всегдарасполагается в секторе 2, копия заголовка размещается в конце тома.
HPFS Plus для управленияразмещением информации на томе использует специальные файлы, которыеразмещаются не на фиксированных позициях в томе, а в произвольных местахпространства данных. Различаются следующие специальные файлы.
Файл каталога — содержитинформацию об иерархии папок и файлов на томе. Каталог организован как B-деревои содержит записи четырех видов:
запись папки — информацияоб отдельной папке
запись файла — информацияоб отдельном файле;
запись связи папки — информация о родительской папке для данной папки;
запись связи файла — информация о родительской папке для данного файла.
Информация о файлевключает в себя два плана размещения — для ответвления ресурса и дляответвления данных. Размещение файла выполняется экстентами переменной длины,часть плана, размещаемая в записи файла, содержит массив из дескрипторов 8первых экстентов. Если файл фрагментирован на большее число экстентов,дескрипторы дополнительных экстентов находятся в файле переполнения экстентов.
Файл переполненияэкстентов — содержит информацию о дополнительных экстентах файлов, непоместившихся в основные записи файлов в каталоге. Этот файл общий для всеготома и также организован как B-дерево, ключами в котором являются:идентификатор файла, тип ответвления и адрес начала экстента относительноначала файла.
Файл атрибутов — структура, введенная для будущих реализаций, предусматривающих наличиеименованных ответвлений в файле. Организован как B-дерево.
Файл размещения — представляет собой битовую карту свободных/занятых блоков распределения. Файлразмещения применяется только в HFS Plus, в HFS его функцию выполняла отдельная«область битовой карты», размещавшаяся на томе по фиксированномуадресу.
Пусковой файл — файл,содержащий информацию для загрузки с диска HFS операционной системы, отличнойот Mac OS.
Интерфейс пользователя
Фирма Apple была иостается лидером в области графического интерфейса пользователя. Сама концепцияWIMP-интерфейса, если не родилась в компьютерах Macintosh, то прошла на нихпромышленную апробацию. Mac OS является системой с«только-графическим» интерфейсом, и все операции пользователя ссистемой и с приложениями производятся только через манипулированиеграфическими объектами. Основные концепции интерфейса Mac OS:
метафоры, главной изкоторых является метафора рабочего стола и интегрированные с ней метафорыдокументов и папок;
прямое манипулированиеобъектами;
прямое целеуказание(принцип see-and-point — увидеть и указать);
согласованностьинтерфейса — одинаковое образное представление и одинаковое поведениеинтерфейсных элементов в разных приложениях и системных операциях;
доступность всех объектови функций для пользователя;
информированностьпользователя о происходящих в системе процессах и о результатах еговоздействий;
и т.д.
Эти и другие свойстваобеспечивают интерфейсу Mac OS интуитивную понятность, дружественность ипредсказуемость. Большинство принципов построения пользовательского интерфейсаMac OS было с той или иной степенью последовательности внедрено в другиесистемы, так что даже пользователи, никогда не имевшие дела с компьютерамиMacintosh, имеют о них представление «из вторых рук». Следует,однако, отдельно упомянуть еще об одном из таких принципов, отличающеминтерфейс Mac OS от интерфейса, например, Windows. Это принцип «пользовательскогоуправления». Apple исходит из того, что работа происходит болееэффективно, если пользователь является в ней активной, инициативной стороной.Это означает, что пользователь, а не компьютер должен инициировать управляющиедействия. Разумеется, в некоторых случаях компьютер «берет управление насебя» — если, например, имеются ограничения в выборе альтернатив в данномконтексте или для того, чтобы предохранить пользователя от излишней детализациив формировании управляющего действия. Однако подход Apple состоит в соблюдениитакого баланса между предоставлением пользователю всей полноты возможностей ипредохранении его от разрушения данных, при котором инициатива пользователя неущемляется никоим образом.
Набор программныхмодулей, которые обеспечивают базовые функции работы с интерфейсной графикой(рисование, перемещение, вращение и т.п. образов), называется в Mac OSQuickDraw. Приложения используют QuickDraw неявным образом, когда обращаются кдругим менеджерам графического интерфейса для создания интерфейсных элементов иманипулирования ими. QuickDraw развивался вместе с Mac OS — от черно-белогоизображения к цветному и далее — к 3-мерной графике. При этом сохраняетсясовместимость новых версий QuickDraw со всеми предыдущими. Современные версии QuickDrawGX используют объектно-ориентированную архитектуру графического интерфейса.
Хотя Mac OS являетсяоднопользовательской системой с невытесняющей многозадачностью, она вполнеудовлетворяла требованиям своих пользователей, несмотря на то, что некоторыеприменяемые в ней технологии уже несколько устарели. Mac OS версии 8 и 9 исейчас продолжает применяться. Однако расширение ресурсов компьютеров Macintoshи стремление фирмы Apple выйти на рынок серверных систем потребовали созданияпринципиально иной ОС.
8.3 Mac OS X
Путь фирмы Apple к новойоперационной системе — многопользовательской, с вытесняющей многозадачностью ис защитой памяти — оказался долгим и нелегким. В середине 90-х годов фирманеоднократно начинала проекты новых ОС, иногда даже демонстрировала ихальфа-версии, но по разным причинам эти проекты так и не дошли до промышленнойреализации. Только в 1998 г. усилия фирмы увенчались успехом и появилась новаяОС — Mac OS X [29]. Текущая версия Mac OS X — 10.1.3 (сохранена сквознаянумерация версий от Mac OS к Mac OS X).
Mac OS X представляетсобой удивительное сочетание оригинальных закрытых программных технологий Appleс открытыми технологиями, ставшими промышленными стандартами. Архитектура MacOS X, показанная на рисунке 8.3, имеет явно выраженную иерархическую структуру.
/>
Микроядро Darwin
Mac OS X строится на баземикроядра, которое называется Darwin. Внутри же Darwin находится «ядро вядре» — микроядро Mach. Mach [27] является «классическим»микроядром, оно было разработано в университете CarnegieMellon (начало проекта- 1985 г.), и именно в этом проекте родились основные концепции архитектурымикроядра, ныне являющиеся общепринятыми. Микроядро Mach было создано на основеBSD и послужило основой для ряда Unix-подобных (точнее — BSD Unix-подобных)систем, например, ядра OSF/1 и сделанной на его основе ОС DIGITAL UNIX.
И Mach, и Darwin являютсяпродуктами в Открытых Кодах и поддерживаются организацией Open Group.
Mac OS X строится наверсии микроядра Mach 3 и, по-видимому, является единственной не-Unix системой,использующей ядро Mach.
Mach поддерживаетосновные низкоуровневые функции управления ресурсами, такие как:
управление единицамивыполнения (нитями);
назначение ресурсов дляпроцессов (в терминологии Mach — задач, task);
поддержку адресныхпространств для задач;
обмен сообщениями междузадачами;
управление реальнымиресурсами (процессорами, памятью, вводом-выводом).
Управление памятью вMach, как и в большинстве современных Unix-систем, обеспечивает для каждойзадачи виртуальное адресное пространство размером 4 Гбайт, в принципе,изолированное от адресных пространств других задач. Адресное пространствостроится на страничной модели памяти, однако соседние виртуальные страницы,обладающие одинаковыми свойствами, могут составлять область (сегмент). Как имногие другие Unix-системы, Mach использует абстракцию «объектовпамяти», представляющую собой надстройку над обычными механизмамивиртуальной памяти. Объекты памяти создаются в виртуальном адресномпространстве, а реальная память рассматривается только как кеш дляпредставления этих объектов. Области и объекты памяти могут совместноиспользоваться несколькими задачами.
Mach обеспечиваетвытесняющую многозадачность и многопоточность (API нитей в Mach соответствуетспецификациям POSIX). Как и во всех BSD-системах, нить обладает достаточнополным набором ресурсов для выполнения, таким образом, в Mach нет необходимостивводить легковесные процессы, как, например, в Open Unix. Все нити одной задачиразделяют адресное пространство задачи и некоторые ресурсы задачи. Каждая нитьимеет собственный вектор состояния, стек, параметры планирования икоммуникационные порты. Диспетчеризация нитей ведется по приоритетномупринципу, приоритеты назначаются и изменяются вне микроядра. Нить может бытьсделана «закрепленной» (wired). Такая нить являетсяпривилегированной: она получает управление сразу же при достижении состоянияготовности и ей выделяется память даже при нехватке реальной памяти. Этопозволяет Mach обеспечивать процессы реального времени.
Многопоточность Machработает как на одном процессоре, так и на SMP конфигурациях.
Задачи в Machвзаимодействуют через посылку сообщений и прием ответов. Сообщения передаютсячерез коммуникационные порты, которые представляют собой почтовые ящики илиочереди сообщений, описанные нами в главе 9 части I. При создании любой нитидля нее создаtтся также собственный порт для приема сообщений от других нитей ипорт для приема исключений. Собственный набор портов создается и для задачи.
Микроядро Darwin являетсярасширением Mach. Кроме Mach, Darwin содержит следующие основные компоненты:
Инструменты ввода-вывода- объектно-ориентированный каркас для разработки драйверов устройств, созданиядрайверов и обеспечения требуемой для драйверов инфраструктуры.
Файловая система — основывается на виртуальной файловой системе VFS и обеспечивает возможностьдобавлять новые файловые системы. В настоящее время поддерживаются HFS, HFSPlus, ufs и ISSO 9660 — файловая система для CD.
Расширенные сетевыесредства Network Kernel Extensions (NKE), позволяющие разработчикам какдобавлять поддержку новых протоколов, так и расширять функциональность ужеподдерживаемых.
BSD — оболочка BSD 4.4вокруг ядра. Реализация BSD в Darwin включает в себя много API POSIX,обеспечивает модель процессов, базовые политики безопасности и поддержку нитейдля Mac OS X.
Службы ядра
Службы ядра содержат тесистемные сервисы, которые не связаны с графическим интерфейсом пользователя.Основные компоненты этих служб — менеджеры среды Carbon, а также CoreFoundation и Open Transport.
Менеджеры среды Carbonявляются общесистемными и обеспечивают низкоуровневый сервис для всехприкладных сред. В число этих менеджеров входят, например:
Collection Manager — обеспечение абстрактных типов для коллекций данных.
Component Manager — обеспечение для приложения возможности находить во время выполнения различныепрограммные объекты (компоненты), а также создавать компоненты.
Date, Time, andMeasurement Utilities — работа с датой, временем, географическими местами,временными зонами и т.п.
File Manager — файловыйAPI для всех файловых систем.
Folder Manager — обеспечение работы с папками.
Memory Manager — выделение памяти в виртуальном адресном пространстве задачи и другие функцииуправления виртуальной памятью.
Multiprocessing Services- средства для создания нитей, управления ими и синхронизации.
Core Foundation — каркас,который обеспечивает некоторые базовые программные службы, полезные для болеевысоких уровней программного обеспечения. Core Foundation используетобъектно-ориентированную парадигму «непрозрачных» типов, «черныхящиков» для таких программных объектов как числа, строки, массивы,словари, деревья и т.д. Этот компонент также обеспечивает работу сподключениями (plug-in) и ряд других сервисов. Некоторые из сервисов,обеспечиваемых Core Foundation:
String Services — наборинструментов для манипулирования строками, включая поддержку Unicode.
Bundle Services — средства организации и поиска различных типов программных ресурсов (исполняемыхкодов, графических и звуковых образов и т.п.).
Plug-in Services — обеспечение архитектуры подключений.
Collection Services — высокоуровневые абстракции коллекций.
URL Services — средствадоступа к локальным или удаленным ресурсам через URL.
Notification Services — механизм обмена сообщениями (уведомлениями) между процессами.
Open Transport — основныемодули пользовательского уровня для обеспечения работы в сети и коммуникаций вMac OS X.
Прикладные службы
Главная задача прикладныхслужб Mac OS X — обеспечение графического и оконного интерфейса. Главной частьюэтих служб является набор модулей Quartz, который состоит из двух частей:исполнения изображений (собственно Quartz) и базовых графических служб илисервера окон (Core Graphics Services). Вторая часть представляет собойбиблиотеку, обеспечивающую некоторые общие сервисы для других прикладных служб.
В сумме Quartz являетсямощной графической системой, которая обеспечивает 2-мерную графику на основеформата PDF и работу с окнами и составляет основу для формирования изображенийв Mac OS X — как для системных модулей, так и для приложений. Эта системаобладает такими свойствами, как независимость от разрешающей способности,преобразование координат, сплайны, прозрачность, сглаживание и т.д., чтопозволяет обеспечить системе и приложениям весьма изысканный графическийинтерфейс.
Mac OS X реализует такжеOpenGL — многоплатформенный промышленный стандарт для 3-мерного рисования иускорения работы аппаратуры. Использование OpenGL обеспечивает высокуюэффективность в создании анимации в реальном времени для игр и научной илиделовой визуализации.
Система QuickTimeпредоставляет средства для эффективной работы с мультимедийной информацией,такой как видеоролики, изображения, аудиозаписи. Компоненты QuickTime позволяютприложениям не зависеть в работе с мультимедийной информацией от конкретныхтипов устройств и памяти. Каждый компонент обеспечивает какой-то определенныйнабор свойств и предоставляет определенный API для использующих его приложений.Компонент является кодовым ресурсом, который регистрируется МенеджеромКомпонентов, и Менеджер Компонентов обеспечивает его доступность в рамках всейсистемы. Различные приложения могут использовать компоненты, не вникая в деталиих реализации.
Некоторые прикладныеслужбы Mac OS X (не показанные на рисунке 8.2) обеспечивают отображениенизкоуровневых объектов (объектов ядра) в объекты API. Менеджеры Carbon,которые обеспечивают этот сервис, обслуживают все прикладные системы. Ниже мырассматриваем некоторые из этих служб.
Carbon Process Manager(CPM) обеспечивает абстракцию процесса для прикладных сред. В ядре процесс(задача) является сущностью, состоящей из набора нитей, адресного пространстваи пространства имен портов. CPM на базе задачи ядра создает CPM-процессы,которые представляют процессы для прикладных сред. В средах Carbon, Cocoa иJava каждому CPM-процессу соответствует одна задача ядра. Для среды Classic (сневытесняющей многозадачностью) создается один CPM-процесс для каждого приложения,но все CPM-процессы приложений отображаются на единственную задачу ядра.
Базовый механизм нитей вмикроядре Mach преобразуется в ядре в многопоточную среду POSIX. Нитяммикроядра соответствуют нити POSIX. Лежащие выше уровни программного обеспечениясоздают прикладные модели многопоточных сред, а именно:
Multiprocessing Service — диспетчеризация нитей с вытеснением в среде Carbon;
Tread Manager — диспетчеризация нитей без вытеснения в среде Carbon;
NSThread — класс-оболочкадля представления нитей с вытеснением в среде Cocoa;
java.lang.Thread — класс-оболочка для представления нитей с вытеснением в среде Java.
Во всех моделях, кромеTread Manager нити приложения соответствует нить POSIX, в модели Tread Managerвсе нити приложения отображаются на одну нить POSIX.
Базовые механизмы в ядре,обеспечивающие взаимодействие между процессами, — очереди сообщений,передаваемых через коммуникационные порты. Прикладные службы строят на основеэтого механизма множественные прикладные модели взаимодействия, а именно:
события Apple;
простые уведомления(simple notification) — передача сообщения в «центр уведомлений»,который распространяет сообщение для всех процессов, которые в нем«заинтересованы»;
передачанеструктурированных данных — быстрый низкоуровневый способ обмена данными междулокальными процессами;
сокеты BSD — основноймеханизм Mac OS X для передачи данных в сети;
программные каналы(pipe);
сигналы (набор сигналовBSD);
разделяемые областипамяти с управлением доступом к ним через семафоры;
объектно-ориентированныемеханизмы «стандартных служб» и «распределенных объектов» всреде Cocoa;
обмен сообщениями черезпорты микроядра Mach.
Прикладные среды
Прикладные среды Mac OS Xсостоят из каркасов (framework), библиотек и сервисов, которые обеспечиваютвыполнение приложений в той или иной модели API. Mac OS X в настоящее времяподдерживает следующие прикладные среды.
Carbon — развитие API MacOS для Mac OS X. Около 70% системных вызовов Carbon имеются и в Mac OS, такимобразом, может быть обеспечена переносимость приложений в обе стороны. Как былопоказано выше, Менеджеры Carbon выполняют обслуживание также и другихприкладных сред. В Carbon часть менеджеров Mac OS подвергласьусовершенствованию, часть была заменена, некоторые были добавлены. Наиболеесущественные изменения произошли в управлении памятью (адаптация к болееразвитой модели виртуальной памяти и к защите памяти), в интерфейсахоборудования (менеджеры Mac OS X уже не выполняют низкоуровневые операции наоборудовании непосредственно), полностью заменены менеджеры печати и управлениясобытиями.
Cocoa — объектно-ориентированная среда для языков Java и Objective-C. Базируется надвух каркасах: Foundation и Application Kit. Каркас Foundation обеспечиваетобъекты и методы, не связанные напрямую с интерфейсом: базовые типы и операции(строки, массивы, словари и т.п.), классы-оболочки для объектов ядра (задачи,нити, порты и т.д.), общую функциональность, связанную с объектами (управлениепамятью, архивация, сериализация и т.д.), функциональность ввода-вывода ифайловой системы, другие службы (распределенные уведомления, дата и время,откат операций и т.д.). Каркас Application Kit в основном обеспечивает классыпользовательского интерфейса (окна, меню, диалоги, кнопки и т.п.), но также и наборболее развитых возможностей, таких как рисование и создание композитныхобразов, управление событиями, приложениями и документами и т.д.
Java позволяетразрабатывать и выполнять в Mac OS X приложения и апплеты, соответствующиеспецификациям 100% «чистой» Java. Среда Java включает в себякомпилятор javac и полный набор утилит, среду выполнения — виртуальную машинуJava, базовый набор пакетов Java и компилятор байт-кода в коды целевойплатформы, пакеты awt и swing.
Среда Classicобеспечивает выполнение приложений Mac OS. В этой среде не обеспечиваютсясвойства, предоставляемые новым ядром ОС и интерфейсом Aqua. Эта среда неподдерживается прикладными службами непосредственно, следовательно, онаобеспечивает только выполнение приложений, но не их разработку.
Среда BSD выполняетпрограммы BSD из командной строки. Она обеспечивает shell и стандартный наборкоманд и утилит BSD. Эта среда базируется непосредственно на функциях ядра и неявляется обязательной для Mac OS X (может быть отменена при инсталляции).
Интерфейс Aqua
Интерфейс Mac OS Xназывается Aqua. В этой разработке фирма Apple вновь доказала, что она являетсялидером в продвижении дружественных графических интерфейсов. Aqua, с одной,стороны наследует интерфейсу Mac OS, а с другой,- предлагает новыефункциональные возможности и новый дизайн.
Среди новыхфункциональных возможностей Aqua можно назвать такие, как:
введение нового объекта,который называется Док (Dock — бассейн для стоянки кораблей), для отображенияиконок открытых приложений и минимизированных документов, его функциональностьотчасти та же, что и у Линейки Программ, но навигация в Доке гораздо болееудобна;
введение полотнищ (sheet)- диалогов, привязанных к своему окну, что позволяет сделать диалогинемодальными;
введение иерархии окон,облегчающей ориентацию в монгооконной среде;
возможностьмасштабирования иконок от максимального размера 128х128 до мини-иконок;
введение «выдвижныхящиков» (drawer), содержащих те управляющие элементы окна, в постояннойвизуализации которых нет необходимости;
использование анимациидля отображения изменения состояния элементов интерфейса;
расширение возможностейиспользования клавиатуры;
и т.д., и т.п.
Дизайн же новогоинтерфейса Mac OS X представляется почти революционным. Название нового интерфейсаотражает метафору, послужившую основой для внешнего вида интерфейса. Визображении повсеместно используется метафора воды с такими замечательнымсвойствами этой субстанции, как цвет, глубина, прозрачность, блики, движение.Кнопки выглядят как отполированные и блестящие цветные стеклышки, все объектыотбрасывают размытые тени, меню просвечиваются, диалоги полупрозрачны и т.д.Дизайнеры интерфейса смогли почувствовать и воплотить на экране туодухотворенность воды, которая на протяжении многих веков вдохновлялахудожников и поэтов. При этом, как это свойственно интерфейсам Apple,изобразительные средства ни в коей мере не мешают функциональности, а наоборот- подчеркивают и усиливают ее.
В настоящее фирмапредлагает компьютеры iMac, iBook, PowerBook, Server G4 на процессорах PowerMacпоколений G3 и G4 — от ноутбуков до профессиональных графических станций исерверов. Все компьютеры Apple работают под управлением ОС Mac OS X. Хотя фирмаApple далека от каких-либо претензий на господствующее положение на рынке, ееаппаратная и программная продукция — факт, с которым приходится считаться всемпроизводителям информационных технологий, претендующим на обеспечениесовместимости.
Глава 9. Операционнаясистема BeOS
9.1 Короткая история ипозиционирование системы
Операционная система BeOS[36] разработана фирмой Be Inc., созданной в 1990 г. Первоначально фирма производила также и собственные компьютеры BeBox на базе процессораAT&T Hobbit, однако компьютеры BeBox не утвердились на рынке, и сейчаскомпания специализируется на программном обеспечении BeOS и созданном на ееоснове пакете BeIA — интегрированном средстве работы в Internet.
Программное обеспечениеBe работает на платформах Intel-Pentium, PowerMac и PowerPC. Последним релизомBeOS является версия 5. BeOS v.5 для некоммерческого использованияраспространяется свободно.
В основу создания BeOSбыла положена концепция «молодой» ОС, которая не будет обремененамноголетним наследством и с самого начала будет построена с учетом некоторыхреалий современных подходов к обработке информации — прежде всегомультимедийной информации и Internet. Наверное, в начале истории BeOS еесоздатели имели «тайную мысль» создать универсальную ОС длянастольного применения. Но выходить на рынок с таким предложением былорискованно, поэтому для новой ОС была найдена «экологическая ниша», вкоторой, по крайней мере в то время, у BeOS опасных конкурентов почти не было.Этой нишей стала разработка и выполнение мультимедийных приложений. Ориентацияна мультимедиа была заложена в самые основы BeOS и продолжала развиваться вовсех последующих версиях. В ходе дальнейшего развития BeOS так и не удалосьвыйти из своей первоначальной экологической ниши. Основной причиной этого, какобычно, называют отсутствие на платформе BeOS достаточного числа известныхпользователям приложений. Более того, все более широкое обеспечениеуниверсальных ОС (прежде всего — Windows) мультимедийными приложениями создаетсерьезную конкуренцию для BeOS и в ее собственной нише. В настоящее время фирмаBe пытается внедриться в рынок Internet-вычислений, и эта ее попытка вполнеоправдана, так как роль мультимедийной информации в этой области весьма великаи продолжает расти.
Как раз в те дни, когдаписалась эта глава, на сайте компании Be появилось сообщение о том, что праваинтеллектуальной собственности на технологии Be куплены фирмой Palm Inc.Предполагается, что за этим последует полная интеграция Be Inc. в Palm.
Ориентация на мультимедианаложила определенный отпечаток на структуру BeOS. Подобно QNX, BeOS строитсяна базе микроядра и процессов-серверов. Независимые серверы в сочетании собъектно-ориентированной структурой системы обеспечивают для ОС гибкость ипростоту в наращивании функциональности.
Поскольку задачиобработки мультимедийной информации эффективно решаются методамираспараллеливания, в BeOS уделяется большое внимание эффективному использованиюмногопроцессорных конфигураций. Основной концепцией BeOS является«всепроникающая многопоточность» — возможность для приложенийсоздавать практически неограниченное число нитей и интенсивное использованиераспараллеливания на уровне нитей во всех сервисах самой ОС — в графическойсистеме, вводе-выводе, файловой системе. При работе на платформе PowerPC BeOSвполной мере использует обеспечиваемое аппаратурой процессора 64-разрядноеадресное пространство, что также существенно для мультимедиа.
BeOS обеспечивает APIPOSIX, однако нас интересуют прежде всего ее оригинальные системные интерфейсы.К сожалению, сколько-нибудь доступная информация о внутренней структуре BeOS непубликуется. Приводимые далее материалы в основном почерпнуты нами изинформации для разработчиков приложений. Однако и они позволяют делатьнекоторые выводы (пусть косвенные) об устройстве BeOS. Следует отметить, что посвоей структуре BeOS является объектно-ориентированной системой, поэтому в нейсуществует «двойная бухгалтерия» системных вызовов: они могутвыполняться через обращения к библиотечным функциям С — и так реализованыинтерфейсы POSIX, но могут выполняться также и через обращения к методамбиблиотечных объектов C++. Оба способа обеспечивают одинаковую функциональностьпрактически во всем.
9.2 Потоки и команды
BeOS являетсямногопоточной системой с несколько оригинальной концепцией распределения и разделенияресурсов. Ключевым понятием BeOS является нить. С точки зрения распределенияпроцессорного времени нить BeOS идентична нити в других системах: нить являетсясубъектом, для которого планируется процессорное время. Однако, понятияпроцесса в BeOS нет. Наиболее близким к нему является понятие команды (team).Команда представляет собой группу нитей, составляющих одно приложение. Призапуске приложения на выполнение (оператором или другим приложением) для негосоздается нить, составляющая новую команду, и в этой нити выполняется функцияmain(). Нить main может порождать другие нити. Все нити разделяют общееадресное пространство и используют общие глобальные для приложения переменные.
Новая нить порождаетсясистемным вызовом spawn_thread(), которому передается имя той функции, котораябудет выполняться в нити и указатель на блок параметров функции нити. Созданнаятаким образом нить еще не выполняется. Она может быть запущена на выполнениесистемным вызовом resume_thread() или wait_for_thread(). В первом случаенить-потомок выполняется асинхронно, то есть, параллельно с нитью, еепородившей. Второй случай — синхронный запуск, выполнение породившей нитиприостанавливается до завершения нити-потомка.
Мы говорим о нитях — родителе и потомке, однако на самом деле родственные отношения междупорождающей и порожденной нитью весьма слабы. Системный вызов spawn_thread()возвращает нити-родителю идентификатор нити-потомка, но не обеспечиваетнаследования никаких ресурсов, кроме общих для всей команды. Нити выполняютсянезависимо друг от друга, и выполнение нити-потомка продолжается даже послезавершения родительской нити. Теоретически, даже завершение нити, в которойвыполняется функция main(), не приводит к завершению всех порожденных ею нитей.Но именно нити main выделяются общие для всей команды статические объекты иресурсы ввода-вывода, так что завершение нити main скорее всего приведет каварийному завершению остальных нитей команды.
При создании нити ейможет быть дано имя. Другая нить, желающая обратиться к данной, независимо оттого, находится она в этой же команде или в другой, может использоватьсистемный вызов find_thread(), который по имени нити возвращает ееидентификатор. Но идентификатор нити является уникальным во всей системе, а имянити — не уникально. Вызов find_thread() возвращает идентификатор первойнайденной нити с таким именем. Поэтому более надежным способом полученияидентификатора нити является передача его нити-корреспонденту через глобальныепеременные, параметры, средства взаимодействия и т.п.
Все нити выполняютсяпараллельно, разделяя процессор (или процессоры) в соответствии с приоритетами.Приоритеты со значениями от 1 до 99 составляют класс приоритетов разделениявремени, приоритеты со значениями 100 и выше — класс приоритетов реальноговремени.
Приоритеты разделениявремени относительные — нити с такими приоритетами выполняются в режимеквантования времени с размером кванта 3 мсек. Приоритет определяет частотуполучения кванта нитью. Нить, получившая квант, использует процессор до исчерпанияею кванта или до перехода в ожидание по собственной инициативе, или допоявления нити с приоритетом реального времени. Нити разделения времени невытесняют друг друга.
Приоритеты реальноговремени абсолютные. Когда нить с приоритетом реального времени приходит всостояние готовности, она немедленно вытесняет с процессора нить с приоритетомразделения времени или нить с более низким приоритетом реального времени.
Приоритеты являютсястатическими: они задаются при создании нити и не изменяются в дальнейшем.
Нить может до некоторойстепени управлять своим планированием, переходя в состояние приостанова назаданный интервал времени (системный вызов snooze()) или завершаясь (системныйвызов exit_thread()).
Управление нитью «состороны» — из другой нити, которой известен идентификатор управляемой,возможно следующее:
нить может бытьприостановлена системным вызовом suspend_thread(), а затем вновь запущена навыполнение системным вызовом resume_thread() или wait_for_thread().
для запуска заблокированнойили «спящей» нити может быть использован системный вызов POSIXsend_signal(). Сигнал SIGCONT разблокирует нить.
системный вызовkill_thread() прекращает выполнение нити.
9.3 Средствавзаимодействия
При создании каждой нитидля нее создается буфер сообщения. Другая нить, знающая идентификаторнити-корреспондента, может записать в этот буфер сообщение системным вызовомsend_data(), а нить — владелец буфера выбирает сообщение системным вызовомrecive_data(). Однако буфер рассчитан только на одно сообщение, а попыткиписать данные в занятый буфер или выбирать данные из пустого буфера приводят кблокировке нити.
Более гибким средствомобмена данными между нитями является порт (port). Следует отметить, что порт неявляется прямым аналогом ни одного из средств взаимодействия процессов,рассмотренных нами в главе 9 части I. Порт представляет собой общесистемнуюочередь сообщений, работающую по дисциплине «первым пришел — первымвышел». В системе может быть создано сколько угодно портов. Любая нить излюбой команды, которой известен идентификатор порта, может записать в портсообщение (системный вызов write_port()) и прочитать из порта сообщение(системный вызов read_port()). При создании порта (системный вызовcreate_port()) задается его емкость — число сообщений, которое можетсохраняться в порте. Попытка писать в переполненный порт или читать из пустогопорта, естественно, приводит к блокировке нити. Однако, есть варианты системныхвызовов (write_port_etс() и read_port_etc()), которые к блокировке не приводят.Но система поддерживает общий репозиторий портов, емкость которого равнасуммарной емкости всех созданных портов, и переполнение происходит только призаполнении общей емкости.
Порт принадлежит команде,в которой он был создан. Однако, если идентификатор порта, возвращаемыйсистемным вызовом create_port(), передается в другую команду, эта другаякоманда также может использовать порт. Системный вызов delete_port() уничтожаетпорт, системный вызов close_port() закрывает порт для записи, но оставляет возможностьпрочитать сообщения, еще остающиеся в порте. Порт автоматически уничтожается,когда завершается последняя нить команды, в которой он был создан. Однакосоздавшая порт команда может передать право владения портом другой командесистемным вызовом set_port_owner().
Еще раз подчеркнем, чтопорт является только FIFO-очередью, и никаких средств неразрушающего чтения изпорта не существует.
Семафоры в BeOSпредставляют собой традиционные общие семафоры. Семафор создается системнымвызовом create_sem(), системные вызовы acquire_sem() и release_sem()обеспечивают традиционные семафорные операции P и V соответственно. Начальноезначение семафора задается при его создании, но значение семафора может ипревысить начальное, если операции release_sem() выполняются чаще, чемacquire_sem(). Семафор принадлежит той команде, в которой он был создан, иавтоматически уничтожается с завершением последней нити этой команды. Явнымобразом семафор может быть уничтожен системным вызовом delete_sem().Идентификатор семафора, который был возвращен вызовом create_sem(), может бытьпередан в другую команду, но право владения семафором не передается.
9.4 Управление памятью
В части управленияпамятью BeOS обеспечивает сегментную модель для приложений, однако, в ней«просматривается» сегментно-страничная реализация. Любая нить можетзапросить выделение для нее области (area) памяти. Область представляет собойнепрерывный участок виртуальной памяти, размер которого задается в системномвызове create_area(). Размер области должен быть кратен размеру страницы (4Кбайт). Операция создания области возвращает ее адрес в виртуальном адресномпространстве команды. При создании области нить может явно задать адрес в своемвиртуальном адресном пространстве, по которому область должна быть размещена,но адрес размещения области обязательно выравнивается по границе страницы.Кроме того, при создании каждой новой области ей присваивается уникальный вовсей системе идентификатор. Этот идентификатор может использоваться в вызовеdelete_area() или передаваться другим командам для совместного использованияобласти.
Области также может бытьприсвоено имя. Системный вызов find_area() возвращает идентификатор области сзаданным именем. Однако, как и в случае с нитями, имя области не являетсяуникальным, и системный вызов find_area() возвращает идентификатор толькопервой найденной области.
В пределах одной командывсе нити «видят» созданную область по одному и тому же виртуальномуадресу. При совместном использовании области двумя и более командами, команда,не являющаяся владельцем области, должна получить ее идентификатор и«клонировать» область при помощи системного вызова clone_area().Параметром этого вызова является идентификатор области, а возвращает онвиртуальный адрес области. Этот адрес может отличаться от виртуального адресаобласти в той команде, в которой область была создана. Клонирование области,однако, не означает дублирования ее данных. Оно просто задает отображениеучастков виртуального адресного пространства разных команд на одну и ту жереальную память. Изменения в содержимом области, сделанные одной командой,будут немедленно видны в другой команде.
Область явно уничтожаетсясистемным вызовом delete_area() или неявно — при завершении всех нитей команды,в которой область была создана. Если, однако, область была клонирована, то еереальное освобождение происходит при уничтожении (явном или неявном) еепоследнего клона.
При создании иликлонировании области можно сделать ее защищенной от записи или защищенной отчтения.
При создании областиможно также зафиксировать ее в реальной памяти, при этом имеются возможности:
выделить для областифизическую память немедленно и исключить ее из страничного обмена;
выделять для областифизическую память постранично, по требованию и выделенные страницы исключать ееиз страничного обмена;
выделить для областифизическую память немедленно, причем в непрерывной области реальной памяти, иисключить ее из страничного обмена.
9.5 Образы
Программные коды, готовыедля выполнения, называются в BeOS образами (image). Различаются три видаобразов:
образы приложений;
библиотечные образы;
дополнительные (add-on)образы.
Образы приложенийявляются загрузочными модулями программ. Для их загрузки и связыванияприменяется системный вызов load_image(). Параметром вызова является имя файла,из которого загружается образ приложения. Этот вызов в чем-то подобен вызовуspawn_thread(). Он также создает новую нить. В этой нити будет выполнятьсяфункция main() приложения. Но этот вызов создает также и новую команду,«возглавляемую» нитью main запускаемого приложения, а следовательно,и новое виртуальное адресное пространство и другие общекомандные ресурсы. Как иspawn_thread(), load_image() возвращает идентификатор нити. Созданная такимобразом нить должна быть запущена на выполнение теми же системными вызовамиresume_thread() или wait_for_thread().
Библиотечные образыявляются модулями динамической компоновки, подключение (связывание) которыхпроисходит автоматически при загрузке приложения. Библиотечные образы используютсясовместно всеми приложениями.
Дополнительные образытакже являются совместно используемыми модулями динамической компоновки. Но ихзагрузка и связывание происходят по требованию, уже в процессе выполненияприложения. Загрузка такого модуля выполняется при помощи системного вызоваload_add_on(), которому передается имя файла, содержащего дополнительный образ.Вызов load_add_on() возвращает идентификатор загруженного образа, который далееможно использовать в качестве параметра системного вызова get_image_symbol(),чтобы получить адреса внешних символов и входных точек дополнительного образа.
С точки зрения форматадополнительные образы ничем не отличаются от библиотечных. В параметрахсистемного окружения отдельно задаются каталоги, из которых загружаютсябиблиотечные и дополнительные образы. Манипулируя этими параметрами, можносделать так, что образ, к одному приложению подключаемый при загрузке, длядругого будет дополнительным.
9.6 Устройства и файловыесистемы
Драйверы в BeOS являютсярасширениями ядра системы и могут работать в адресном пространстве ядра. Всистеме различаются три вида драйверов:
драйверы устройств;
драйверы файловых систем;
модули.
Последние являютсявспомогательными программными единицами, выполняющими некоторый общий сервис,необходимый для всех или нескольких драйверов устройств (например, управлениешиной SCSI). Если первые два вида драйверов доступны для пользовательскихприложений через API, то модули полностью скрыты от пользователей и вызываютсятолько из других драйверов.
Обращения к драйверам изприложений выполняются через API POSIX (open(), read(), write() и т.д.).Перевод API POSIX во внутренние системные вызовы ядра BeOS осуществляет«файловая система устройств» devfs. Для того, чтобы драйвер былдоступен для devfs, он должен быть записан (опубликован) в соответствующемкаталоге иерархической файловой системы.
К сожалению, нам неудалось найти исчерпывающей информации о файловой системе BeOS, но даже танеполная информация, которую нам удалось получить, представляет существенныйинтерес.
Первая файловая системаBeOS не имела иерархической структуры. Вместо этого логическая структурафайловой системы поддерживалась «базой данных файлов». Навигация пологической структуре осуществляется средствами, напоминающими средства,принятые в реляционных базах данных — запросами. Поиск файла выполняетсязапросом, содержащим предикат (иногда довольно сложный), проверяющий значениеодного или нескольких атрибутов файла. Хотя бы для одного из атрибутов,участвующих в предикате, должен быть создан индекс. Наряду с запросами,формулируемыми при каждом обращении, в системе существуют и «постоянноживущие» запросы — аналоги представлений (view) в реляционных базахданных. Подобно представлению, постоянный запрос представляет собой незафиксированную выборку, а зафиксированный предикат, выборка же при каждомобращении выполняется заново. Постоянные запросы представляют собойфункциональный аналог каталогов в иерархической файловой системе.
В 1997 г. для BeOS была разработана новая файловая система — BFS. В ней была введена иерархическаяструктура файловой системы и логическая структура в значительной степениинтегрировалась с физической структурой хранения. Однако наряду с иерархическойлогической структурой BFS поддерживает и индексирование по именам и другиматрибутам файлов и, таким образом, в полном объеме сохраняется возможностьальтернативной «реляционной» навигации по файловой системе.
Единицей распределениядискового пространства является блок, размер блока выбирается из ряда: 512байт, 1 Кбайт, 2 Кбайт, 4 Кбайт, 8 Кбайт. Файл состоит из одного или несколькихэкстентов, каждый экстент — целое число последовательных блоков. Планразмещения файла представляет собой массив описателей экстентов. Каталогиструктурированы в виде B+-деревьев. Дескрипторы файлов и элементы каталоговразделены, но несмотря на это, BFS не поддерживает «жесткие» связи(алиасы), а только «мягкие» связи (косвенные файлы). В дескрипторефайла хранятся основные его атрибуты, расширенные же атрибуты хранятся вместе сданными файла.
С введением BFS былавведена и концепция виртуальной файловой системы, обеспечивающая для BeOSвозможность работы с файловыми системами различных форматов (CDFS и HFS отMacOS). Ядром BeOS формируется корневой каталог виртуальной файловой системы, вкотором не могут находится файлы, а только подкаталоги и «мягкие»связи. Другие физические файловые системы монтируются как подкаталоги корневогокаталога. Ряд подкаталогов и связей монтируются в корневой каталогавтоматически, при загрузке системы. Также автоматически монтируются и еще двевиртуальные файловые системы: /dev — виртуальная файловая система устройств и/pipe — виртуальная файловая система программных каналов.
Некоторые другиеинтересные свойства BFS также определяются спецификой этой файловой системы:
64-разрядный размер файла- важное обстоятельство, если учесть то, что многие файлы в BFS содержатмультимедийную информацию;
использованиемногопоточности в работе самих модулей BFS — в соответствии с общей концепциейвсей BeOS;
журналирование — свойство, которое может показаться роскошью для настольной ОС, но в BFS оносовершенно необходимо для сохранения целостности при сбоях базы данных файлов.
Интересен способ, которыйиспользует BeOS для определения типа файла, а следовательно, и приложения, поумолчанию связываемого с визуализацией и обработкой этого файла. В атрибутахфайла обеспечивается идентификация типа в соответствии со спецификациями MIME(Multipurpose Internet Mail Extensions). Наряду со стандартными типами MIME,BeOS применяет также и собственные типы, не предусмотренные в MIME, ноопределяемые также в формате спецификации MIME. При отсутствии у файлаMIME-специфицированных атрибутов для определения типа используется расширениефайла, и BeOS ведет собственную «базу типов файлов», которыеопределяют связанные с типом-расширением приложения. BeOS также представляетпользователю возможность назначать собственные интерпретации типа для каждогофайла или группы файлов.
Глава 10. Операционнаясистема QNX
10.1 Архитектура
Операционная система QNX[32] производится компанией QNX Software Systems Ltd. с 1980 г. В настоящее время существует версия 6.1 системы. Для нас ОС QNX представляет особый интерес подвум причинам: во-первых, это ОС реального времени, во-вторых, это ОС,построенная на концепции микроядра «в чистейшем виде». Как следствиеэтого, QNX — легко масштабируемая система
Архитектура ОС QNXпоказана на рисунке 10.1.
/>
Микроядро QNX имеетминимальный размер (всего 8 Кбайт), и в нем сосредоточены все операции,выполняемые в режиме ядра. Ядро не имеет процессов, его модули всегдавыполняются в контексте процесса, их вызвавшего. Модули, сосредоточенные вмикроядре, выполняют следующие основные функции:
планирование ипереключение процессов и управление реальной памятью (планировщик);
первичную обработкупрерываний и перенаправление их адресатам (редиректор прерываний);
обеспечение связей междупроцессами (средства взаимодействия);
сетевые взаимодействия(сетевой интерфейс).
Все эти функцииаппаратно-зависимые и/или требуют высокой эффективности в реализации. Другиефункции ОС обеспечиваются системными процессами-менеджерами, которые, однако,выполняются в пользовательском режиме и с точки зрения микроядра ничем неотличаются от процессов пользователей. Типичные конфигурации ОС QNX включают всебя следующие системные процессы:
менеджер процессов(Proc);
менеджер файловой системы(Fsys);
менеджер устройств (Dev);
сетевой менеджер (Net).
Микроядро QNX выполняетвсего 57 системных вызовов, однако процессы-менеджеры ОС обеспечиваютвыполнение большого числа других системных вызовов, что позволило ОС QNXполучить сертификат POSIX. Таким образом, ОС QNX может считаться Unix-подобнойсистемой, хотя ее внутренняя структура далека от традиционной структуры ОСUnix.
10.2 Управлениепроцессами
Порождение и планированиепроцессов обеспечивается менеджером процессов совместно с планировщиком вмикроядре. Менеджер процессов выполняет порождение новых процессов, загрузку изавершение процессов. Для создания процессов имеются системные вызовы fork() иexec(), традиционные для Unix, а также spawn() — создание процесса-потомка свыполнением в нем новой программы.
QNX различает процессы,находящиеся в следующих состояниях:
готовые ( среди них — иактивный процесс);
ожидающие (6 подвидов — взависимости от причин ожидания)
мертвые (ужезавершившиеся, но не передавшие информации о своем завершении).
Планирование процессов вQNX выполняется по абсолютным приоритетам, то есть, появившийся илиразблокированный процесс с более высоким приоритетом вытесняет активный процесснемедленно. При наличии в состоянии готовности нескольких процессов с одинаковымвысшим приоритетом разделение процессора между ними выполняется по одной издисциплин на выбор:
FCFS;
RR;
динамическое изменениеприоритета.
В последнем случаеизменение приоритета производится по таким правилам:
если активный процессполностью исчерпал квант времени и есть еще процессы с таким же приоритетом,приоритет активного процесса уменьшается на 1;
если процесс пробыл вочереди готовых процессов, не получая обслуживания на процессоре, 1 сек, егоприоритет увеличивается на 1.
Всего в системе имеется32 градации приоритетов.
В отличие от другихсистем, в которых процессы реального времени получают наивысший приоритет (вущерб всем другим процессам), в QNX обеспечение работы в реальном временисостоит в том, что всем процессам обеспечивается высокая реактивность. То есть,если происходит какое-либо событие (прерывание), требующее выполненияопределенного процесса, требуемый процесс становится активным после самойминимальной задержки. Реактивность обеспечивается за счет высокой реентерабельностимодулей микроядра (то есть, возможности прервать выполнение модуля) и высокойэффективности средств взаимодействия процессов.
Внешнее событие вызываетпрерывание. Для обеспечения высокой реактивности прерывание должнообрабатываться немедленно. Но обработка прерывания может быть отложена последующим причинам:
выполняется обработкапрерывания с более высоким приоритетом;
выполняетсянереентерабельный код микроядра (при этом обработка прерывания запрещается).
Если первый вид задержекявляется объективным и оправданным, то второй является нежелательным. В QNXмодули микроядра тщательно оптимизированы с целью минимизации размера участковнереентерабельного кода. В результате модули микроядра также являютсяпрерываемыми почти в любом месте. Участки кода с запрещенными прерываниямисоставляют в среднем всего 9 команд на входе в модуль микроядра и 14 команд — на выходе из модуля.
10.3 Средствавзаимодействия
ОС QNX обеспечивает (науровне микроядра) три средства взаимодействия процессов: сигналы, сообщения ипоручения (proxy).
Механизм сигналовсоответствует тому, который мы рассмотрели в разделе 9.2 части I. QNX работаетс большим количеством типов сигналов, среди которых:
стандартные сигналы,определяемые POSIX;
сигналы, управляющиеработой процессов;
специальные сигналы QNX;
сигналы, поддерживающиестарые версии Unix.
Процесс может определятьспособы обработки некоторых (но не всех) сигналов.
Сообщения являютсяосновным способом взаимодействия между процессами в QNX. В отличие от того смысла,который мы вкладывали в этот термин в разделе 9.7 части I, в QNX сообщенияявляются синхронными, то есть процесс, пославший сообщение, требуетобязательного ответа на него.
Обмен сообщениямиобеспечиваются вызовами микроядра:
Send() — посылка сообщения:
Recive() — приемсообщения;
Reply() — посылка ответа.
На рисунке 10.2 показансценарий взаимодействия процессов при посылке сообщения
/>
Рисунок 10.2 Сценарийвзаимодействия процессов при посылке сообщения
В соответствии спротоколом передачи сообщений различаются следующие подвиды блокировкипроцесса:
SEND-блокированныйпроцесс — послал сообщение и ожидает подтверждения его приема.
REPLY-блокированныйпроцесс — получил подтверждение приема и ожидает получения ответа.
RECIVE-блокированныйпроцесс — запросил прием сообщения и ожидает его поступления. На рисунке 10.2состояние RECIVE-блокировки не показано, в него мог бы попасть Процесс B, еслибы выполнил системный вызов Recive() прежде, чем Процесс A выполнил Send().
Модель сообщений QNXболее всего напоминает взаимодействие процессов по принципу рандеву (см. раздел8.11 части I), описываемую как:
A!x; ?y
Для взаимодействияпроцессов необходима «встреча» готовности одного процесса (ПроцессаA) передать сообщение и готовности другого процесса (Процесса B) принятьсообщение. При этом для процессов, участвующих в рандеву, нет необходимостизнать о готовности процесса-корреспондента. Процесс, первым пришедший в точкурандеву, просто блокируется (SEND- или RECIVE-блокировкой) до готовностипроцесса-партнера.
Передача ответаподтверждения не требует, и выполнение вызова Reply() не приводит к блокировкепроцесса, выполнившего этот вызов.
При необходимости процессможет посылать сообщения нулевой длины и/или ответы нулевой длины — такиеприемы применяются для взаимного исключения и синхронизации без обмена данными.
Несколько процессов могутпослать сообщения одновременно одному адресату. В этом случае сообщения могутобрабатываться (получаться адресатом) либо в порядке их поступления, либо всоответствии с приоритетами отправителей.
Еще один вызов микроядра-Crecive() — позволяет процессу проверить наличие сообщений для него и, такимобразом, избежать RECIVE-блокировки.
Интересно, что, используямеханизм сообщений-рандеву, библиотеки системных вызовов QNX обеспечиваютинтерфейсы других стандартных средств взаимодействия процессов, таких какпрограммные каналы или семафоры.
Третий вид взаимодействия- поручения — обеспечивает асинхронное взаимодействие процессов. Фактическипоручения идентичны очередям сообщений, описанным нами в разделе 9.7 части I.
10.4 Файловая система
Администратор файловойсистемы ОС QNX позволяет стандартным образом организовать хранение и доступ кданным файловых подсистем (томов). С точки зрения логической файловой системы,хранение файлов в QNX подобно тому, какое обеспечивает ОС Unix: общее деревокаталогов с возможностью монтирования новых томов как ветвей этого общегодерева. Обеспечиваются также «жесткие» и «мягкие» связи.
На физическом уровне дискQNX структурирован так, как показано на рисунке 10.3.
/>
Рисунок 10.3 Структурадиска QNX
Загрузчик представляетсобой блок начальной загрузки. Он не осуществляет загрузку собственно ОС, авыполняет выбор загрузочного файла ОС.
Корневой блок имеетструктуру каталога и содержит информацию о следующих специальных файлах:
файл с именем / — корневой каталог;
файл с именем /.inodes — файл файловых индексов;
файл с именем /.boot — загрузочный файл ОС;
файл с именем /.altboot — альтернативный загрузочный файл ОС.
Загрузчик загружаетоперационную систему из файла /.boot, но имеется возможность загрузки и изальтернативного файла.
Битовая карта содержитинформацию о свободных блоках на диске. Свободному блоку соответствует бит созначением 0, занятому — 1.
Размещение файла на дискеQNX показано на рисунке 10.4.
/>
Рисунок 10.4 Размещениефайла на диске QNX
Единицей распределениядискового пространства является блок (512 байт). Пространство файлу выделяетсяэкстентами — непрерывными последовательностями, состоящими из целого числаблоков. В элементе каталога, соответствующем файлу, содержится номер начальногоблока и размер для первого экстента файла. Если файлу выделено более одногоэкстента, то в элементе каталога содержится номер блока расширения, черезкоторый адресуются следующие экстенты файла. Если одного блока расширениянедостаточно, последний элемент первого блока расширения адресует второй блокрасширения и т.д.
Интересным образомобеспечиваются в QNX жесткие связи (алиасы). Показанная на рисунке 10.4структура относится к файлу, не имеющему жестких связей. Если же для файласоздается жесткая связь, то информация о размещении файла переносится вфайловый индекс, находящийся в файле /.inodes. Элемент каталога в этом случаесодержит номер файлового индекса, и два разных элемента каталога могутссылаться на один и тот же файловый индекс, а следовательно, на один и тот жефизический файл. Таким образом, файловый индекс для файла создается толькотогда, когда нужно разделить информацию о хранении файла в логической и вфизической файловых системах.
Файловый индекс создаетсятакже и для файла с длинным именем. В обычном элементе каталога предусмотреноместо для 16-символьного имени файла. Если длина имени файла превышает 16символов, для файла создается файловый индекс и информация о размещении файлапереносится в файловый индекс. При этом в элементе каталога освобождается местоеще для 32 символов имени, таким образом, длина имени файла может достигать 48символов.
10.5 Управлениеустройствами
Интерфейс междупроцессами и устройствами обеспечивается менеджером устройств. Устройствавключены в общее пространство имен файловой системы как специальные файлы,находящиеся в подкаталоге \.dev. Для процесса устройство представляется какдвунаправленный поток байтов. Менеджер устройств управляет прохождением этогопотока между процессом и устройством и отчасти осуществляет обработку данных впотоке. С каждым устройством связан блок управления termios, в котором задаютсяпараметры обработки данных, такие как:
алгоритм передачи данных(скорость, контроль четности и т.д.);
отображение символов,вводимых с клавиатуры, на экране;
трансляция вводимыхсимволов;
программное и аппаратноеуправление потоком данных;
и т.д., и т.п.
Данные, которымиобмениваются менеджер устройств и драйвер, проходят через набор очередей, скаждым устройством связаны по три очереди:
входная очередь;
выходная очередь;
так называемая,каноническая очередь — очередь ввода данных с редактированием.
Общий размер всех трехочередей не превышает 64 Кбайт. Очереди обслуживаются по дисциплине FIFO,независимо от приоритетов процессов, которым принадлежат данные в очередях. Дляобеспечения высокой эффективности ввода-вывода сам менеджер устройстввыполняется как процесс с высоким приоритетом. Это не сказывается набыстродействии других процессов, так как управление вводом-выводом никогда незанимает процессор надолго. Драйверы также выполняются как отдельные процессы,их приоритеты зависят от особенностей обслуживаемых ими устройств.
Вводимые данныепомещаются драйвером во входную очередь. Менеджер устройств выбирает данные изэтой очереди только тогда, когда процесс запрашивает данные. Выходные же данныеменеджер устройств помещает в выходную очередь и немедленно же активизируетдрайвер.
Запрос данных при пустойвходной очереди приводит к блокировке процесса. Также блокируется процесс итогда, когда пытается вывести данные при переполненной выходной очереди.
10.6 Сетевыевзаимодействия
С самого начала QNXсоздавалась как сетевая ОС и это выражается прежде всего в том, что средствавзаимодействия локальных и удаленных процессов в QNX одни и те же — сообщения.Процесс не видит разницы во взаимодействии с локальным или удаленнымкорреспондентом. Такое свойство обеспечивается при помощи «виртуальныхканалов», показанных на рисунке 10.5.
/>
Рисунок 10.5 Посылкасообщения через виртуальный канал
Виртуальный каналсоздается процессом-отправителем сообщения При этом на узле отправителя и наузле получателя создаются виртуальные процессы, каждый из которых представляетна локальном узле идентификатор процесса — удаленного корреспондента. Реальныйпроцесс имеет реальный идентификатор (PID), виртуальный процесс — виртуальныйидентификатор (VID). VID обеспечивает соединение, которое содержит следующуюинформацию:
локальный PID;
удаленный PID;
удаленный NID(идентификатор узла сети);
удаленный VID.
Процессы QNX имеютсимвольные имена, причем эти имена могут быть глобальными, доступными во всейсети. Приложение может по имени получить PID процесса — удаленногокорреспондента. При этом система автоматически создает виртуальный канал и дляприложения этот канал отождествляется с PID корреспондента.
Администратор сетиобеспечивает создание виртуальных каналов, буферизацию данных в канале иконтроль целостности виртуальных каналов.
10.7 Графическая системаPhoton
Пользовательскийинтерфейс QNX строится на базе графической системы Photon. Структураграфической системы представляет для нас интерес прежде всего потому, что онаследует общим архитектурным концепциям QNX. Это обстоятельство делаетграфическую систему нетребовательной к ресурсам, легко масштабируемой — отинтерфейса встроенного или карманного мобильного устройства до полнофункциональногоWIMP-интерфейса. Это обеспечивает также то, что возможные сбои графическойсистемы не оказывают влияния на работоспособность всей ОС и требуют толькоперезапуска отказавшего компонента.
В отличие от другихграфических систем, которые обеспечивают функции графического интерфейса вмонолитной (Windows) или клиент/серверной (X Window) модели, Photon строится набазе компактного графического микроядра и распределения графическойфункциональности между взаимодействующими процессами. Архитектура графическойсистемы показана на рисунке 10.6, и она очень похожа на архитектуру QNX вцелом.
/>
Рисунок 10.6 Архитектураграфической системы Photon
Микроядро Photon, котороеявляется процессом QNX, выполняет необходимый минимум графических функций.Микроядро Photon занимает всего 55 Кбайт памяти. Прочие части графическойсистемы — также процессы, которые для выполнения базовых функций обращаются кмикроядру Photon, используя средства взаимодействия, обеспечиваемые микроядромQNX. Менеджеры графической системы являются опционными, включение новыхменеджеров расширяет функции системы. До некоторой степени ключевымкомпонентом, определяющим переход от интерфейса встроенной системы к WIMP-интерфейсу,является менеджер окон, который обеспечивает изменение размера, минимизацию,перемещение и т.д. для окон.
Работа системы Photonстроится на концепции «трехмерного пространства событий», котораяиллюстрируется на рисунке 10.7.
/>
Рисунок 10.7. Движениечерез пространство событий
Событиями в системеявляются как события, инициируемые пользователем (мышью, клавиатурой), так исобытия, инициируемые процессами. Пространство, через которое движутся события,представляется как набор параллельно размещенных прямоугольных областей.Метафорой, давшей название системе, является движение частицы света (фотона)через ряд стеклянных пластин. На одном конце этого ряда находится корневаяобласть, создаваемая системой, на другом конце — та область, котораяпредставляется пользователю. Процесс, который выполняет какие-либо функции,связанные с интерфейсом, помещает свою область в этот ряд. Каждая область имеетдве маски для проходящих через нее событий: маску чувствительности и маскунепрозрачности. Установка бита чувствительности для определенного событияопределяет передачу события для обработки процессу, связанному с областью.Установка для события бита непрозрачности определяет прекращение движениясобытия через пространство. Графические драйверы являются процессами, которыепомещают свои области на переднем (ближнем к пользователю) краю ряда. Этообеспечивает также возможность распределенной обработки в сети: приложение сграфическим интерфейсом может работать в одном узле сети, а результат егоработы отображаться на другом узле. Физический драйвер целевого узел простопомещает свою область на переднем краю пространства событий. Подобным образомобеспечивается и отображение результатов работы приложений QNX в другихграфических системах: вместо драйвера в пространство событий вставляетсяобласть переходника в систему Windows или X Window.
Глава 12. Операционныесистемы мейнфреймов
12.1 История иархитектура мейнфреймов
Обычно на русский язык термин«мейнфрейм» переводится как «большая ЭВМ универсальногоназначения». Однако нам представляется, что в настоящее время такоеопределение уже не является точным. Современные мейнфреймы не универсальны. Ониспециализированы как компьютеры для обработки больших и сверхбольших объемовданных или как суперсерверы. Название одного из поколений мейнфреймов IBM ESA(Enterprise System Architecture — архитектура систем масштаба предприятия)достаточно точно отражает такую специализацию
Мейнфреймы фирмы IBM [7] имеютпочти 40-летнюю историю развития, причем, развитие это протекало эволюционно,во всяком случае, с точки зрения пользователей. При любых изменениях ваппаратной архитектуре каждое следующее поколение мейнфреймов обеспечиваловыполнение программного обеспечения, разработанного для предшествующихпоколений, почти в полном объеме.
За время существованиямейнфреймов неоднократно высказывались и приобретали широкую популярностьзаявления об их устаревании и скорой кончине, однако, всегда «эти слухиоказывались несколько преувеличенными», и мейнфреймы продолжалисуществовать и развиваться. В настоящее время в технологиях обработкиинформации возрастает потребность в существенно централизованных решениях, иновое поколение мейнфреймов оказывается востребованным, как никогда раньше.
Семейство мейнфреймов IBMSystem/360, появившееся в начале 60-х годов, стало значительной вехой в историивычислительной техники. Во-первых, это были первые ЭВМ, которые началивыпускаться серийно, а не по индивидуальным проектам, во-вторых, они сталипервым семейством ЭВМ, то есть набором моделей с разной производительностью иразной стоимостью, но с переносимостью программного обеспечения с одной моделина другую. Семейство IBM System/360 строилось на базе CISC-процессоров с богатымнабором команд и несколькими режимами адресации. Эти процессоры, однако, неподдерживали динамическую трансляцию адресов, поэтому программное обеспечениеработало с реальной памятью, привязка адресов осуществлялась при загрузке.(Точнее — во время выполнения, в момент загрузки «базовых» регистров,но загруженная в реальную память программа уже не могла быть перемещена.)Размер адресной шины составлял 24 бит, что позволяло адресовать 16 Мбайт памяти- реальной и виртуальной. Чрезвычайно сильным свойством IBM System/360 явиласьархитектура каналов ввода-вывода [8] (см. главу 6 части I). Достоинствамейнфреймов IBM System/360 определили ведущее положение этого семейства нарынке вычислительной техники в течение всех 60-х и начала 70-х годов, и первоевремя конкуренты IBM, вынуждены были делать собственные компьютеры программносовместимыми с IBM System/360.
Следующим поколениеммейнфреймов стало семейство IBM System/370. Принципиальным отличием его отпредыдущего поколения явилось введение динамической трансляции адресов.Применялась сегментно-страничная модель трансляции, во всех ОС этого поколениякаждому процессу выделялся один сегмент адресного пространства (АП), то есть,процесс обладал собственной виртуальной памятью размером в 16 Мбайт. Однако вэтом поколении проявилось некоторая «успокоенность» фирмы IBM. Фирмаупустила из виду одно из конкурирующих направлений развития вычислительнойтехники, а именно — мини-ЭВМ, так называемые, Unix-машины, ведущимпроизводителем которых в то время была фирма Digital Equipment. Нововведенийсемейства IBM System/370 оказалось недостаточно, чтобы сохранить почтимонопольное положение на рынке, и именно тогда возникла первая «легенда осмерти мейнфреймов».
Отличие семейства IBMSystem/370/XA (eXtended Architecture — расширенная архитектура) от предыдущегопоколения было достаточно революционным: адресная шина расширилась до 31 бита,что позволило адресовать виртуальную память до 2 Гбайт (при этом сохраниласьсовместимость и со старыми 24-разрядными моделями). Другим принципиально важнымнововведением расширенной архитектуры явилось введение в подсистемуввода-вывода возможности динамического определения пути к устройствамввода-вывода и поддержка SMP-архитектуры.
Следующим поколениемстало семейство IBM ESA/370. В этом семействе появилась возможность адресоватьдо 16 2-Гбайтных виртуальных АП. Важнейшим из других возможностей, по-видимому,явилось свойство PR/SM (Partition Resources/System Management), обеспечивающеевозможность разбиения (на микропрограммном уровне) ресурсов вычислительнойсистемы на независимые логические разделы. Семейства 370/XA и ESA/370определили новую специализацию мейнфреймов, однако еще не вывели фирму IBM вабсолютные лидеры.
Дальнейшее развитиемейнфреймов происходило во многом благодаря конкуренции IBM с японскими фирмами(Hitachi, Fujitsu), выпускающими собственные мейнфреймы, программно совместимыес IBM. Новое семейство — IBM ESA/390 интегрировало в себе большое количествонововведений, которые в итоге определили «второе рождение» мейнфреймов.Среди этих нововведений — увеличение регистрового массива, новые средствазащиты памяти, новые средства работы с числами с плавающей точкой,оптоволоконные ESCON-каналы, встроенные криптографические процессоры иаппаратная поддержка сжатия данных и, конечно, sysplex — средствокомплексирования вычислительных систем. В этом семействе произошел такжепереход мейнфреймов на CMOS-технологию, что привело к тому, что по размерам ипо энергопотреблению они стали сравнимы даже с ПЭВМ.
Семейство ESA/390 прочновосстановило позиции мейнфреймов в мире информационных технологий, нодальнейшее развитие требований к обработке данных повлекло за собой и появлениенового семейства мейнфреймов — z/900 [40]. Главная особенность новойархитектуры — расширение адресной шины до 64 разрядов. Для пониманияфункционирования программного обеспечения и ОС мейнфреймов мы приведемнекоторые минимальные сведения об аппаратной части z-архитектуры. На рисунке12.1 показана логическая структура современного мейнфрейма, так называемогоz-сервера.
/>
Рисунок 12.1 Логическаяструктура z-сервера
Основные вычислительныесвойства реализуются на симметричной многопроцессорной (до 16 z-процессоров)конфигурации. Однако реально процессоров может быть и больше, так какконфигурация может включать в себя, помимо основных z-процессоров,специализированные сервисные процессоры, криптографические процессоры,процессоры ввода-вывода и т.д. Z-процессор, как и все предыдущие поколенияцентральных процессоров мейнфреймов, является CISC-процессором. Свойства CISCиспользуются в этой архитектуре в полной мере. Обязательной составной частьюz-архитектуры является Лицензионный Внутренний Код (LIC), реализованный науровне микропрограмм процессора. Интенсивное использованиемикропрограммирования позволяет включить в систему команд процессора оченьмощные команды, обеспечивающие значительную поддержку работы операционныхсистем и даже конкретных приложений. Одно из различий в моделях z-процессоровсостоит в том, реализованы те или иные команды в них аппаратно (в болеепроизводительных моделях) или микропрограммно.
Основной аппаратнойструктурой, в которой фиксируется состояние процессора, является 16-байтноеСлово Состояния Программы (PSW — Program State Word). В нем отражается адресвыполняемой команды, состояние задача/супервизор, режим адресации и т.п.Дополнительная информация о состоянии содержится еще в 16 8-байтных управляющихрегистрах. В системе имеется 16 8-байтных регистров общего назначения (парасмежных таких регистров может использоваться для представления 16-байтногозначения) и 16 16-байтных регистров плавающей точки.
Система имеет основную(оперативную) и расширенную память. Команды и обрабатываемые данные находятся воперативной памяти. Расширенная память является необязательным компонентомсистемы. Она используется как дополнительный буфер между оперативной и внешнейпамятью. Данные могут перемещаться между основной и расширенной памятьюпостранично — командами PAGE IN и PAGE OUT.
В z-процессоре адресимеет размер 64 бита, что позволяет работать с адресным пространством (АП)размером 16 эксабайт, однако процессор поддерживает и «старые» режимыадресации — с 31-битным и 24-битным адресом (режим определяется состоянием соответствующихразрядов PSW).
В системе адресацииразличаются адреса: абсолютные, реальные и виртуальные адреса нескольких типов.
Абсолютный адрес — адресв реальной памяти, фактический адрес ячейки памяти.
Реальный адрес, какправило, совпадает с абсолютным, кроме реальных адресов, меньших 8 Кбайт.Реальный адрес, меньший 8 Кбайт, преобразуется в абсолютный путем префиксации — добавления к нему значения, записанного в префиксном регистре. Область реальнойпамяти до 8 Кбайт используется для специальных целей системой прерываний иввода-вывода, префиксация обеспечивает для каждого процессора вмногопроцессорной системе собственную область младших адресов памяти.
Виртуальные адресаразличаются четырех типов: первичные, вторичные, домашние и определяемыерегистрами доступа. Для виртуальных адресов разного типа по-разному выполняетсядинамическая трансляция адреса. Режим динамической трансляции задаетсяопределенными битами PSW и управляющих регистров. В зависимости от режима, впроцессе динамической трансляции адресов используются от двух до пятиуправляющих таблиц переадресации (3 таблицы областей, таблица сегментов,таблица страниц). В системе имеется также 16 AR-регистров (регистры доступа).Регистр AR0 содержит указатель на таблицы переадресации для первичного АП.Регистры AR1-AR15 позволяют приложению адресовать еще 15 дополнительных АП.
Защита памяти вмейнфреймах z-архитектуры включает в себя традиционную для многих компьютерныхсистем изоляцию АП виртуальной памяти, бит защиты от выборки, бит обращения ибит изменения в дескрипторах страниц, а также предусматривает механизм,основанный на применении ключей защиты памяти. Такой ключ приписывается каждой4-килобайтной странице. В дескрипторе каждого страничного кадра имеется4-битный ключ доступа, обеспечивающий авторизацию программ при обращении кпамяти. Каждая программа имеет свой 4-битный ключ доступа, который привыполнении программы заносится в определенные разряды PSW. При каждом обращениик памяти ключ защиты, который выбирается из PSW, сравнивается с ключомстраницы, к которой происходит обращение. Запись разрешается, только присовпадении ключей. Системные (привилегированные) программы выполняются снулевым ключом защиты, что дает им доступ к любой странице памяти.
Система ввода-выводаосновывается на каналах ввода-вывода, описанных нами в главе 6 части I. Однакотам мы описали строго иерархическое подключение «канал — контроллер — устройство», которое применялось в ранних реализациях. Современнаяархитектура мейнфреймов обеспечивает более сложную схему подключений с гибкимустановлением путей к устройству. Канальная подсистема ввода-вывода управляетпотоком данных между основной памятью и устройствами. Как часть операцииввода-вывода, канальная подсистема выполняет проверку доступности канальныхпутей, выбор одного из доступных путей и инициализацию операции обмена. Всистеме имеется два типа канальных путей:
Параллельные канальныепути, служащие для поддержки интерфейса ввода-вывода System/360 и System/370;такой путь представляет собой электрические проводные соединения междуканальной подсистемой и одним или несколькими контроллерами. До 8 контроллерови до 256 устройств могут использовать совместно один параллельный путь.
Последовательныеканальные пути ESCON и FICON состоят из двух фибероптических кабелей,динамических переключателей и контроллеров. Динамическое переключение можетбыть выполнено между двумя любыми последовательными канальными путями в этой жеили в другой канальной подсистеме. К каждому контроллеру последовательногоинтерфейса может быть подключено до 256 внешних устройств.
Внешний таймер (ETR — external time reference) обеспечивает синхронизацию часов мейнфреймов,объединенных в тесно связанный комплекс (Parallel Sysplex).
Аппаратные средстваz-архитектуры поддерживают программное обеспечение всех предыдущих архитектурмейнфреймов IBM, аналогично и ОС мейнфреймов развиваются эволюционным путем[21]. Эта эволюция происходит по трем параллельным линиям, история которыхпредставлена на рисунке 12.2.
/>
12.2 Операционная системаVSE/ESA
Линия ОС, представляемаясегодня VSE/ESA v.2.6 [21, 24, 38], ориентирована на применение на младших,наименее мощных моделях мейнфреймов. Поэтому ей свойственны более простыерешения, запаздывающее внедрение новых свойств аппаратной платформы (вчастности, она пока не использует новых возможностей z-архитектуры), отсутствиеразвитых средств управления производительностью. Хотя имеется много примеровуспешного построения промышленных информационных систем на базе VSE, ееосновное назначение — поддерживать «унаследованное» программноеобеспечение, разработанное для предшествовавших версий аппаратуры и ОС.Программисту, воспитанному на ПЭВМ, это может показаться странным, но в сферепромышленной обработки данных достаточно широко применяется программноеобеспечение, разработанное 20 и более лет назад. За столь длительный срок этипрограммы доказали свою полезность и надежность, и у пользователей нетоснований от них отказываться.
Среда выполнения, которуюVSE обеспечивает для приложений, показана на рисунке 12.3. Эта средаобеспечивается отчасти обязательными компонентами в составе ОС, отчасти — опционными компонентами ОС, отчасти — промежуточным программным обеспечением.Ниже вкратце рассматриваются компоненты, создающие эту среду.
/>
Рисунок 12.3 Средавыполнения приложения в VSE/ESA
Базовые управляющиесредства обеспечиваются обязательным компонентом ОС, который носит названиеVSE/AF (Advanced Functions). В состав этого компонента входят: ядро ОС — супервизор, обеспечивающее управление памятью, управление задачами (втерминологии IBM задача означает процесс), базовые функции управления заданиямии базовые функции управления файлами, некоторые системные утилиты и т.д.
Управление памятью
Аббревиатура VSEрасшифровывается как Virtual Storage Extension — расширение виртуальной памяти.Это название сложилось исторически, но сейчас его нельзя считать вполне точным.Первая ОС этой линии — DOS — работала только с реальной памятью. Реальнаяпамять разбивалась на разделы фиксированного размера, и в каждом разделевыполнялась одна задача. В DOS/VSE за счет динамической трансляции адресаSystem/370 создавалось виртуальное АП размером 16 Мбайт, которое затемразбивалось на разделы фиксированного размера — и для такой модели название VSEявляется вполне справедливым. Однако, уже в VSE/SP и далее — в VSE/ESAпоявилась возможность создавать для каждого раздела независимое АП размером 16Мбайт (а позже — 2 Гбайт). Структура памяти для современных версий VSEпредставлена на рисунке 12.4.
/>
Рисунок 12.4 Структурапамяти VSE/ESA
Нижняя часть виртуальнойпамяти — общая для всех разделов, в ней размещается ядро ОС — супервизор. Вышерасполагается совместно используемая область виртуальной памяти, котораясодержит программы и данные, доступные для всех разделов. Другая совместноиспользуемая область находится в верхней части 2-Гбайтного АП. Разделениесовместно используемой области на две части связано с переходом от24-разрядного адреса к 31-разрядному. Унаследованные программы с 24-разряднойадресацией видят только часть АП до 16 Мбайт, в которой есть все, что им нужно.Программы же, созданные с учетом 31-разрядной адресации, видят все 2 Гбайт АП,в том числе, и расширение разделяемой области.
Для части или для всегоАП задачи может быть определен режим GETVIS, задающий расположение этой части вреальной памяти и исключающий ее из страничного обмена. Разумеется, это снижаетэффективность функционирования остальных задач и применяется только длясистемных задач.
При старте системыавтоматически создается 12 статических разделов. В системе есть такжевозможность создавать и динамические разделы (до 200 разделов) — такие разделысоздаются автоматически при запуске задачи в области динамических разделов иуничтожаются при ее завершении. Кроме того, 31-разрядным приложениям ОС можетпредоставлять (через регистры AR) 2-Гбайтные «пространства данных»,которые могут использоваться для хранения данных. В этих пространствах такжемогут создаваться виртуальные диски.
В части статическихразделов, как правило, уже при старте системы запускаются системные задачи.Так, в разделе 0, который называется BG, обычно запускается задача связи соператором — BG; в разделе 1 — задача POWER и т.д. Разделы этих задач,выполняющих обязательное общесистемное обслуживание, обычно (но не обязательно)размещаются в общей части АП, как показано на рисунке 12.4.
Управление задачами
Единицей работы в ОСявляется задание (job). Задание состоит в последовательном выполнениинескольких шагов-задач (task) — программ (в частном случае задание можетсостоять из единственного шага). Задание характеризуется классом (буква) иприоритетом (число). Для каждого раздела оператором задаются классы заданий,выполняемых в разделе, и приоритет класса в разделе. Задания одного классавыбираются на выполнение в соответствии с числовым приоритетом, а при равенствеприоритетов — в порядке поступления. Классы и приоритеты заданий определяютпорядок, в котором задания выбираются на выполнение, но не дисциплинураспределения процессорного времени.
С точки зренияраспределения процессорного времени, VSE является системой без разделения времени,с абсолютными приоритетами. Вытесняющая многозадачность здесь реализована в томотношении, что задача с более высоким приоритетом, придя в состояниеготовности, немедленно вытесняет с центрального процессора задачу с низкимприоритетом. Приоритет задачи определяется номером раздела, в котором онавыполняется. Наивысший приоритет имеет раздел 0, далее — раздел 1 и т.д.,задачи в динамических разделах имеют самый низкий приоритет. Для эффективногоиспользования многозадачных свойств VSE следует в статических разделах сменьшими номерами запускать обменные задачи.
При работе VSE/ESA намногопроцессорной конфигурации только один процессор в каждый момент времениможет выполнять код в режиме супервизора (привилегированном режиме).
Задания в VSE/ESA бываютдвух видов — пакетные и интерактивные. Базовые средства VSE/AF обеспечиваютобработку пакетных заданий. Пакетное задание представляет собой набороператоров языка управления задания JCL на перфокартах (виртуальных). Основнымиоператорами языка JCL являются:
// JOB — операторзаголовка задания;
// OPTION — операторустановки параметров/режимов выполнения задания;
// EXEC — шаг задания,вызов на выполнение программы;
// ASSIGN — назначениефизического устройства логическому файлу программы для шага задания;
// DLBL — назначениефизического дискового файла логическому файлу программы для шага задания;
// EXEC PROC — выполнениепроцедуры в шаге задания; процедура представляет собой хранимый в библиотекенабор операторов JCL; процедура может иметь параметры и содержать некоторуюлогику (ветвление в зависимости от значений параметров и результатов выполненияотдельных шагов).
Данные могут включаться впакет или выбираться из файлов и библиотек.
Обязательным компонентомVSE является VSE/POWER — подсистема управления входными и выходными и выходнымиочередями. POWER обычно запускается в разделе F1 и располагается в реальнойпамяти. POWER выполняет следующее:
читает задания изразличных источников и записывает их во входную очередь, располагающуюся надиске (очередь RDR);
выбирает задания изочереди RDR (в соответствии с их параметрами) в соответствующие разделы иинициирует их выполнение;
записывает выходныеданные приложений в очереди LST (печать) и PUN (вывод на перфокарты);
также в соответствии спараметрами заданий передает данные из выходных очередей на реальные устройства(перфокарточные устройства не используются в современных мейнфреймах, и данные,выведенные на перфокарты, остаются электронными, в таком виде они могут бытьперенаправлены, например, во входную очередь);
для сетевой среды POWERсоздает также очередь XMT для передачи данных между узлами сети.
Таким образом, POWERявляется системой спулинга, обеспечивающей разделение процессов ввода,обработки и вывода и параллельное выполнение этих процессов.
Описанные выше классы иприоритеты заданий относятся к входной очереди, RDR. Данные, выводимые ввыходные очереди, также имеют классы и приоритеты, задаваемые независимо отвходных. VSE/POWER имеет собственный управляющий язык JECL (Job Entry ControlLanguage), основное назначение операторов которого — определение классов иприоритетов данных в очередях.
Файловая система
Сочетание структурыфайлов на внешней памяти и способов обработки файлов в программе составляетметод доступа. В VSE/ESA применяются две группы методов доступа: базисныеметоды — BAM, «унаследованные» от старых версий и виртуальныйпоследовательный метод — VSAM (применяемый также и в z/OS как единственная дляэтой ОС структура файловой системы). Обычно при инсталляции VSE создаются двадисковых тома. На этих томах устанавливаются системные файлы и библиотеки, нотакже остается место и для пользовательских файлов. Первичное управлениедисковым пространством выполняется средствами BAM. На каждом диске выделяетсяпространство — область VSAM. С точки зрения BAM, вся эта область представляетсякак один файл, но внутри этого файла средства VSAM обеспечивают собственноеуправление дисковым пространством и создание VSAM-файлов.
В начале каждого дисканаходится метка тома (VOL1), содержащая имя тома и указатель на размещениеоглавления тома. Оглавление тома — структура VTOC — содержит информацию оразмещении на томе BAM-файлов. Средства BAM фактически перекладывают управлениедисковым пространством на программиста: при создании файла программист долженявным образом указать физический адрес файла на диске и его размер. Этовыполняется средствами языка управления заданиями: после оператора // DLBL,относящегося к создаваемому файлу должен следовать один или несколькооператоров // EXTENT, задающих адреса и размеры участков файла. BAM-файлрасполагается в одном или нескольких (до 16) непрерывных участках дисковогопространства. Дисковое пространство выделяется сразу при создании файла и неможет быть перераспределено в дальнейшем. Элемент VTOC для каждого файласодержит его имя и до 16 пар «адрес-размер» для каждого участка. — Утилита VTOC помогает программисту вести карту распределения дисковогопространства.
Основные файлы BAM,создаваемые на диске DOSRES при инсталляции системы:
системная библиотекаIJSYSRS.SYSLIB, необходимая для начальной загрузки системы;
область страничногообмена;
область очередей POWER;
области файлов ICCF, CICSи других системных программ;
каталог VSAM;
область VSAM.
Часть системных библиотеки файлов инсталлируется в области VSAM.
Информация обо всехVSAM-файлах на диске сохраняется в каталоге VSAM. Каталог VSAM должен быть накаждом томе, содержащем область VSAM.
Для файлов VSAM дисковоепространство выделяется динамически, и файл может занимать несмежные участкидискового пространства. Пространство выделяется блоками фиксированного размера(размер выбирается), план размещения файла представляет собой B+-дерево. Крометого, «листья» дерева связаны в линейный список, что позволяетосуществлять быстрый последовательный доступ к данным файла. VSAM поддерживаетфизические стуктуры файлов четырех типов:
ESDS (entry-sequenceddata set) — неупорядоченные записи фиксированной или переменной длины;
KSDS (key-sequenced dataset) — записи фиксированной или переменной длины, упорядоченные по ключам;
RRDS (relative-recorddata set) — записи фиксированной длины, упорядоченные по номерам;
VRDS (variable-lengthrelative-record data set) — записи фиксированной или переменной длины,упорядоченные по номерам.
Физическая структурафайлов ESDS очевидна. Для файлов RRDS память выделяется сразу для всех записейфайла, и относительная позиция записи вычисляется. В RRDS-файле могут быть«пустые места» — для записей, еще не занесенных в файл. Для файловKSDS и VRDS строится индекс (B+-дерево с линейным списком листьев) ключей илиномеров соответственно. Для этих файлов возможно создавать также любоеколичество альтернативных индексов — по любым другим ключам, альтернативныйиндекс ссылается на основной индекс. Хотя физическая структура файлов в VSE — записеориентированная, системный API предоставляет как записе-, так ибайториентированный интерфейс.
Логическоеструктурирование хранения информации и в BAM, и в VSAM основывается наконцепции библиотек. Библиотека является контейнерным объектом, содержащим однуили несколько подбиблиотек. Подбиблиотеки содержат разделы (файлы). Памятьвыделяется для библиотеки, библиотеки BAM не могут увеличиваться в размерахсверх выделенного им пространства. Память для подбиблиотек выделяется динамическив пределах пространства библиотеки. Обычно подбиблиотеки объединяют в себеданные одного определенного типа — исходные, объектные или загрузочные модули.Системная утилита LIBR обеспечивает операции по обслуживанию библиотек.
ICCF
Наряду с пакетными заданиями,в VSE есть возможность и интерактивной работы. Она обеспечивается компонентомVSE/ICCF (Interactive Computing Control Facility). ICCF не является строгообязательным компонентом ОС, но применяется практически при всех ееинсталляциях. ICCF выполняется в отдельном статическом разделе и обеспечиваетпользователю терминала следующие возможности:
ввод, просмотр иредактирование программ, заданий и данных;
запуск с терминалазаданий — интерактивных или пакетных в POWER;
ведение библиотек ICCF(см. ниже);
доступ к файлам VSE;
доступ к очередям;
интерактивное выполнениесистемных утилит;
организацию и выполнениепотока заданий в интерактивном разделе.
Для взаимодействия спользователем ICCF использует несколько типов полноэкранных панелей:
панели выбора (меню);
панели ввода данных;
списковые панели;
панели подсказок;
панель текстовогоредактора.
ICCF обеспечиваетсобственные библиотеки и подбиблиотеки, предназначенные прежде всего дляхранения текстов программ и заданий. Файлы в библиотеках ICCF состоят иззаписей размером 88 байт, из которых первые 80 используются для данных, а в 8байтах находятся два указателя, связывающие записи файла в двунаправленныйсписок. Для библиотек ICCF определяются права доступа. С точки зрения доступаимеется три типа библиотек:
COMMON — библиотеки,содержащие некоторую общую информацию (общие процедуры, макросы и т.п.), ктаким библиотекам имеют доступ все пользователи, но только для чтения, толькосистемный администратор имеет доступ к этим библиотекам для записи;
PUBLIC — библиотеки,доступные всем пользователям для чтения и для записи;
PRIVATE — библиотеки,доступные только для одного пользователя.
Права доступа назначаютсясистемным администратором.
Другие компоненты
Для обеспеченияодновременной работы многих пользователей и ряда других своих функций ICCFиспользует компонент VSE/CICS (Customer Information Control System), которыйобязательно должен устанавливаться вместе с ICCF.
Функциональность CICSзначительно шире, чем только поддержка интерактивного интерфейса VSE. CICSявляется мощным сервером транзакций, который доступен на всех аппаратных иоперационных платформах IBM и применяется для обеспечения совместного доступа кданным множества разноплатформенных компонентов информационной системы. VSE/CICSпредставляет собой набор программных единиц и системных таблиц, которыевыполняются в отдельном статическом разделе и обеспечивают:
безопасность — авторизацию доступа пользователей к данным;
управление терминалами;
управление задачами — смультипрограммным управлением транзакциями в разделе CICS;
управление программами,включая поддержку множественных языковых сред и параллельное выполнениетранзакций в одной программе;
сериализацию доступа кданным параллельно выполняющихся транзакций;
ведение журнала ивосстановление целостности данных после сбоев.
Во всех промышленныхприменениях VSE CICS является практически обязательным компонентом, иприкладные программы для таких применений создаются с использованиемплатформенно-независимого API CICS для доступа к данным.
VSE/BTAM (BasicTelecommunication Access Method) является базовым телекоммуникационным методомдоступа, обеспечивающим управление локальными и удаленными устройствами сиспользованием протоколов BSC или Asynch. BTAM не требует отдельной инсталляциии входит в состав VSE/AF.
VSE/VTAM — (VirtualTelecommunication Access Method) является дополнительным методомтелекоммуникации, управляющим взаимодействиями между устройствами в сети SNA.Он поддерживает локальные и удаленные рабочие станции в одно- или многомашиннойсети. Если VSE/ESA установлена в узле сети, VTAM позволяет:
пользователям иприложениям получать доступ к приложениям, установленным в другой системе;
обмениваться данными сдругими системами;
другим системам получатьдоступ к VSE.
VTAM устанавливается какопционный компонент VSE/ESA и выполняется как задача в отдельном статическомразделе.
12.3 Операционная системаz/OS
z/OS (раньше — OS/390,еще раньше — MVS) является стратегической для IBM ОС мейнфреймов [21, 24, 41].Именно в этой ОС в первую очередь осваиваются новые свойства аппаратнойплатформы, именно в этой ОС в первую очередь становятся доступными новые версиистратегических продуктов промежуточного программного обеспечения, именно эта ОСрассчитана на применение в самых мощных и производительных вычислительныхкомплексах и sysplex'ах (тесно связанных многомашинных комплексах, которые«выглядят» с точки зрения управления и распределения нагрузки какодна вычислительная система). Последняя на сегодняшний день версия этой ОС — z/OS V1R3.
ОС OS/360 MVT,находившаяся «у истоков» этой линии, работала только с реальнойпамятью, создавая в ней динамические разделы по мере необходимости. В ОС MVSсложились концепции управления виртуальной памятью и другими основнымиресурсами, оставшиеся в принципе неизменными и до настоящего времени.Переименование системы в OS/390 было связано с интеграцией в систему рядапрограммных серверов, ранее существовавших в виде отдельных программныхпродуктов, а в z/OS — с адаптацией к 64-разрядной z-архитектуре. Длительнаяистория эволюционного развития MVS — OS/390 — z/OS привела к тому, что насегодняшний день z/OS является системой настолько сложной и богатойвозможностями, что описать их все даже на структурном уровне — задачаневыполнимая в объеме одной книги. Тем не менее, мы попытаемся (ни в коей мерене претендуя на полноту) дать читателю некоторое представление о компонентахуправления теми ресурсами, которые являются предметом нашего основноговнимания.
Примерная структурасистемного программного обеспечения в составе z/OS показана на рисунке 12.5.
/>
Рисунок 12.5 Структурапрограммного обеспечения z/OS
Мы отметили, что развитиеэтой ОС происходило исключительно эволюционным путем. Внедрение новыхвозможностей управления ресурсами в ОС происходит, как правило, по следующемусценарию:
новый управляющий сервисразрабатывается и внедряется как отдельный программный продукт, продаваемыйотдельно от ОС;
новый программный продуктвключается в комплект поставки ОС;
новый продуктинтегрируется с ядром ОС, возможно, становится частью ядра.
Хотя понятие«ядро» для z/OS точно не определено, мы называем ядром БазовуюУправляющую Программу (BCP — Base Control Program), осуществляющуюнизкоуровневое управление такими ресурсами, как память, процессы, средствакоммуникаций. Надстройки над низкоуровневым управлением (в составе самой BCPили на более высоких уровнях системного программного обеспечения) позволяютуправлять политиками распределения ресурсов. Ряд системных сервисов, невходящих в состав ядра, но работающих в режиме супервизора, являютсяподсистемами — средами выполнения приложений. Дополнительные системные сервисырасширяют возможности сервисов, включенных в базовый комплект. Некоторыепрограммные продукты IBM, относящиеся к классу промежуточного программногообеспечения, также можно назвать подсистемами, так как они создают собственныесреды. Эти продукты также тесно интегрированы с системой, и в ядро системывключены функции поддержки этих продуктов.
Управление памятью
Управление памятьюявляется, возможно, самым интересным свойством z/OS. Аббревиатура первогоназвания ОС — MVS расшифровывается как Multiply Virtual Storage и отражаетименно аспект управления памятью. Каждая задача в MVS (и в ее современныхнаследниках) обладает собственным виртуальным АП. Размер этого АП составлял 16Мбайт в ранних версиях ОС (24-битный адрес), 2 Гбайта, начиная с MVS/XA(31-битный адрес) и 16 эксабайт в z/OS (64-битный адрес). Мы рассмотрим сначалапервые две модели адресации, а затем отдельно расскажем об «освоении»системой 64-битного адреса.
Распределениевиртуального АП для 24- и 31-битого размера адреса показано на рисунке 12.6.Нижняя часть виртуального АП занята системой, она перекрывается для всех АП, нодля прикладных программ недоступна. Верхняя часть виртуального 16-Мбайтного АП- общая область памяти, занимаемая объектами, совместно используемыми разнымизадачами. Это как разделяемые объекты данных, так и совместно используемые программныекоды, например, системные сервисные службы, такие как TSO и т.п. АП между этимидвумя областями является частным АП задачи. При расширении АП до 2 Гбайтдополнительная часть общей области памяти, смежная со «старой»появляется по другую сторону 16-Мбайтной границы, остальная частьдополнительного АП является дополнительным частным пространством задачи. Такимобразом, задачи, в которых выполняются программы, разработанные для24-разрядных версий MVS, видят привычную для себя структуру 16-Мбайтного АП,задачи, созданные для новых версий, видят полную структуру 2-Гбайтного АП.Размещение в памяти и выполнение программы определяется параметрами RMODE иAMODE. Первый из этих параметров определяет размещение программы в нижней иливерхней части АП. Значение параметра AMODE отображается на соответствующий битPSW и определяет режим выполнения некоторых команд процессора, при AMODE=24команды, работающие с адресами, используют 24-битный адрес, при AMODE=31 — 31-битный адрес. Каждая программная секция характеризуется своими параметрамиRMODE и AMODE, таким образом, режимы адресации могут изменяться и в ходевыполнения одной задачи.
z/OS предоставляет такжеприложениям возможности использовать дополнительные АП. Хотя реализации всехэтих возможностей используют описанные выше регистры доступа AR, с точки зренияприложений их можно разделить на 4 направления:
коммуникации«пересечения памяти» (cross memory communications);
явное использованиедополнительных АП (AR ACS mode);
пространства данных (dataspaces);
гиперпространства(hiperspaces).
Коммуникации пересеченияпамяти позволяют программе передавать управление в другое АП. Управлениепередается не «напрямую», а через системный вызов (блок запроса SRB).Различают синхронные и асинхронные коммуникации пересечения памяти.
В так называемомпервичном режиме AR-программа работает только с данными, расположенными впервичном АП. В режиме же управления памятью через регистры доступа в режимеACS AR-программа может определять регистры AR, используемые для трансляцииадресов и, таким образом, употреблять обычные команды обращения к данным дляработы с параллельными АП. Программа, однако, не может передавать управление вдругое АП, для этого режим ACS AR надо комбинировать с коммуникациямипересечения памяти.
Пространства данных игиперпространства являются дополнительными именованными АП размером от 4 Кбайтдо 2 Гбайт, используемыми только для размещения данных.
Программа, использующаяпространства данных, должна работать в режиме ACS AR. Она использует системные вызовыдля создания и удаления пространства данных и управления им, команды же,выполняемые в основном АП, могут непосредственно манипулировать данными впространстве данных.
Программа, использующаягиперпространства, может работать в первичном режиме AR. Она используетсистемные вызовы для создания и удаления пространства данных и управления им, атакже для того, чтобы пересылать данные между гиперпространством и основным АП.Обмен между первичным АП и гиперпространством ведется 4-Кбайтными блоками.
Пространства данных илигиперпространства могут содержать также и программные коды, но передаватьуправление на эти коды непосредственно программа не может. Для выполнения этикоды должны быть пересланы в буфер в первичном АП. Физически оба вида пространствмогут размещаться как в основной, так и в расширенной памяти, но дляпространства данных предпочтение отдается основной памяти, а длягиперпространства — расширенной. Для управления пространствами данных системаиспользует те же механизмы страничного обмена, что и для первичного АП.Поскольку же манипулирование данными в гиперпространстве несколько ограничено,для управления гиперпространством используются более простые и болееэффективные алгоритмы.
В z/OS имеется такжемеханизм отображения в память объектов данных (data-in-virtual), аналогичныйфайлам, отображаемым в память, в Unix. Этот механизм позволяет назначить«окно» виртуальных адресов, просматривать в этом окне нужную частьобъекта данных и перемещать окно по мере необходимости. Отображение данныхвозможно (и предпочтительно) в пространство данных или в гиперпространство.
Приложение получаетпамять в своем виртуальном АП, используя системные вызовы явного (GETMAIN илиSTORAGE) или неявного выделения памяти. Управление выделением памяти ведется припомощи так называемых подпулов. Подпулы состоят из 4-Кбайтных блоков памяти иформируются динамически: блоки добавляются в подпул или удаляются из него помере необходимости. Система удовлетворяет каждый запрос на выделение памяти изодного блока (разумеется, кроме тех случаев, когда размер запроса превосходитразмер блока). При размещении небольших запросов система ищет свободное место вуже выделенных блоках по принципу «самый подходящий» и лишь приневозможности удовлетворить запрос таким образом выделяет новый блок.
При создании любой задачидля нее обязательно создается подпул 0, но в задаче может быть создано ибольшее число подпулов. Любой подпул может использоваться только одной задачейили разделяться несколькими задачами. Подпул 0 разделяется задачей со всеми ееподзадачами, но если подпул 0 задачи определен как неразделяемый, для каждойподзадачи будет создаваться свой подпул 0. Монопольно используемые подпулыосвобождаются с окончанием задачи, которая ими владеет. Разделяемые подпулысохраняются, пока сохраняется хотя бы одна из использующих их задач.
«64-разряднаяреволюция» аппаратуры мейнфреймов осваивается z/OS за несколько шагов.
Первый шаг, сделанный вz/OS V1R1, обеспечил 64-битное управление реальной памятью, что позволилоуменьшить страничный обмен и ограничения на память для прежних 31-разрядныхприложений.
Со второго шага,сделанного в z/OS V1R2, обеспечивается поддержка 64-битной адресации в одномАП. Качественно картина виртуальной памяти приложения остается такой же, как ипредставленная на рисунке 12.6, но выше границы 2 Гбайт, называемой«планкой» (bar) появляется дополнительная часть частного АП. Любая31-битная программа может теперь получать виртуальную память за планкой иманипулировать данными в этой памяти. Программа по-прежнему размещается впределах 2 Гбайт, виртуальная память выше планки предназначена только дляданных. Новый язык Ассемблера включает в себя новые команды для работы сданными за планкой и манипулирования с 64-разрядными регистрами общегоназначения. Системные вызовы для работы с данными за планкой включают в себяпрежние механизмы выделения и освобождения памяти — для совместимости состарыми программами, но система управляет пространством выше планки какобъектами данных. В новых механизмах программа создает за планкой объектыданных, размер которых кратен 1 Мбайту. В V1R2 объекты данных не могутсовместно использоваться в разных АП.
Третий шаг (z/OS V1R3)состоит во внедрении AMODE=64. В сочетании с новыми возможностями РедактораСвязей и Загрузчика этот режим позволяет создавать полностью 64-разрядныепрограммы.
Четвертый шаг, которыйбудет реализован в следующей версии z/OS, — обеспечение возможности разделенияобъектов данных, размещенных за планкой между разными АП.
Параллельно с введением64-разрядных возможностей в системные сервисы и низкоуровневое программированиеони внедряются и в инструментальные средства (C/C++, Java), и в основныепродукты промежуточного программного обеспечения (DB2, WebSphere и др.).
Управление процессами
АП в z/OS создается длязадания. Как и в VSE, задание в z/OS состоит из нескольких последовательновыполняющихся программ — шагов задания. Для каждого шага задания создаетсязадача (процесс). Структурой, представляющей задачу в системе, является блокуправления задачей TCB (Task Control Block). Задача может порождать новыезадачи (подзадачи) при помощи системных вызовов ATTACH (подзадача выполняется впервичном режиме AR) или ATTACHX (подзадача выполняется в режиме ASC AR).Порождаемые таким образом подзадачи имеют собственные блоки TCB и, такимобразом, представляются как полноценные задачи, но все они выполняются в том жеАП, что и породившая их задача. Порожденная подзадача выполняется параллельно спородившей и может порождать собственные подзадачи. Между задачей и ее подзадачамиустанавливаются отношения «предок — потомок». Задача и ее подзадачивыполняются асинхронно, но выполнение задачи-предка может быть исинхронизировано с завершением задачи-потомка. Подзадача может порождаться спараметрами ECB или/и EXTR. Первый параметр назначает для подзадачи БлокУправления Событием (Event Control Block), в котором делается отметка озавершении подзадачи. Если подзадача создается с параметром ECB, ее TCB неудаляется с ее завершением, а сохраняется до тех пор, пока информация озавершении не будет востребована задачей-предком. Задача-предок может ожидатьзавершения потомка и получить информацию о его завершении, применяя системныйвызов WAIT, параметром которого является ECB потомка. Параметр EXTR позволяетопределить в задаче-предке процедуру, которая автоматически выполняется призавершении данного потомка.
Приоритеты выполненияопределяются на двух уровнях:
приоритет АП;
приоритеты задач иподзадач.
Приоритет АП, какправило, определяется ОС из соображений обеспечения наилучшей загрузки системы(см. ниже). Однако этот приоритет может быть назначен и пользователем воператорах языка управления заданиями. Приоритет пользователя назначаетсядифференцированно для каждого шага задания. Приоритет АП, установленныйпользователем для шага задания, во время выполнения шага изменяться в программене может, но может меняться ОС.
Создавая задачу для шагазадания, ОС присваивает ей диспетчерский (текущий) и граничный приоритеты.Подзадача по умолчанию наследует приоритеты своего родителя, но ей могут бытьназначены и собственные приоритеты. Приоритеты подзадач могут меняться впрограмме системным вызовом CHAP. Приоритеты задач/подзадач, однако, никак невлияют на то, в каком порядке выбираются на выполнение программы — этот порядокопределяется только приоритетом АП. Приоритеты же подзадач влияют на порядок ихвыборки на выполнение в пределах процессорного обслуживания, выделяемого дляАП. В этих пределах приоритеты подзадач являются абсолютными: на выполнениевыбирается подзадача с наивысшим приоритетом, текущая активная подзадачанемедленно вытесняется, если подзадача с более высоким приоритетом приходит всостояние готовности.
Средства взаимодействия
Выше мы упомянули облоках ECB, используемых для синхронизации выполнения задачи и ее подзадач.Однако блоки ECB являются более универсальным средством синхронизациивыполнения. ECB используется с системными вызовами WAIT, POST и EVENTS.Системный вызов POST сигнализирует о совершении события, системные вызовы WAITи EVENTS задерживают выполнение задачи до совершения одного или несколькихсобытий.
Для взаимного исключениядоступа к ресурсам из разных программ используются системные вызовы ENQ и DEQ.В первом приближении их можно считать эквивалентным семафорным операциям P и Vсоответственно. При употреблении этих системных вызовов задается имя ресурса имасштаб. Имя (оно состоит из двух частей) в документации IBM называется именемресурса, но на самом деле это скорее имя семафора, имена в операциях ENQ/DEQназначаются произвольно и не имеют никакой связи с действительными именамиресурсов. Масштаб определяет область видимости ресурса:
масштаб STEP означает,что ресурс доступен только в данном АП;
масштаб SYSTEM означает,что ресурс доступен во всех АП, но только в данной вычислительной системе;
масштаб SYSTEMS означает,что ресурс доступен во всех АП всех вычислительных систем sysplex'а.
Комбинация имени ресурсаи масштаба должна быть уникальной.
В отличие от обычныхсемафорных операций, системный вызов ENQ может выполняться в монопольном илиразделяемом режиме, что соответствует классической задаче«читатели-писатели». Любое число задач может одновременно получатьдоступ к ресурсу в разделяемом режиме, только одна задача может иметь доступ кресурсу в монопольном режиме.
Системный вызов ENQ можеттакже выполняться и с условием. Предусмотренные для ENQ условия могутобеспечивать:
проверку состоянияресурса без его захвата;
захват ресурса только втом случае, если он немедленно доступен;
изменение режима захватас разделяемого на монопольный;
захват ресурса только втом случае, если программа еще им не владеет.
Задачи, задержанные привыполнении операции ENQ, образуют очереди к ресурсам, которые обслуживаются подисциплине FCFS. Размер такой очереди может быть, однако, ограничен, в этомслучае попытка выполнения запроса ENQ, который переполнит очередь, приводит нек блокированию программы, а к завершению запроса с признаком ошибки.
Попытка захвата ресурса,которым программа уже владеет, приводит к аварийному завершению программы. Ответственностьза обход тупиков лежит на программисте.
Системные вызовы в z/OSвыполняются системными сервисными процедурами. Такая процедура представляется всистеме Блоком Сервисной Процедуры SRB (Service Routine Block). SRB во многоманалогичен TCB, но SRB не может владеть АП. Однако SRB может получать ииспользовать память в АП вызвавшей его задачи и в системном АП. После вызовапроцедуры и создания для нее SRB сервисная процедура может выполнятьсяпараллельно с вызвавшей ее программой (даже с реальным параллелелизмом — наразных процессорах). Все системные процедуры являются реентерабельными и,следовательно, могут быть прерваны в ходе своего выполнения.
Подсистемы и управлениересурсами
Прежде чем рассмотретьпринципы распределения ресурсов в системе, дадим краткие характеристикинекоторым (далеко не всем) подсистемам в составе z/OS.
Подсистема ввода заданийJES (Job Entry Subsystem) обеспечивает выполнение пакетных заданий. Ее функцииво многом аналогичны подсистеме POWER в VSE. JES интерпретирует операторы языкауправления заданиями JCL и управляет очередями. В системе могут быть запущенынесколько копий JES, каждая из которых создает свой системный образ. Имеютсядве версии JES — JES2 и JES3, которые различаются тем, что в JES2 выполняетсянезависимое управление каждой запущенной копией, в JES3 осуществляетсяцентрализованное управление всеми копиями.
Подсистема разделениявремени TSO/E (Time Sharing Option/Extention) — основной интерактивныйинтерфейс z/OS. TSO/E обеспечивает для конечных пользователей, программистов иадминистраторов набор команд и полноэкранных возможностей для подготовкипрограмм, подготовки и выполнения заданий, выполнения управления системой. Какобязательная часть z/OS, TSO/E является базой для ряда других системныхсервисов, таких как Book Manager, Hardware Configuration Definition и другие.
z/OS UNIX System Servicesобеспечивают использование z/OS как сверхмощного Unix-сервера. Службыприложений z/OS UNIX System Services включают в себя командный интерпретаторshell, утилиты и отладчик. Набор команд и утилит полностью соответствуетспецификациям стандарта Single Unix Specification, известного также как Unix95. Это позволяет программистам и пользователям, даже не знающим команд z/OS,взаимодействовать с z/OS как с Unix-системой. Отладчик предоставляетпрограммистам набор команд для интерактивной отладки программ, написанных наязыке C. Этот набор подобен аналогичным командам, существующим в большинствеUnix-систем. Службы ядра z/OS UNIX System Services совместно с языковыми средамиобеспечивают соответствующий Single Unix Specification API для программированияна языке C, многопоточность и средства разработки клиент/серверных приложений.Это обеспечивает возможность программирования для z/OS как для Unix и переносав z/OS приложений, созданных для Unix.
Еще MVS прошласертификацию по стандартам POSIX, Single Unix Specification и OSF/1. Такимобразом, z/OS соответствует Unix-ориентированным стандартам лучше, чембольшинство систем, относящихся к семейству Unix, и является наилучшимUnix-суперсервером.
Планированиемраспределения ресурсов занимается Менеджер Системных Ресурсов — SRM (SystemResource Manager), являющийся компонентом BCP. SRM определяет, какие АП получатдоступ к системным ресурсам, и ту долю системных ресурсов, которая будетвыделена каждому АП. SRM распределяет ресурсы между АП в соответствии сприоритетными требованиями, заданными в параметрах инсталляции, и стремитсядостичь оптимального использования ресурсов с точки зрения производительностисистемы. При определении параметров функционирования SRM работы, выполняемые всистеме, разбиваются на группы, называемые доменами. Домены характеризуютсяобщими характеристиками работы, и общим для домена показателем важности. Каждоевыполняющееся АП попадает в тот или иной домен — пакетное задание, транзакцияIMS, транзакция DB2, короткая или длинная команда TSO и т.д. Управлениедоменами дает возможность:
гарантировать доступ ксистемным ресурсам хотя бы минимальному количеству АП, принадлежащих копределенному типу работы;
ограничивать количествоАП, имеющих доступ к ресурсам, для каждого типа работ;
назначать степеньважности для каждого типа работ.
Управлениехарактеристиками выполнения позволяет дифференцировать выполняемые работы,например, установить приоритет коротких транзакций над длинными, приоритетвремени реакции над пропускной способностью и т.д.
Управление доменамипозволяет установить, какие АП получают доступ к системным ресурсам.Диспетчеризация управляет долей системных ресурсов, получаемых каждым из допущенныхАП. После того, как АП включено в мультипрограммный набор (набор АП,размещенных в основной памяти и допущенных к использованию ресурсов), все АПконкурируют за обладание ресурсами независимо от доменов, к которым онипринадлежат. Диспетчеризация ведется по приоритетному принципу: работа снаивысшим приоритетом получает ресурс первой. Всего в системе имеется 256уровней приоритетов, которые разбиты на 16 наборов по 16 уровней в каждом.Внутри каждого набора АП может иметь переменный или фиксированный приоритет.Фиксированные приоритеты более высокие, чем переменные. Фиксированный приоритетпросто назначается АП в соответствии с параметрами, указанными в настройках SRMдля домена. Переменные приоритеты периодически перевычисляются по алгоритмуминимизации среднего времени ожидания.
SRM управляетиспользованием ресурсов в пределах всей системы и постоянно ищет путипреодоления дисбаланса — перегрузки ресурса или его простоя. Это достигаетсяпутем периодического пересмотра уровня мультипрограммирования — количества АП,которые находятся в основной памяти и готовы к диспетчеризации. Когдахарактеристики использования показывают, что ресурсы системы используются неполностью, SRM выбирает домен и увеличивает число допущенных АП в этом домене.Если показатели использования говорят о перегрузке системы, SRM уменьшаетуровень мультипрограммирования.
Для уменьшенияинтенсивности страничного обмена SRM применяет так называемый «логическийсвопинг». Страничные кадры АП, подвергающегося логическому свопингу, сохраняютсяв основной памяти на время, не превышающее некоторого порогового значения,устанавливаемого SRM. Пороговое значение для логического свопингаперевычисляется динамически и зависит от текущей потребности системы в основнойпамяти.
SRM автоматическиопределяет наилучший состав АП в мультипрограммном наборе и количество основнойпамяти, выделяемое каждому АП, наиболее эффективное в рамках принятого уровнямультипрограммирования. При этом управление страничным обменом и использованиемЦП в рамках всей системы сочетается с индивидуальным управлением рабочимнабором каждого АП. Таким образом, показатели свопинга определяютсяобщесистемными показателями страничного обмена и требованиями рабочего набора,причем последние имеют некоторый приоритет.
SRM также определяетприоритеты АП в очередях ввода-вывода. По умолчанию эти приоритеты такие же,как и диспетчерские приоритеты, но в параметрах SRM для доменов могут бытьназначены приоритеты ввода-вывода выше или ниже их диспетчерских приоритетов.
SRM управляетраспределением дисковых устройств и контролирует использование таких ресурсов,как вторичная память (дисковые области, используемые для свопинга — они невходят в дисковое пространство, управляемое файловой системой), областьсистемных очередей и ресурс страничных кадров. При нехватке этих ресурсов SRMпредпринимает меры, сводящиеся к уменьшению уровня мультипрограммирования.
Настройка SRMпроизводится при инсталляции ОС и продолжается в ходе ее эксплуатации. Этопроцесс итеративный и, возможно, бесконечный, так как в ходе эксплуатациихарактеристики выполняемого системой потока работ могут уточняться и меняться.Мы уже отмечали в нашей книге, что мейнйфреймы обладают весьма высокимпоказателем производительность/стоимость, но реально высоким этот показательможет быть только тогда, когда производительность будет востребована в полномобъеме. Эффективность работы SRM существенно зависит от параметров, заданныхпри его настройке, а гарантировать правильность определения пользователембольшого числа параметров, многие из которых могут находиться в сложнойзависимости друг от друга, невозможно. Поэтому возникла необходимостьпереложить планирование нагрузки в вычислительной системе или sysplex'е на ОС.В настоящее время надстройка над SRM, осуществляющая это планирование — Менеджер Нагрузки (WLM — Workload Manager) — включена в ядро ОС. WLM требует отадминистратора нагрузки задания определения сервиса и сам реализует этоопределение в рамках системы или sysplex'а. Определение сервиса производится нев терминах системных параметров, как для SRM, а в терминах пользователя. Такимобразом, WLM требует от пользователя определение того, что нужно сделать, а нетого, как это делать. Как это делать, WLM решает сам, учитывая конфигурациюсистемы и требования всех используемых подсистем, обеспечивающих собственныесреды выполнения — как входящих в состав ОС (TSO, JES, Unix System Services идр.), так и отдельных программных продуктов (CICS, DB2, MQSeries и др.).
Определение сервисавключает в себя:
Политику сервиса — наборбизнес-целей управления, таких как время реакции и максимальная задержкавыполнения. Каждой цели придается также весовой коэффициент, характеризующийважность достижения этой цели.
Классы сервиса, которыеразбиваются на «периоды» — группы работ с одинаковыми целями итребованиями к ресурсам.
Группы ресурсов, которыеопределяют границы процессорной мощности в sysplex'е. Назначая классу сервисагруппу ресурсов, администратор загрузки определяет минимальный и максимальныйобъем процессорного обслуживания для работы.
Правила классификации,которые определяют, как отнести поступившую работу к тому или иному классусервиса.
Прикладные среды — группыприкладных функций, которые выполняются в АП сервера и могут быть вызваныклиентом. WLM в соответствии с определенными целями автоматически активизируетили останавливает АП сервера.
Среды планирования — списки ресурсов (первичных и вторичных) с отражением их состояния, которыепозволяют гарантировать, что система (в составе sysplex'а) обладает достаточнымресурсом для выполнения работы.
Классы отчетности,используемые для получения более подробной информации о производительностивнутри класса сервиса.
В соответствии сопределением сервиса WLM обеспечивает распределение нагрузки между процессорамиодной вычислительной системы и системами всего sysplex'а, управление временемзадержки работы после прихода ее в состояние готовности, управление анклавами(транзакциями, например, DB2, выполняющимися параллельно в разных АП, возможно,на разных системах sysplex'а), управление запросами клиентов к серверами иполучение информации о состоянии. Управление ведется WLM с динамическойобратной связью, с учетом нагрузки в каждый текущий момент, а такжераспределения нагрузки на предыдущем интервале времени.
Следующим шагом воптимизации использования ресурсов мейнфреймов и их sysplex'ов стало внедрениеИнтеллектуального Распорядителя Ресурсами IRD (Intellegent Resource Director).IDR обеспечивает возможность управлять несколькими образами операционнойсистемы, выполняющимися на одном сервере (в разных логических разделах), какодним вычислительным ресурсом с динамическим управлением нагрузкой ибалансировкой физических ресурсов — процессоров и каналов ввода-вывода — междумногими виртуальными серверами. Система динамически перераспределяет этиресурсы в соответствии с определенными бизнес-приоритетами с тем, чтобыудовлетворить непредсказуемые требования задач электронного бизнеса. IRDвключает в себя три основных компонента:
LPAR CPU Management — логические разделы (LPAR) на одном z-сервере объединяются в виртуальныеsysplex-кластеры и управляются в соответствии с бизнес-целями и их важностью,сформулированными для WLM;
Dynamic Channel PathManagement — дает возможность динамически переключать канальные пути (черезпереключатель ESCON Director) от одного контроллера к другому, таким образом,WLM получает возможность обеспечивать раздел большей или меньшей пропускнойспособностью по вводу-выводу — в соответствии с требованиями и важностьювыполняемой в нем задачи;
Channel SubsystemPriority Queuing — распространяет возможности приоритетной диспетчеризацииввода-вывода на весь LPAR-кластер: если важная задача не может обеспечитьвыполнение своих целей из-за нехватки пропускной способности ввода-вывода,раздел, выполняющий эту задачу, получает дополнительные каналы ввода-вывода.
IRD является частьюширокомасштабного проекта IBM eLiza, целью которого является созданияфундамента для информационных систем с уменьшенной сложностью и стоимостьюэксплуатации, использования, администрирования. Хотя проект eLiza неориентирован на единственную аппаратную платформу и операционную среду, повполне понятным причинам z-серверы и z/OS являются «передним краем»его реализации. Цели проекта eLiza сформулированы как: самооптимизация(self-optimization), самоконфигурирование (self-configuration),самовосстановление (self-healing) и самозащита (self-protection).
Самооптимизациязаключается в свойствах WLM и IRD эффективно перераспределять ресурсы вусловиях непредсказуемой рабочей нагрузки. В z/OS V2 планируется распространитьвозможности IRD на разделы, выполняющие ОС, отличные от z/OS (z/VM, Linux).
Самоконфигурированиеподдерживается такими средствами, как msys for Setup (обеспечение простой дляпользователя установки программного обеспечения) и z/OS Wizards — web-базированные диалоговые средства настройки системы.
Самовосстановлениеподдерживается:
множеством функцийконтроля и восстановления оборудования (Hardware RAS), среди которых — определение различных сбоев и в ряде случаев — автоматическое переключение ивосстановление, plug and play и «горячее» переключение ввода-вывода идр.;
дуплексной передачейструктур соединения (System-Managed CF Structure Duplexing) — устойчивыммеханизмом, позволяющим обеспечить неразрывное соединение;
msys for Operations — обеспечением лучшей работоспособности приложений за счет большей информации оресурсах и самовосстановления критических ресурсов, а также снижениявероятности и облегчения восстановления из-за ошибок оператора;
System Automation forOS/390 — продуктом, обеспечивающим восстановление приложений, ресурсов системыи sysplex'а — на базе принятой политики обслуживания.
Самозащитаобеспечивается:
Intrusion DetectionServices — средством, позволяющим обнаруживать атаки на систему и выбирать механизмызащиты;
Public Key Infrastructure- встроенной в z/OS системой аутентификации и авторизации на основе открытогоключа;
средствами безопасности,являющимися промышленными стандартами: LDAP, Kerberos, SSL, цифровыесертификаты и т.д.
Часть описанных средствуже имеется в составе z/OS, в рамках проекта eLiza предполагается ихинтеграция, расширение их возможностей в новых версиях, создание новых средстви перенос их на другие аппаратные платформы и в другие ОС IBM.
12.4 Операционная системаz/VM
ОС z/VM [21, 24, 42](последняя версия — V4R2) является высокопроизводительной многопользовательскойинтерактивной ОС, предоставляющей уникальные возможности в части выполненияразличных операционных сред на одном вычислительном комплексе, поддержки интерактивныхпользователей и клиент/серверных сред. Существует «легенда» о том,что VM родилась как инструментальное средство, предназначенное дляиспользования только внутри IBM, и попала на рынок вопреки планам фирмы. ХотяIBM и опровергает эту легенду, она выглядит вполне правдоподобно. z/VMпредставляет интерес для применения прежде всего в таких случаях:
как инструментальнаяплатформа для разработки и отладки системного программного обеспечения, в томчисле, и других ОС, обеспечивающая эффективное использование вычислительныхмощностей в процессе отладки и легкое восстановление после краха отлаживаемойсистемы;
как платформа длямиграции на новые ОС и новые версии ОС и системного программного обеспечения,обеспечивающая параллельное функционирование как старого, так и новогопрограммного обеспечения;
как платформа дляинформационных систем, требующих параллельного функционирования множестваприкладных и операционных сред, хорошо друг от друга изолированных, с однойстороны, а с другой, легко устанавливающих связи друг с другом.
Уникальные свойства z/VMопределяются ее архитектурой. Аббревиатура VM расшифровывается как VirtualMachine, и эта ОС в полной мере воплощает концепцию виртуальных машин:интерфейс процесса выглядит как интерфейс оборудования. Ядро z/VM составляетУправляющая Программа CP (Control Program), которая предоставляет для своихконечных пользователей рабочую среду, называемую виртуальной машиной (ВМ). ВМ вz/VM является аналогом процесса в других ОС: это тот «субъект»,которому CP выделяет ресурсы. ВМ моделирует реальную вычислительную систему:процессор (или процессоры), память, устройства и каналы ввода-вывода. Упользователя создается впечатление, что в его распоряжении имеется реальнаяЭВМ, доступная для него в привилегированном режиме. На самом же деле, в егораспоряжении находится только то подмножество ресурсов, которое выделяет илимоделирует для ВМ CP. PSW ВМ определяет для выполняющейся на ВМ программысостояние «супервизор» (привилегированное состояние). PSW же реальногооборудования при выполнении такой программы определяет состояние«задача» (непривилегированное). При попытке программы, выполняющейсяна ВМ, выполнить привилегированную команду происходит исключение, и управлениеполучает CP. CP распознает причину исключения и выполняет для ВМпривилегированную команду или моделирует ее выполнение, после чего возвращаетуправление ВМ. Исключение и его обработка скрыты от ВМ, ВМ кажется, что еепривилегированная команда выполнилась на реальном оборудовании.
СP на выбор моделируетдля ВМ архитектуры нескольких поколений мейнфреймов — от 370/XA до z900, атакже виртуальную архитектуру ESA/XC (eXtended Confuguration), в которой ВМмогут быть доступны (при авторизации) адресные пространства других ВМ. В числокомпонентов архитектуры ВМ входят:
процессор/процессоры;
память;
внешняя память;
операторская консоль;
каналы и устройстваввода-вывода.
Поскольку CPпредоставляет ВМ модель, неотличимую для нее от ресурсов реальнойвычислительной системы, программа, выполняющаяся на ВМ, может (и должна)осуществлять управление этими ресурсами, то есть, в свою очередь, бытьоперационной системой. Такие ОС называются в z/VM гостевыми (guest). Вдокументации z/VM CP иногда называют гипервизором, в отличие от супервизоров — управляющих программ гостевых ОС. Гостевая ОС может «знать» о том,что она работает под управлением гипервизора, в этом случае гостевая ОС можетиспользовать обращения к CP (команда DIAGNOSE), а также гостевая ОС и CP могутраспределять между собой управление ресурсами: гипервизор работает синтерфейсом оборудования, а гостевая ОС — с интерфейсом процесса. Если жегостевая ОС не знает о присутствии CP, то она выполняет управление созданнойдля нее моделью ресурсов в полном объеме. С этой точки зрения можно разделитьгостевые ОС на четыре категории:
ОС, специально созданныекак гостевые, которые могут работать только в среде ВМ под управлениемгипервизора — CMS и GCS.
Полнофункциональныедругие ОС мейнфреймов (VSE, z/OS и ее предшественники, Linux for zSeries),выполняющиеся «не зная» о существовании гипервизора.
Те же ОС, ноадаптированные для выполнения в среде ВМ, адаптация состоит в том, чтоисключается дублирование функций в гипервизоре и супервизоре.
Гостевой ОС может бытьдругая (вторичная) CP, которая распределяет выделенное ей подмножество ресурсовмежду своими ВМ и своими гостевыми ОС, среди которых в свою очередь могут бытьCP и т.д.
/>
Рисунок 12.7 CP ивиртуальные машины
Определение ВМ являетсяквазипостоянным: оно создается один раз, а затем используется многократно.Определение ВМ сохраняется в каталоге CP, основным содержанием элементакаталога CP является описание ресурсов, выделяемых ВМ. При запуске ВМ навыполнение CP на основе элемента каталога строит Блок Определения ВиртуальнойМашины — VMDBLK (Virtual Machine Definition BLocK), в котором содержитсяописание ресурсов ВМ (либо непосредственно в VMDBLK, либо как ссылки на другиеуправляющие блоки) и их текущего состояния. Если для ВМ создается нескольковиртуальных процессоров, то для каждого процессора создается свой VMDBLK, нотолько один из VMDBLK каждой ВМ является базовым — тот, который содержитописание памяти ВМ. Свой VMDBLK имеет также и CP. Все VMDBLK связаны вкольцевой список.
Управление памятью
Возможно, главнымресурсом, которым управляет CP, является реальная память, и с этой точки зренияCP может создавать ВМ трех типов:
Тип V=V — ВМ, которойвыделяется только виртуальная память, требуемый размер памяти дя ВМобеспечивается за счет динамической трансляции адресов и страничного свопинга.
Тип V=F — ВМ, которойвыделяется непрерывная область реальной памяти. Эта область исключается изстраничного обмена, но динамическая трансляция адресов для ВМ V=F применяется,так как виртуальное адресное пространство ВМ начинается с адреса 0, а вреальной памяти область, выделяемая для ВМ V=F, начинается не с 0. ВМ типа V=Fобладают преимуществом в производительности перед ВМ V=V.
Тип V=R — ВМ, которойвыделяется непрерывная область реальной памяти, начиная с адреса 0. Эта памятьисключается из страничного обмена и для нее не применяется динамическаятрансляция адресов. Кроме того, ВМ V=R может выполнять некоторыепривилегированные операции на реальном оборудовании. Очевидно, чтопроизводительность ВМ этого типа наивысшая.
ВМ двух последних типовназываются привилегированными. В настоящее время CP допускает одновременноефункционирование не более шести привилегированных ВМ, из которых только однаможет быть типа V=R, тогда как число одновременно работающих ВМ типа V=V можетисчисляться десятками тысяч. Работа привилегированных ВМ резко отрицательносказывается на производительности всех других VM, поэтому эти типы ВМ создаютсятолько при наличии действительной необходимости в них (например, для задачреального времени).
Если под управлением CPработают только ВМ типа V=V, то ядро CP занимает нижнюю часть реальной памяти(начиная с адреса 0). Вся реальная память выше ядра отводится под динамическуюстраничную область, которая подвергается страничному обмену. Если же подуправлением CP работают наряду с ВМ типа V=V и привилегированные ВМ, то нижняячасть реальной памяти отводится под область V=R. Часть этой области, начиная садреса 0, занимает единственная ВМ типа V=R, остальная часть области распределяетсямежду ВМ типа V=F. Выше области V=R размещается ядро CP, а еще выше — динамическая страничная область.
Динамическая страничнаяобласть содержит:
управляющие блоки СP;
нерезидентные модули CP;
блоки управления памятьюCP;
буферы для спулинга и файловойсистемы;
префиксные страниц дляреальных процессоров;
свободные страничныекадры;
страницы ВМ типа V=V.
В архитектуре z/VMразличаются три уровня памяти:
память первого уровня — реальная память;
для каждой ВМ CP строитвиртуальное адресное пространство — память второго уровня;
с точки зрения гостевойОС память второго уровня является реальной памятью, и гостевая ОС строит длясвоих процессов виртуальные адресные пространства — память третьего уровня.
Виртуальная память ВМсостоит из сегментов. Для каждой ВМ строится своя таблица сегментов. Приразмере виртуальной памяти ВМ до 32 Мбайт таблица сегментов находитсянепосредственно в VDMBLK, при большем размере — для нее выделяютсядополнительные страницы (по 1 странице на каждые 1024 Мбайт виртуальнойпамяти). С каждой таблицей сегментов связана собственная таблица страниц.
Страницы, размещаемые вдинамической страничной области, подвергаются вытеснению и подкачке. CP ведетобщий список свободных страничных кадров и списки используемых страничныхкадров для каждой ВМ.
Список свободныхстраничных кадров пополняется при необходимости и обрабатывается по дисциплинеLIFO.
Списки используемыхстраничных кадров ВМ обрабатываются по дисциплине рабочего набора. Этот сисокпериодически переупорядочивается по частоте использования. После каждого такогопереупорядочивания в списке устанавливается промежуточный указатель — на началотой части списка, в которой располагаются дескрипторы кадров, к которым не былообращения со времени последнего переупорядочивания. Первая часть спискасоставляет рабочий набор ВМ, вторая — страницы-кандидаты на перенос в списоксвободных страничных кадров.
Если размер спискасвободных страничных кадров достигает установленной нижней границы, происходитпополнение списка. Список пополняется до тех пор, пока его размер не достигнетверхней установленной границы. Это может потребовать неоднократного просмотрасписков страничных кадров ВМ, каждый следующий просмотр предъявляет болеежесткие требования к состоянию страницы и ВМ, которой страничный кадрпринадлежит.
При выделении для ВМвиртуальной памяти предусмотрены два механизма: выделение блока памятипроизвольного размера и выделение блока из подпула. Выделение блокапроизвольного размера происходит традиционными методами. Выделение из подпулавыполняется быстрее произвольного и применяется для выделения памяти (какправило, неявного) для управляющих блоков, создаваемых для ВМ. В этом случаевыделяется один из заранее заготовленных блоков стандартного размера.
Диспетчеризация ВМ
При работе на двух- иболее процессорной конфигурации реальной системы для ВМ типа V=R по умолчаниювыделяется отдельный процессор. Для ВМ типа V=F отдельный процессор может бытьвыделен, но по умолчанию это не делается.
CP может моделироватьмногопроцессорную конфигурацию для ВМ, но при создании ВМ с большим числомпроцессоров, чем имеется в реальной системе, производительность такой ВМпадает, поэтому такой прием применяется только при отладке гостевых ОС идругого программного обеспечения, рассчитанного на многопроцессорнуюконфигурацию.
Единицей диспетчеризациис точки зрения распределения процессорного обслуживания является ВМ. Основнойцелью обслуживания является справедливое распределение процессорного временимежду ВМ. СP поддерживает три очереди ВМ на процессорное обслуживание:
диспетчерскую очередь,d-список (dispatch list), ВМ состоящие в диспетчерской очереди, получаютпроцессор в режиме разделения времени, мы называли такие процессы готовыми;
очередь готовых ВМ,e-список (eligible list), которые исключены из диспетчеризации из-за нехваткиресурса памяти;
список «спящих» ВМ (dormant list).
Готовыми здесь называютсяте ВМ, которые требуют выполнения какой-либо процессорной транзакции.«Спящие» ВМ процессорного обслуживания не требуют.
Все ВМ распределяются почетырем классам обслуживания:
критические — те, длякоторых гарантируется отсутствие ожидания в e-списке (класс 0);
очень интерактивные — выполняющие короткие транзакции (класс 1);
интерактивные — выполняющие транзакции средней длительности (класс 2);
неинтерактивные — выполняющие длинные транзакции (класс 3).
Класс с меньшим номеромимеет более высокий приоритет в e-списке. В d-списке приоритеты перевычисляютсядинамически через каждый квант времени. При перевычислении кванта принимаетсяво внимание:
внешний приоритет ВМ;
время ожидания вd-списке;
интерактивная добавка длякласса 1;
страничная добавка — единоразовая добавка к приоритету, назначаемая для ВМ класса 2 или 3 призадержке из-за страничного отказа.
Очередная ВМ из d-спискаполучает квант процессорного времени, который назначается таким образом, чтобыего время было примерно равно времени выполнения 100000 машинных команд. ЕслиВМ переходит в состояние ожидания до исчерпания кванта, то она еще остается вd-списке на время, называемое «интервалом проверки ожидания» (300мсек). Если ВМ выйдет из ожидания до истечения этого интервала, она остается вd-списке и получает возможность использовать недоиспользованный квант. Есливремя ожидания превосходит интервал проверки, ВМ переводится в список спящих.ВМ за время пребывания в d-списке разрешается трижды воспользоваться интерваломпроверки ожидания.
Кроме того, CP такжевычисляет для каждой ВМ квант готовности — общее реальное время пребывания ВМ вd-списке. Для ВМ класса 1 этот квант вычисляется системой таким образом, чтобыза время кванта готовности успели завершить свои транзакции 85% ВМ класса 1.Для классов 0 и 2 этот квант в 6 раз больше, чем для класса 1, для класса 3 — в48 раз больше, чем для класса 1. Если ВМ исчерпала квант готовности, но незавершила транзакцию, она переводится в следующий класс.
Использование рабочегонабора не влияет на приоритет ВМ в e-списке, но влияет на перемещение ВМ междуd- и e-списками. Если ВМ, находящейся в d-списке, не хватает памяти дляразмещения своего рабочего набора, в d-списке блокируются все ВМ того же ибольшего класса. Если ВМ, находящаяся в d-списке, превысила лимит роста своегорабочего набора (кроме ВМ класса 0), она переводится в e-список. Если вe-списке имеется ВМ класса 1, которая запаздывает с переходом в d-список, CPпытается вытеснить из d-списка последние переведенные в него ВМ классов 2 или3.
В результате такойполитики распределения процессорного обслуживания преимущество получаютинтерактивные ВМ, выполняющие короткие процессорные транзакции.
Виртуальные устройства
ВМ владеет такжевиртуальными каналами и устройствами. Назначение ВМ виртуального внешнегоустройства может быть как постоянным (записанным в соответствующем данной ВМэлементе каталога CP), так и временным. С точки зрения ВМ виртуальноеустройство ничем не отличается от реального, оно имеет в ВМ свой физическийадрес и ВМ управляет им как реальным устройством.
Некоторые внешниеустройства (например, накопители на магнитных лентах) закрепляются за ВМ.Закрепление означает, что устройство используется ВМ в монопольном режиме, иуправляющие воздействия, формируемые ВМ для устройства, почти не преобразуютсяCP. Однако, и в случае закрепления устройство для ВМ является виртуальным. Егоадрес в ВМ не совпадает с реальным адресом устройства, CP преобразует адресустройства в реальный, а также выполняет трансляцию адресов памяти в канальныхпрограммах, так как ВМ формирует канальную программу с адресами в своем АП. Какправило, устройства не закрепляются за ВМ постоянно, закрепление происходит принеобходимости и отменяется при окончании работы с устройством.
z/VM также широкоиспользует концепцию спулинга. Каждая ВМ имеет свой виртуальный принтер ивиртуальные устройства ввода с перфокарт и вывода на перфокарты. Физически этиустройства моделируются очередями на внешней памяти. Если очередь принтераможет быть выведена на реальное устройство, то данные из очередейперфокарточных устройств так и остаются на внешней памяти, так как реальныеперфокарточные устройства просто уже не существуют. Но эти данные могутпересылаться из выходных очередей в выходные. Механизмы спулинга используютсятакже для организации, так называемых, именованных сегментов памяти (namedstorage segment). В таких сегментах в области спулинга сохраняются многократноиспользуемые коды и данные, например, образы гостевых ОС.
Каждое реальное дисковоеустройство разделяется на несколько областей. Среди таких областей — областьсистемных данных, вторичная память страничного обмена, область спулинга иобласти минидисков — постоянных и временных. Для обеспечения ВМ внешней памятьюCP использует разделение дискового пространства. Каждая ВМ получает в своераспоряжение несколько минидисков. С точки зрения ВМ минидиск выглядит какреальное дисковое устройство с собственным физическим адресом. На самом же делеминидиск — это лишь часть дисковой памяти, выделенная для ВМ в областиминидисков на реальном диковом накопителе. Описание минидисков, принадлежащихВМ (адрес на реальном диске и размер), хранится в каталоге CP. Минидиски могутбыть доступными только для чтения или для чтения/записи и использоваться вмонопольном или совместном режиме. Обычно каждой ВМ назначается один илинесколько минидисков для монопольного использования в режиме чтения/записи, атакже разрешается доступ к нескольким минидискам, совместно используемым врежиме чтения (содержащим, например, системные утилиты, средства разработки ит.п.). Наряду с этим, ВМ может получать доступ к минидискам других ВМ — присоответствующей авторизации. Если минидиск разделяется двумя или более ВМ врежиме чтения/записи, то требуются специальные средства для предотвращенияконфликтов и потери данных. Наряду с постоянно назначенными для ВМ минидисками,для ВМ могут создаваться и временные минидиски (создаваемые в области временныхминидисков на реальном накопителе), и временные виртуальные минидиски(моделируемые буферами в памяти).
Примером еще одногоподхода к виртуализации устройств в z/VM является виртуальный адаптерканал-канал. Через этот адаптер может осуществляться взаимодействие между ВМ.Управляющие воздействия, которые ВМ формирует для виртуального адаптера, — такие же, как и для реального адаптера. Однако виртуальный адаптер неотображается ни на какое реальное устройство, он моделируется CP, а управляющиевоздействия для него интерпретируются CP с использованием буферов в памяти ипрограммных кодов.
CMS
Диалоговая управляющаясистема СMS (Conversation Monitor System) является гостевой ОС, обязательнымкомпонентом z/VM. Это интерактивная однопользовательская, однозадачная ОС,предназначенная прежде всего для разработчиков программного обеспечения иадминистраторов системы. CMS разрабатывалась именно как гостевая ОС, поэтому ейне свойственны некоторые функции, типичные для самостоятельных ОС, такие какдиспетчеризация и планирование, управление реальной памятью — эти функциивыполняет CP. CMS обеспечивает работу с файловой системой, управлениевиртуальной памятью, управление виртуальными устройствами и интерфейспользователя.
CMS не обеспечиваетмногозадачности. В программах, разрабатываемых для CMS, возможнамногопоточность, но параллельная обработка обеспечивается только на уровненитей, но не программ. Структура виртуальной памяти в CMS также очень проста.Нижнюю часть виртуального АП занимают структуры ядра CMS, создаваемые длякаждой ВМ. Выше расположено частное адресное пространство программы,выполняющейся в CMS. Верхнюю часть АП занимают объекты, совместно используемыев режиме чтения: общая для всех ВМ часть структур и кодов CMS, системаподсказки и т.п.
CMS состоит из следующихосновных частей:
терминальная система,обеспечивающая коммуникации между пользователем и ОС;
системные службы CMS, втом числе:
команды и утилиты ипакетная служба;
сервис библиотекLIBRARYAN;
сервис редактора XEDIT;
командные интерпретаторыEXEC2, CMS EXEC, REXX;
Open Extention;
файловые системы:
файловая системаминидисков;
SFS;
BFS.
CMS являетсяинтерактивной командно-управляемой ОС и обладает богатым набором команд иутилит, обеспечивающих управление файлами, выполнение программ и управлениесистемой. Хотя основной интерфейс CMS — командная строка, использование вутилитах возможностей REXX и XEDIT обеспечивает во многих случаях полноэкранныйинтерфейс взаимодействия с системой. Пользователи CMS могут также готовитьпакетные задания, для этого в их распоряжении есть специальный командный язык.Пакетные задания пересылаются серверу пакетной обработки CMSBATCH,выполняющемуся в отдельной виртуальной машине и обслуживающему пакетныхклиентов на всех ВМ системы.
Сервис библиотекобеспечивает создание и ведение библиотек макроопределений, объектных модулей изагрузочных модулей, а также загрузку и выполнение модулей из библиотек z/OS.
XEDIT являетсяполноэкранным текстовым редактором с богатыми возможностями манипулированиятекстом и форматирования экрана. Для XEDIT с помощью языка REXX могутсоздаваться сколь угодно сложные макрокоманды и профили, что позволяетиспользовать его как основу для создания интерфейсов системных ипользовательских утилит.
Наиболее развитымпроцедурным языком CMS является язык REXX. Этот язык родился именно в CMS, носейчас является обязательной составной частью любой операционной системы IBM. Вкачестве прототипа для REXX был взят язык программирования PL/1, таким образом,REXX обладает полным набором алгоритмических возможностей и возможностьювыполнять в программе команды, адресуемые операционной системе (CMS или CP) илидругой системной или прикладной среде (например, XEDIT, DB2 и т.д.). В отличиеот своего прототипа, REXX является интерпретирующим языком и в полной мереиспользует это свойство — вплоть до возможности выполнить переменную — строкусимволов как оператор программы.
Файловые системы CMS
На минидисках,предоставляемых ВМ, CMS организует файловую систему с плоским каталогом,распределением пространства блоками по 512 байт и планом размещения файлов ввиде B+-дерева. Минидиски идентифицируются буквами от A до Z, полное имя файласостоит из собственно имени, типа (аналог расширения в MS DOS, Windows илиOS/2) и идентификатора диска. Файлы CMS — записеориентированные с постояннымили переменным размером записи.
Файловая система наминидисках была первой файловой системой для CMS, однако ее существенныйнедостаток состоит в том, что дисковое пространство для минидисков ВМ должновыделяться все сразу и, таким образом, реальное дисковое пространствоиспользуется нерационально. Поэтому для CMS была разработана РазделяемаяФайловая Система SFS.
SFS обеспечиваетсовместное управление дисковым пространством для всех ВМ и динамическоевыделение внешней памяти для ВМ в пределах установленной для нее квоты.Управление обеспечивается сервером SFS, выполняющимся на отдельной ВМ иобслуживающим все остальные ВМ в системе. Для каждой ВМ сервер SFS обеспечиваетсобственную структуру хранения файлов в виде дерева каталогов глубиной до 8уровней. Корнем дерева является имя файлового пула и имя ВМ. Пользователь ВМможет давать права доступа к своим файлам и каталогам другим пользователями, втом числе, и право PUBLIC. SFS обеспечивает также алиасы и автоматическуюзащиту совместно используемых файлов от одновременной записи. Специальныекоманды CMS обеспечивают возможность представления каталога SFS как минидискаили наоборот — минидиска как каталога SFS.
Управляющие ипользовательские данные SFS располагаются на минидисках сервера SFS исоставляют файловый пул. Сервер обслуживает только один файловый пул, но всистеме может быть запущено в нескольких ВМ несколько серверов SFS. Одинминидиск сервера является управляющим, на нем находятся карты распределенияпамяти (память в SFS распределяется блоками по 4 Кбайт) и карты свободныхблоков. Один или несколько минидисков отводятся под каталог, в котором хранитсяинформация о пользователях, файлах, каталогах, алиасах и правах доступа. Минидискикаталога составляют так называемую группу памяти 1. Два минидиска отводятся поджурнал транзакций, который ведет SFS для сохранения целостности своихуправляющих данных. Эти два минидиска назначаются на разных реальных дисках ина разных контроллерах и хранят две идентичные копии журнала.
Остальные минидискисервера составляют пользовательские данные, которые для удобства управленияразбиваются на группы памяти. Всего возможно до 32К групп памяти, группы могутдобавляться к файловому пулу. Размер всех групп памяти одинаков, группа состоитиз нескольких минидисков, желательно — находящихся на разных реальных дисках.
CMS Open Extension
Чрезвычайно важнымкомпонентом CMS является Open Extension, позволяющий CMS функционировать какUnix-системе. Open Extension обеспечивает выполнение ряда спецификацийстандартов POSIX, Single Unix Specification и DCE, как в части интерпретатораshell и утилит, так и в части API и файловой системы… Для соблюдения стандартаPOSIX в иерархическую файловую систему в SFS добавлено расширение, называемоеБайтовой Файловой Системой BSF (Byte File System). BFS, в отличие от SFS,обеспечивает байориентированное представление файлов, иерархическую структурукаталогов без ограничений на глубину вложенности, связи и символьные связи,права доступа к файлам. Open Extension позволяет разрабатывать в CMSPOSIX-совместимые приложения и портировать таковые в CMS, а такжефункционировать выполняемым в CMS приложениям в гетерогенной распределеннойсреде.
GCS
Групповая УправляющаяСистема GCS (Group Control System), как и CMS, является гостевой ОС — компонентом z/VM. GCS не конкурирует с CMS, они предназначены для разных задач.Если CMS — система для поддержки интерактивной работы, разработки иадминистрирования, то GSC — среда для выполнения приложений, прежде всего — приложений, тесно взаимодействующих друг с другом и приложений в архитектуреIBM SNA (System Network Architecture).
GSC позволяет объединятьВМ в группы, управляемые общим супервизором. Все ВМ в группе используют общийзагруженный код ОС и ряда системных сервисов, а также имеют общую областьпамяти, доступную для чтения и записи.
Специфической функциейGCS в составе z/VM является является поддержка архитектуры SNA как части z/VMбез помощи какой-либо другой ОС. Эта поддержка выполняется продуктом ACF/VTAM (AdvancedCommunication Functiom/Virtual Telecommunications Access Method). Версия VTAM для GCS выполняется наодной из ВМ группы и управляет потоками данных, проходящими между сетевымиустройствами и программами, выполняющимися на других ВМ группы. VTAM такжепредоставляет сетевой интерфейс другим программным продуктам, обеспечивающимкоммуникации, таким как:
APPC (AdvancedProgram-to-Program Communications)/VM Support, обеспечивающий высокоуровневыйинтерфейс взаимодействия программ по протоколу APPC, независящий от того,являются взаимодействующие программы локальными или удаленными;
RSCS (Remote SpoolingCommunications Subsystem), обеспечивающая передачу информации через сеть SNA,работу с файлами спулинга и передачу сообщений через связи не-SNA;
NetView — средствоуправления сетями SNA.
Виртуальное АП,создаваемое GCS для выполняющихся в ней приложений, отчасти напоминает АПприложений CMS: 16-Мбайтное пространство распределяется следующим образом (отменьших адресов к большим):
управляющие блоки GCS,создаваемые для каждой ВМ;
частное АП приложений;
коды ядра общиеуправляющие блоки GCS (совместно используемые группой);
общая область данных,общие управляющие блоки GCS (только чтение);
общая область памяти(чтение и запись).
При расширении АП выше 16Мбайт в верхней части АП создаются дополнительные порции частного АП и областиданных и памяти.
В отличие от CMS, GCSявляется многозадачной ОС, поэтому задача управления памятью для нее сложнее:нужно обеспечить динамическое выделение памяти для нескольких программ и защитупамяти одной программы от другой. Для разделения областей памяти, принадлежащихразным программам, GCS использует механизм ключей защиты памяти (описанный вразделе 12.1). При запросе программы на выделение памяти GCS ищет свободнуюстраницу, ключ защиты которой совпадает с ключом программы, выдавшей запрос,при отсутствии таковой — изменяет ключ защиты любой другой свободной страницы.
GSC поддерживаетмногозадачность на одной ВМ. Следует, однако, помнить о том, что распределениепроцессорного обслуживания между программами GSC ведется в рамках того квантавремени, который выделяется виртуальной машине CP. GSC распределяетобслуживание по принципу абсолютных приоритетов, число градаций приоритета — 256(приоритет 255 — наивысший). Задача, выбранная на выполнение, вытесняетсятолько тогда, когда она переходит в состояние ожидания или в состояниеготовности приходит задача с более высоким приоритетом. Если, однако, имеетсянесколько задач с одинаковым наивысшим приоритетом, они получают обслуживание врежиме квантования времени. Приоритет задачи/подзадачи устанавливается при еепорождении и может быть изменен только явным образом — системным вызовом CHAP.Механизмы управления задачами в GCS — те же, что и в z/OS:
системные вызовы ATTACH иDETACH — для порождения и уничтожения задач;
системные вызовы WAIT иPOST и блоки ECB — для синхронизации выполнения;
системные вызовы ENQ иDEQ — для взаимного исключения доступа к ресурсам.
Linux в z/VM
В разделе, посвященномz/VM, будет уместно упомянуть и Linux for 390, и Linux for zSeries. ОС Linuxбыла портирована на мейнфреймы в рамках Advanced Technology Project, и этотпроект активно поддерживается IBM. Linux не является чисто гостевой ОС дляz/VM, эта ОС может работать и непосредственно на вычислительном комплексе,однако мощности ОС Linux, разумеется, недостаточно для управления ресурсамиполноценного мейнфрейма. Поэтому Linux применяется как самостоятельная ОС внебольшом логическом разделе мейнфрейма или (чаще всего) как гостевая ОС вz/VM. Использование Linux в таком качестве позволяет обеспечить конечныхпользователей мейнфрейма рабочими станциями, обладающими гибкостью, надежностьюи способностью работать в тесном взаимодействии с другими системами. Немаловажнымявляется то обстоятельство, что виртуальные рабочие станции Linux делаютмейнфреймы доступными для огромного числа пользователей, которые не знакомы соспецификой работы в их ОС. Поскольку ОС мейнфреймов поддерживают стандартыработы в Открытой распределенной среде, многие мощные сервисы, обеспечиваемыедругими ОС мейнфреймов, являются доступными и для виртуальных рабочих станцийLinux.
Глава 13. Платформа Javaкак операционная среда
13.1 Основные свойстваплатформы Java
Принято считать, что технологияJava зародилась в 1980 г. Она была создана группой разработчиков фирмы SunMicrosystems, инициаторами этого проекта являлись Патрик Нотон и ДжеймсГослинг. Первоначально этот проект (тогда он назывался Oak) предназначался дляуправления включением в сеть бытовых устройств со встроенными вычислительнымивозможностями. В 1995 году проект получил свое нынешнее название и былпереориентирован на программирование в Internet. В дальнейшем возможности ифункции языка и платформы Java существенно расширились. На сегодняшний деньможно назвать четыре типа программ, создаваемых в рамках технологии Java:
приложения — программы вобычном смысле, выполняемые, однако, в среде платформы Java;
аплеты — программы,выполняемые в среде Web-броузера, поддерживающего платформу Java (Sun HotJava,Netscape Communicator, Microsoft Internet Explorer), такие программы могутпередаваться по Internet и выполняться на компьютере клиента;
сервлеты и корпоративныебины — Java-программы, серверные компоненты распределенных приложений;
программы (пока для нихнет общего названия), выполняющиеся в средах продуктов промежуточногопрограммного обеспечения, например, программы для сервера приложений LotusDomino, хранимые процедуры для СУБД IBM DB2 и Oracle и т.п.
Технология Java состоитиз двух основных компонентов:
языка программированияJava [19];
платформы Java [25].
Язык программированияJava является универсальным объектно-ориентированным языком программирования,синтаксис которого очень похож на синтаксис C++. Отличия Java от С++ состоят втом, что, во-первых, Java гораздо более последовательно воплощает парадигмуобъектно-ориентированного программирования, во-вторых, в Java отсутствуютнекоторые свойства C++, делающие последний трудным для понимания и легким дляошибок (например, арифметика указателей), в-третьих, в Java введены некоторыедополнительные свойства, расширяющие его функциональность (например, нити исинхронизация). Сам по себе язык Java был бы не столь интересен (во всякомслучае, для нас), если бы не платформа Java. Платформа Java или средавыполнения Java (JRE — java runtime environment) — это набор программныхсредств, обеспечивающих выполнение Java-программы на любой аппаратной платформеи в среде любой ОС. В JRE входит виртуальная машина Java и набор стандартныхбиблиотек Java. Девиз технологии Java — «написано однажды — работаетвезде». Sun Microsystems декларирует большой набор достоинств языка иплатформы Java, но, безусловно, ключевым достоинством Java является переносимость.
Переносимость в Javaдостигается за счет того, что Java-программа компилируется не непосредственно вкоманды какой-либо конкретной ЭВМ, а в, так называемый, байт-код Java — командынекоторой абстрактной машины, называемой виртуальной машиной Java (Java VM),как показано на рисунке 13.1. Конечным результатом (исполняемым модулем)является файл класса — программа в байт-коде Java. На целевой платформе (на тоймашине, на которой программа выполняется) должна быть запущена программная JavaVM, которая эмулирует ЭВМ, способную выполнять команды байт-кода Java. СамаJava VM платформенно-зависимая, то есть, предназначена для выполнения наконкретной платформе и в конкретной операционной системе. Java VM читаеткоманды байт-кода Java и моделирует их выполнение на той аппаратной платформе ив той операционной среде, в которой она работает. При этом она используетбиблиотеки Java, также платформенно-зависимые. Стержнем технологии являютсяспецификации байт-кода Java, файла класса и Java VM. Компиляторы Java могут бытьсозданы (и создаются) разными разработчиками, но все генерируемые имиисполняемые модули должны соответствовать спецификациям байт-кода Java. Болеетого, существуют и компиляторы других языков программирования, которыегенерируют байт-код Java. Также различными разработчиками могут разрабатываться(и разрабатываются) и Java VM, но все Java VM должны выполнять стандартныйбайт-код Java.
/>
Рисунок 13.1 Выполнениеприложения в платформе Java
Итак, Java-программавыполняется в режиме интерпретации. Хотя фирма Sun Microsystems декларируетэффективность в числе основных свойств Java-программ, в отношении быстродействияэто утверждение, мягко говоря, сомнительно. Интерпретируемая программа впринципе не может выполняться так же быстро, как программа в целевых кодах.Эффективность работы Java-программ зависит от эффективности работы Java VM, иJava VM разных производителей существенно различаются по этому показателю(лидером является фирма IBM). В составе средств разработки Java имеются также«своевременные» (just-in-time) компиляторы (JIT), которые транслируютбайт-код Java в коды целевой платформы, результатом чего является исполняемыймодуль в формате целевой платформы и системы. Такой модуль выполняется безучастия Java VM, и его выполнение происходит эффективнее, чем выполнениеинтерпретируемого байт-кода, но это уже выходит за пределы платформы Java.
Таким образом,независимость Java-программ от конкретной аппаратной платформы и ОС достигаетсяза счет того, что Java-платформа является дополнительной «прослойкой»между приложением и ОС и вместо специфических системных вызовов API конкретнойОС приложение использует API JRE или базовые конструкции языка
Ниже мы рассматриваемнекоторые особенности виртуального «процессора» Java VM, как тойплатформы, на которой выполняются Java-программы.
13.2 Виртуальная машинаJava
Типы данных, с которымиработает Java VM, подразделяются на примитивные и ссылочные. Большинствопримитивных типов данных Java VM являются также примитивными типами в языкеJava. К ним относятся:
byte — 1-байтное целое сознаком;
short — 2-байтное целоесо знаком;
int — 4-байтное целое сознаком;
long — 8-байтное целое сознаком;
float — 4-байтное число сплавающей точкой;
double — 8-байтное числос плавающей точкой;
char — 2-байтный символUnicode.
В отличие от другихязыков программирования, размеры типов в языке Java и в Java VM являютсяпостоянными, не зависящими от платформы.
Java VM не оперируеттипом boolean, являющимся примитивным типом языка Java. Для выражений языка,оперирующих этим типом, компилятор Java генерирует коды, оперирующие типом int.
Примитивный типreturnAddress в Java VM не имеет соответствия в языке Java. Тип returnAddressпредставляет собой указатель на команду байт-кода Java и используется вкачестве операнда команд передачи управления.
Ссылочные типы в Java VMи в языке Java являются ссылками (указателями) на объекты — экземпляры классов,массивы и интерфейсы (экземпляры классов, реализующих интерфейсы). СпецификацииJava VM не определяют внутренней структуры объектов, в большинстве современныхJava VM ссылка на объект является указателем на дескриптор объекта, в котором,в свою очередь содержатся два указателя:
на объект типа Class,представляющий информацию типа, в том числе методы и статические данные класса;
на память, выделенную длялокальных данных объекта в куче.
Все указатели, с которымиработает Java VM, являются указателями в плоском 32-разрядном адресномпространстве, хотя в реализациях Java VM для 64-разрядных платформ могутиспользоваться и 64-разрядные указатели.
Основные области памяти,с которыми работает Java VM, показаны на рисунке 13.2.
/>
Рисунок 13.2 Основныеобласти памяти Java VM
Область памяти,называемая кучей, разделяется на две части: область классов и областьдинамически распределяемой памяти (иногда кучей называют только эту частьпамяти). Куча создается при запуске Java VM. Конкретные реализации Java VMмогут обеспечивать управление начальным размером кучи и расширение кучи принеобходимости.
Класс является основнойпрограммной единицей платформы Java, объединяющей в себе данные и методы ихобработки. При загрузке класса для него выделяется память в области классов.Каждый класс представляется двумя структурами памяти: областью методов и пуломконстант. Область методов содержит исполняемую часть класса — байт-коды методовкласса, а также таблицу символических ссылок на внешние методы и переменные.Пул констант содержит литералы класса.
В области динамическогораспределения выделяется память для размещения объектов. Управление этойобластью памяти мы рассматриваем в отдельном разделе.
Java VM поддерживаетпараллельное выполнение нескольких нитей. Для каждой нити при ее создании JavaVM создает набор регистров и стек нити.
Набор регистров включаетв себя четыре 32-разрядных регистра:
pc — регистр-указатель накоманду;
optop — регистр-указательна вершину стека операндов текущего кадра;
var — регистр-указательна массив локальных переменных текущего кадра;
frame — регистр-указательна среду выполнения текущего метода.
Стек нити представляетсобой стек в традиционном понимании, то есть, списковую структуру данных,обслуживаемую по дисциплине «последним пришел — первым ушел».Элементами стека являются кадры (frame) методов. В традиционных блочных языкахпрограммирования при помощи стека обеспечиваются вложенные вызовы процедур.Аналогичным образом Java VM через стек нити обеспечивает вложенные вызовыметодов, представляя каждый метод кадром в стеке. Новый кадр создается ипомещается в вершину стека при вызове метода. Кадр, расположенный в вершинестека является текущим, он соответствует методу, выполняемому в нити в текущиймомент. При возврате из метода его кадр удаляется из стека. Управлениеначальным размером стека нити и возможность его динамического расширениязависит от реализации Java VM. Спецификации Java VM не требуют размещения стеканити в непрерывной области памяти.
Кадр, как было сказано,создается динамически и содержит три основных области.
набор локальныхпеременных экземпляра класса, на который ссылается регистр var;
стек операндов, накоторый ссылается регистр optop;
структуры средывыполнения, на которую ссылается регистр frame.
Эти области показаны нарисунке 13.3.
/>
Рисунок 13.3 Структура исвязи кадра
Набор локальных переменныхпредставляет собой массив 32-разрядных слов. Данные двойной точности (типы longи double) занимают по два смежных слова в этом массиве. Размер этого массивафиксирован для метода, так как число локальных переменных метода становитсяизвестным уже на этапе компиляции. Операнды команд байт-кода, которые оперируютлокальными переменными, представляются индексами в этом массиве.
Java VM является стековоймашиной. Это означает, что в ней нет регистров общего назначения, и операциипроизводятся над данными, находящимися в стеке. Этой цели служит стекоперандов, выделяемый в составе каждого кадра. При выполнении команд байт-кодаJava, изменяющих данные, операнды таких команд выбираются из стека операндов, втот же стек помещаются и результаты выполнения команд.
Среда выполнения методасодержит информацию, необходимую для динамического связывания, возврата изметода и обработки исключений. Код класса (размещенный в области класса)обращается к внешним методам и переменным, используя символические ссылки. Динамическаякомпоновка переводит символические ссылки в фактические. Среда выполнениясодержит ссылки на таблицу символов метода, через которую производятсяобращения к внешним методам и переменным.
В среде выполнениясодержится также информация, необходимая для возврата из метода: указатель накадр вызывающего метода, значение регистра pc для возврата, содержимоерегистров вызывающего метода и указатель на область для записи возвращаемогозначения.
Информация обработкиисключений содержит ссылки на секции обработки исключений в методе класса.
Через среду выполнениятакже происходят обращения к данным, содержащимся в области класса, в томчисле, к константам и к переменным класса.
Команды Java VM состоятиз однобитного кода операции, а также могут содержать операнды. Число и размероперандов определяются кодом операции, некоторые команды не имеют операндов.Основной алгоритм работы Java VM сводится к простейшему циклу, приведенному нарисунке 13.4.
/>
Рисунок 13.4 Основнойцикл работы Java VM
Каждый из типов данныхJava VM обрабатывается своими командами. Основные типы команд Java VM:
Команды загрузки исохранения, в том числе:
загрузка в стек локальнойпеременной;
сохранение значения изстека в локальной переменной;
загрузка в стек константы(из пула констант).
Команды манипулированиязначениями (большинство этих операций работают с операндами из стека и помещаютрезультат в стек), в том числе:
арифметические операции;
побитовые логическиеоперации;
сдвиг;
инкремент (операцияработает с операндом — локальной переменной).
Команды преобразованиятипов.
Команды созданияссылочных данных и доступа к ним, в том числе:
создания экземпляровкласса;
доступа к полям класса;
создания массивов;
чтения в стек исохранения элементов массивов;
получения свойствмассивов и объектов.
Команды прямогоманипулирования со стеком.
Команды передачиуправления, в том числе:
безусловный переход;
условный переход;
переход по множественномувыбору.
Команды вызова методов ивозврата (включая специальные команды вызова синхронизированных методов).
Команды генерации иобработки исключений.
Принятые в спецификацияхJava VM структуры данных и алгоритмы таковы, что позволяют реализоватьвиртуальную машину с минимальными затратами памяти и сделать ее работумаксимально эффективной.
Другим ключевым элементомспецификаций Java является файл класса. Каждый файл класса описывает один классили интерфейс. Файл класса содержит поток байт, структурированный определеннымобразом. Все реализации компилятора Java должны генерировать файлы классов,структура которых соответствует определенной в спецификациях. Все реализацииJava VM должны «понимать» структуру файлы класса, соответствующуюопределенной в спецификациях.
Основные компоненты файлакласса следующие:
Некоторая верификационнаяинформация: «магическое число» — сигнатура файла класса, номерверсии.
Флаг доступа,отображающий модификаторы, заданные в определении класса (public, final,abstract и т.д.), а также признак класса или интерфейса.
Пул констант — таблицаструктур, представляющих различные строковые константы — имена классов иинтерфейсов, полей, методов и другие константы, на которые есть ссылки в файлекласса.
Ссылки на именаthis-класса и суперкласса в пуле констант.
Перечень интерфейсов,реализуемых классом (в виде ссылок в пул констант).
Описание полей класса суказанием их имен, типов, модификаторов и т.д.
Методы класса — каждыйметод представляется в виде определенной структуры, в которой содержитсяописание метода (имя, модификаторы, и т.д.), одним из атрибутов этой структурыявляется массив байт-кодов метода.
Многие компоненты файлакласса (пул констант, перечень интерфейсов и др.) имеют нефиксированную длину,такие компоненты предваряются 2-байтным полем, содержащим их длину.
13.3 Многопоточность исинхронизация
Java, по-видимому,является единственным универсальным языком программирования, в котороммеханизмы создания нитей поддерживаются встроенными средствами языка. В традиционныхязыках программирования (например, C) создание нитей обеспечиваетсясистемно-зависимыми библиотеками, обеспечивающими API ОС. В Java средствасоздания нитей системно-независимые.
В Java-программе нитьпредставляет отдельный класс, который может быть создан
либо как подкласс(наследник) суперкласса Tread;
либо как класс,реализующий интерфейс Runnable, внутри этого класса должна быть переменнаяэкземпляра класса — ссылка на объект класса Tread.
Суперкласс Tread иинтерфейс Runnable определены в базовой библиотеке языка Java — пакетеjava.lang. При любом варианте создания в классе-нити должен быть реализованметод run(). Выполнение метода start() для экземпляра такого класса вызываетвыполнения метода run() в отдельном потоке вычисления.
Как мы увидели впредыдущем разделе, Java VM обеспечивает для каждой нити собственную средувычисления — собственный набор регистров и стек (в некоторых реализациях JavaVM обеспечивает для нити также и собственную кучу).
Но Java VM не выполняетдействий по планированию нитей на выполнение. Для этого библиотечные методыJava обращаются к ОС, используя API той ОС, в среде которой работает Java VM.
Для нитей в Javaпредусмотрено управление приоритетами (методы getPriority(), setPriority()),однако, и здесь Java использует механизмы управления приоритетами ОС. Так, ужеклассическим для учебников по Java является пример аплета, в котором по экрану«наперегонки» движутся несколько объектов, движение каждогоосуществляется в отдельной нити и с собственным приоритетом. Этот пример весьманаглядно демонстрируется в средах, например, OS/2 и Linux, но выглядит не оченьубедительным в среде Windows 95/98, так как приоритет нити не слишком влияет наскорость движения объекта — примерно так, как показано на рисунке 13.5.
/>
Рисунок 13.5«Гонки» в разных операционных средах (движение справа налево).
Любая нить может бытьсделана нитью-«демоном». Нить-«демон» продолжаетвыполняться даже после окончания той нити, в которой она была создана. Нитьстановится «демоном» при ее создании только в том случае, если онасоздается из нити-«демона». Программа может изменить состояния нитипри помощи метода setDaemon() класса Thread. Выполнение любой программы Java VMначинает с единственной нити (в которой вызывается метод main()), и эта нитьзапускается не как «демон». Java VM продолжает существовать, пока незавершатся все нити не-«демоны».
В языке Java имеетсятакже класс ThreadGroup — группа нитей, которая может управляться совместно.
Если в Java предусмотренынити, то, естественно, должны быть предусмотрены и средства синхронизации ивзаимного исключения при параллельной работе нитей. Основным средствомсинхронизации и взаимного исключения в Java является ключевое слово synchronized,которое может употребляться перед каким-либо программным блоком. Ключевое словоsynchronized определяет невозможность использования программного блока двумяили более нитей одновременно. В Java synchronized-блоки называются мониторами иих фактическая тождественность мониторам Хоара, описанным в разделе 8.8 частиI, очевидна. В зависимости от деталей способа употребления synchronized можетработать как:
защищенная (guard — см.раздел 8.8 части I) процедура — в том случае, если synchronized-блокпредставляет собой целый метод, однако, в отличие от описанных намиguard-процедур одновременное вхождение в разные synchronized-методы возможно;
анонимные скобкикритической секции — в том случае, если synchronized-блок является простопрограммным блоком;
скобки критической секциис защитой выбранного ресурса — в том случае, если после ключевого словаsynchronized указывается в скобках ссылка на объект.
В первоначальной версииязыка Java для класса Thread предусмотрены методы:
resume() — приостановитьвыполнение нити;
suspend() — возобновитьвыполнение нити;
yeld() — сделать паузу ввыполнении нити, чтобы дать возможность выполниться другой нити;
join() — ожидатьзавершения нити.
Эти средства позволяютсинхронизировать работу нитей, но в следующих версиях был (наряду со старымисредствами) введен новый, более стройный аппарат синхронизации и взаимногоисключения.
Класс Object имеет триметода:
wait() — ожидатьуведомления об этом объекте;
notify() — послатьуведомление одной из нитей, ждущих уведомления об этом объекте;
notifyAll() — послатьуведомление всем из нитям, ждущим уведомления об этом объекте.
Поскольку класс Objectявляется корнем иерархии классов, объекты всех — стандартных и пользовательских- классов являются его подклассами и наследуют эти методы. Эти методыаналогичны операциям wait и signal, описанным нами в разделе 8.7 части I.Реализация, например, общего (с возможным значением, большим 1) семафора сиспользованием этих средств будет выглядеть следующим образом:
//** семафор реализуетсяв виде класса Semaphore
public class Semaphore
{
// значение семафора
private intSemaphore_value;
//** пустой конструктор семафора, поумолчанию начальное значение семафора — 0
public Semaphore()
{
this(0);
}
//** конструктор с параметром- начальным значением семафора,
// если заданоотрицательное значение, устанавливается начальное значение 0
public Semaphore(int val)
{
if (val
elseSemaphore_value = val;
}
//** V-операция. V- и P-операции объявлены synchronized,
// чтобы исключитьодновременное выполнение их двумя или более нитями
public synchronized voidV()
{
// возможно пробуждаетнить, ожидающую у семафора
if (Semaphore_value == 0)this.notify();
// увеличивает значение семафора
Semaphore_value++;
}
//** P-операция
publicsynchronized void P() throws InterruptedException
// исключение может выбрасываться вwait
{
// если значениесемафора равно 0, блокирует нить
while (counter == 0)this.wait();
// уменьшает значениесемафора
Semaphore_value--;
}
}
В Java VM с каждымобъектом связывается замок (lock) и список ожидания (wait set).
В спецификациях байт-кодаJava имеются специальные команды monitorenter и monitorexit, устанавливающие иснимающие замок. Java VM, входя в synchronized-блок, пытается выполнитьоперацию установки замка и не продолжает выполнения нити, пока операция небудет выполнена. При выходе из synchronized-блока выполняется операция снятиязамка.
Список ожиданияиспользуется методами wait(), notify(), notifyAll(). Он представляет собойсписок нитей, ожидающих уведомления о данном объекте. Названные операцииработают с этим списком очевидным образом.
Следует отметить, чтомногопоточность, заложенная в языке Java, имеет большие перспективы. Изначальносама идея нитей (а ее первая коммерческая реализация была сделана именно фирмойSun Microsystems) возникла как решение, призванное обеспечить эффективнуюзагрузку оборудования в многопроцессорных системах, но теперь свойствамногопоточности, закладываемые в программное обеспечение, оказывают (наряду сдругими факторами) обратное влияние на процессорные архитектуры, стимулируяразвитие в них средств распараллеливания вычислительного процесса.
Так, новый проекткомпьютерной архитектуры фирмы Sun Microsystems носит название MAJC(Microprocessor Architecture for Java Computing — архитектура микропроцессорадля Java-вычислений), которое говорит само за себя. В концепцию этойархитектуры (как, впрочем, и ряда других новых архитектур) входитмногопроцессорная обработка с несколькими «потоковыми устройствами» вкаждом процессоре. Такая архитектура призвана обеспечить более эффективнуюобработку на сетевом сервере современных потоков данных, которыехарактеризуются возрастанием удельного веса в них мультимедийной информации.
Для получения лучшейпроизводительности, кроме многопоточных микропроцессоров, разработчики MAJCприменяют технологию, называемую «пространственно-временнымивычислениями» или «предположительной многопоточности». В этойтехнологии прикладной программист вообще не будет беспокоиться ораспараллеливании своих программ, потому что эта работа будет сделана за негоJava VM.
Смыслпространственно-временных вычислений сводится к следующему. Java VM проверяетпрограмму и предполагает, что два метода могут выполняться одновременно на двухпроцессорах. Она посылает метод A на первый процессор, а метод B — на второйдля предположительного вычисления. Поскольку B — предположительный метод, онвыполняется в отдельном адресном пространстве, называемом предположительнойпамятью. Если все идет хорошо, и никакие зависимости в данных не нарушены, топредположительная память сливается с основной памятью и программа обрабатываетследующую пару методов. Если произошло нарушение, то второй метод отменяется ипредположительная память «выбрасывается».
Идеяпространственно-временных вычислений не является кардинально новой, но она неприменялась в обычных многопроцессорных системах без многопоточности, так какпозволяла увеличить эффективность выполнения программ в 2-процессорнойконфигурации не более, чем на 5%. Разработчики MAJC рассчитывают, что в ихархитектуре производительность последовательных приложений на двух процессорахдолжна возрасти в 1.6 раза.
13.4 Управление памятью вкуче
Управление памятьюотносится к числу тех свойств языка Java, которые заложены в само его ядро инепосредственно обеспечиваются Java VM. Особенностью управления памятью в Javaявляется то, что с точки зрения прикладного программиста его практически нет.Память для данных примитивных типов выделяется в области локальных переменныхкадра. Кадр для метода выделяется только на время выполнения метода, призавершении выполнения память кадра освобождается, а следовательно, иосвобождаются и все локальные переменные. Этот механизм подобен размещениюлокальных переменных в стеке в традиционных блочных языках программирования(C/C++, PL/1 и т.д.). Ссылочные типы состоят из двух частей: ссылки на объект исобственно тела объекта. Массивы в Java также являются ссылочным типом, и все,что далее говорится про объекты, справедливо и для массивов. Ссылкапредставляет собой адрес памяти, указатель на объект в терминах языка C/C++, нов отличие от C/C++, адресная арифметика в Java не разрешена. Объект в программедоступен только через переменную, являющуюся ссылкой на него.
Итак, память, выделяемаядля ссылок, управляется автоматически, как и память для примитивных типов.Иначе обстоит дело с памятью, выделяемой для тела объекта. В языке Java имеетсяоперация new, которая явным образом выделяет память для тела объекта ивозвращает ссылку на созданный объект. Память для каждого объекта выделяетсяявным образом, при помощи этой операции. Создание новых объектов возможно такженеявным образом — некоторые библиотечные методы создают (при помощи той жеоперации new) новый объект и возвращают ссылку на созданный объект. На этом«заботы» прикладной Java-программы об управлении памятьюзаканчиваются. Программа не освобождает выделенную память, это делает за нееJava VM. Автоматическое освобождение памяти, занимаемой уже ненужными(неиспользуемыми) объектами, — одна из наиболее интересных особенностейплатформы Java. Это освобождение выполняется в Java VM программным механизмом,который называется сборщиком мусора (garbage collector). Но что такоенеиспользуемый объект? Программа может «оставить объект в покое» надолгое время, а потом вдруг вновь вернуться к нему. Время обращения к объекту(как это делается в дисциплине управления памятью LRU) не может служитьпоказателем ненужности объекта. Сборщик мусора считает неиспользуемыми теобъекты, на которые нет ссылок. Если в программе нет ссылки на объект, топрограмма принципиально не может обратиться к объекту, следовательно, объектпредставляет собой мусор. Обратите внимание на то обстоятельство, что привыходе из блока, в котором был создан объект, освобождается память, занимаемаяссылкой на объект, но это еще не значит, что объект сразу же становитьсямусором. Ссылка на созданный объект может быть присвоена внешней по отношению кданному блоку переменной или быть возвращаемым значением метода. Если же этогоне происходит, то объект действительно становится мусором. При выполненииJava-программы такой мусор в памяти накапливается. Многие методы библиотечныхклассов Java (например, класса String) построены таким образом, что ихиспользование способствует интенсивному накоплению мусора в памяти.
Когда накопление мусораприводит к нехватке памяти, вступает в действие сборщик мусора. Для обеспеченияработы сборщика мусора в дескрипторе каждого объекта имеется «признакмусора». При создании объекта «признак мусора» устанавливаетсяво взведенное состояние. Алгоритм работы сборщика мусора (один из еговариантов) состоит из двух фаз:
Фаза маркировки. Сборщикмусора просматривает области локальных переменных всех активных в настоящиймомент методов, а также поля всех доступных объектов. В дескрипторах техобъектов, на которые есть ссылки в просмотренных областях «признакмусора» сбрасывается
Фаза очистки.Просматривается область кучи, дескрипторы всех объектов. Те объекты,«признак мусора» которых оказывается взведенным (не был сброшен вфазе маркировки), являются мусором, занимаемая ими память освобождается. У техже объектов, «признак мусора» которых сброшен, этот признак взводится- для подготовки к следующей сборке мусора.
Затраты на выполнениесборки мусора практически не зависят от количества мусора — в любом случаетребуется полный просмотр и областей локальных переменных, и кучи.Следовательно, сборку мусора выгоднее производить только в те моменты, когдамусора накопится много: в этом случает при тех же затратах будет полученбольший результат. Поэтому операция сборки мусора может создавать некоторуюпроблему при выполнении Java-программ. Проблема состоит в том, что моментактивизации сборщика мусора непредказуем, а когда такая активизация произойдет,она вызовет задержку в вычислениях. В новых реализациях Java VM эту проблемустараются если не решить кардинально, то несколько сгладить, запуская сборщикмусора в отдельной низкоприоритетной нити.
Хотя область методов тожеформально принадлежит куче, в большинстве современных Java VM сборщик мусора вэтой области не работает.
13.5 Защита ресурсов
Поскольку одной изосновных сфер применения технологии Java является Internet, вопросыбезопасности для этой технологии приобретают особое значение. Безопасность всетевой среде представляет собой целый комплекс сложных вопросов,рассматриваемых в отдельном курсе. Здесь же мы уделим основное внимание защителокальных ресурсов — анализу возможности Java-программы получить несанкционированныйдоступ к ресурсам на том компьютере, на котором она выполняется.
Прежде всего, в самихязыковых средствах Java отсутствуют некоторые возможности языка C/C++, которыенаиболее часто приводят к неправильному использованию ресурсов — случайному илинамеренному. Главная черта языка Java в этом отношении — отсутствие указателей.Хотя доступ к объектам в Java осуществляется по ссылкам, и физический смыслссылки и указателя C/C++ одинаков — адрес памяти, ссылка не есть указатель.Различие состоит в том, что, во-первых, ссылка не может быть преобразована вчисло или какое-либо иное представление физического адреса, во-вторых, надссылками недопустимы арифметические операции. Именно адресная арифметика вC/C++ является средством, использование которого может привести к доступупроцесса за пределы той области памяти, к которой он имеет право обращаться.
Другой«лазейкой» для выполнения несанкционированных действий в языке C/C++является слабая защита типов. C/C++ позволяют использовать типы данных воперациях, этому типу не свойственных — путем неявного преобразования типов илипутем приравнивания разнотипных указателей (в том числе, и для интегрированныхтипов). В Java осуществляется строгий контроль типов и в большинстве случаевтребуется явное преобразование типов.
Автоматическоеосвобождение памяти в Java также является свойством, повышающим защищенность.Можно говорить также и о том, что более последовательное воплощение в Javaпарадигмы объектно-ориентированного программирования также является выигрышнымобстоятельством с точки зрения защиты.
Следует оговорить, чтоуказанные различия между языками C/C++ и Java обусловлены прежде всего тем, чтоязыки ориентированы на разные сферы применения. Те «недостатки» языкаC/C++, на которые мы указываем, превращаются в уникальные достоинства приприменении С/С++ в качестве языка системного программирования, а именно таковопервоначальное предназначение этого языка. При разработке же приложений (а Java- язык именно для разработки приложений) эти возможности становятся ненужными идаже опасными.
Однако сами свойстваязыка Java еще не являются гарантией защищенности. Они обеспечиваютсякомпилятором Java, но не предохраняют от модификации исполняемый модуль.Поскольку спецификации байт-кода Java и файла класса открыты, программы,осуществляющие несанкционированный доступ, могут писаться непосредственно вбайт-кодах или на других языках с компиляцией в байт-код Java. Чтобы перекрытьэтот канал несанкционированного доступа, в платформе Java выполняетсяверификация байт-кода.
Процесс верификациисостоит из четырех шагов.
Шаг 1 выполняется призагрузке класса. При этом Java VM проверяет базовый формат файла класса — «магическое число» и номер версии, соответствие размера файласуммарному размеру его составляющих, формальное соответствие отдельных структурспецификациям.
Шаг2 выполняется присвязывании, он включает в себя верификацию без анализа байт-кодов. На этом шагепроверяется:
отсутствие нарушений виспользовании классов и методов, объявленных с модификатором final;
наличие у каждого класса(кроме класса Object) суперкласса;
соответствиеспецификациям содержимого пула констант;
правильность имен классови интерфейсов и дескрипторов всех полей и методов, ссылающихся на пул констант.
Проверки правильностиэлементов файла класса, выполняемые на этом шаге, — только формальные, несемантические. Более подробные проверки выполняются на следующих шагах.
Шаг 3 также выполняетсяна этапе связывания. На этом шаге верификатор проверяет массив байт-кодовкаждого метода. При этом анализируется поток данных, обрабатывающийся привыполнении метода. Верификатор исходит из того, что в любой точке программы,независимо от того, каким образом управление попало на эту точку, должнысоблюдаться определенные ограничения целостности данных, которые сводятся восновном к следующим:
размер стека операндовнеизменен и стек содержит операнды одного типа;
не выполняется доступ клокальным переменным неизвестного типа;
доступ к локальнымпеременным осуществляется только в пределах массива локальных переменных;
все обращения к пулуконстант производятся к элементам соответствующего типа;
полям класса назначаютсязначения соответствующего типа;
все команды байт-кодаиспользуются с операндами (в стеке или в массиве локальных переменных) типа, соответствующеготипу команды;
методы вызываются справильными аргументами;
команды перехода передаютуправление только внутри байт-кода метода и передача управления всегдапроисходит только на первый байт команды байт-кода.
Шаг 4 выполняется припервом вызове кода любого метода. Это «виртуальный шаг», онвыполняется не в виде отдельного шага проверки всего байт-кода, а привыполнении каждой отдельной команды.
Для команды, котораяссылается на тип, при этом:
загружается определениетипа (если оно еще не загружено);
проверяется, может литекущий выполняемый метод ссылаться на этот тип;
выполняется инициализациякласса (если он еще не инициализирован).
Для команды, котораявызывает метод или осуществляет доступ к полю класса, при этом:
проверяется, существуетли поле или метод в данном классе;
проверяется правильностьдескриптора вызванного метода или поля;
проверяется, имеет литекущий выполняемый метод права доступа к этому методу или полю.
В конкретных реализацияхJava VM допускается после выполнения шага 4 заменять проверенную командубайт-кода альтернативной «быстрой» формой. Например, в Sun Java VMкоманда байт-кода new может быть заменена командой new_quick.«Быстрая» команда выполняется так же, как и исходная, но при ее выполненииисключается повторная верификация команды. В файле класса «быстрые»команды не допускаются, они выявляются на предыдущих шагах верификации ивызывают отказ. «Быстрые» формы не являются спецификациями Java, ониреализуются в конкретной Java VM.
Аплеты являются наиболеекритическими с точки зрения безопасности Java-программами, поскольку аплетзагружается из Internet, возможно, из непроверенного источника. Естественно,недопустимым является предоставление программе, пришедшей «неизвестнооткуда» доступа к ресурсам локального компьютера. Поэтому для аплетоввведены весьма жесткие ограничения на выполнение. Аплету запрещается:
получать сведения опользователе или его домашней директории;
определять свои системныепеременные;
работать с файлами идиректориями на локальном компьютере (читать, изменять, создавать и т.д. и дажепроверять существование и параметры файла);
осуществлять доступ посети к удаленному компьютеру, получать список сетевых сеансов связи, которыеустанавливает локальный компьютер с другими компьютерами;
открывать без уведомленияновые окна, запускать локальные программы и загружать локальные библиотеки,создавать новые нити, получать доступ к группам нитей другого аплета;
получать доступ к любомунестандартному пакету, определять классы, входящие в локальный пакет.
Модель безопасности Javaеще далека от совершенства, и в ее реализациях иногда обнаруживаются«лазейки» для несанкционированного проникновения. Следует отметить,что в сетевых публикациях довольно часто можно встретить критику безопасности вJava и предупреждение о принципиальной возможности «взлома» защитыJava тем или иным способам. Вместе с тем, сетевые публикации не дают основанийговорить о том, что реальные информационные системы, в которых применяетсятехнология Java, чаще подвергаются взлому, чем системы, эту технологию неприменяющие.
13.6 JavaOS и Java длятонких клиентов
В конце 90-х годов фирмаSun Microsystems предприняла разработку новой ОС, базирующейся на технологииJava — JavaOS. Для доводки этой ОС фирма Sun привлекла фирму IBM, и конечныйпродукт JavaOS является собственностью обеих этих фирм.
JavaOS являетсяоперационной системой для широкого спектра вычислительных средств, включаясетевые и встроенные компьютеры. Целью разработки этой ОС являлосьпредоставление среды для выполнения Java-приложений без использования базовойуниверсальной ОС.
JavaOS строится попринципу многослойной архитектуры, показанной на рисунке 13.6, включающей всебя платформенно-зависимую и платформенно-не
/>
Рисунок 13.6 АрхитектураJavaOS
Платформенно-зависимаячасть состоит из загрузчика, микроядра, виртуальной машины Java и частично — среды выполнения Java (JavaOS Runtime Environment).
Функции загрузчикавытекают из его названия. JavaOS ориентирована прежде всего на клиент/сервернуюмодель вычислений. Это означает, что необходимое программное обеспечение,постоянно хранящееся на клиентской стороне — минимальное, загрузчик исоставляет тот необходимый и достаточный минимум программного обеспечения,который обеспечивает загрузку всего остального программного обеспечения ссервера.
Микроядро JavaOS оченьпохоже на микроядра ОС, рассмотренных нами выше (QNX, AMX RTOS и др.). Оновыполняет функции:
обработки прерываний иисключений;
поддержки множественныхнитей;
поддержкимногопроцессорных конфигураций;
управления реальнойпамятью;
управления реальнымиустройствами и каналом ПДП.
JVM обеспечивает:
интерпретацию байт-кода;
управление выполнением;
управление памятью;
нити;
загрузку классов;
верификацию байт-кода.
Программное обеспечениесреды выполнения Java частично создается в кодах Java, частично — в«родных» (native) кодах целевой платформы. В состав среды выполнениявходит JVM и ряд системных менеджеров, в том числе:
Менеджер Конфигурации,представляющий собой первый класс, Java-кода, выполняемый JVM, он обеспечиваетзапуск компонентов Менеджера Платформы и дополнительных сервисов JavaOS;
Менеджер Платформы,обеспечивающий запуск и поддержку компонентов, обслуживающихплатформенно-зависимые устройства и шину ввода-вывода платформы;
Менеджер Сервисов, пакет,обеспечивающий поиск и запуск сервисных утилит JavaOS;
Менеджер Устройств,компонент, обеспечивающий архитектуру Java-интерфейса устройств (JDI);
Классы Java-интерфейсаплатформы (JPI), инкапсулирующие драйверы JDI и решение платформенно-зависимыхвопросов, включая управление временем, памятью и прерываниями.
Дополнительные(опционные) компоненты среды выполнения включают в себя компоненты конфигурации(персональной, сетевой, встроенной), наборы драйверов и средства отладки.
Вся среда выполнения(включая JVM) работает как один процесс в виртуальном адресном пространстве.Соответствие виртуального адресного пространства физической памятиобеспечивается микроядром. Также микроядро обеспечивает использованиемногопроцессорной архитектуры вычислительной системы для функционирования средывыполнения и приложений. Вся специфика управления процессорами и памятьюинкапсулирована в JPI.
Большая часть драйверовустройств JavaOS пишется на языке Java. Платформенная независимость драйверовподдерживается компонентом JDI, который состоит из:
Менеджера Событий,обеспечивающего взаимодействие с устройствами по событийной модели;
Системной Базы Данных,обеспечивающей хранение и получение конфигурационной информации (относящейся кОС, устройствам и приложениям) в едином репозитории;
платформенно-зависимыхблоков драйверов;
Менеджера Шины.
Следующий, полностьюплатформенно-независимый уровень составляют сервисы JavaOS, такие как: классы,обеспечивающие базовую графику, ввод-вывод и сетевые коммуникации дляплатформы.
Более высокие уровнисоставляют стандартные пакеты Java, пакет расширенного графического интерфейсаSwing и, наконец, пользовательские приложения.
К сожалению, JavaOS«не успела» на рынок тонких клиентов, к тому моменту, когда эта ОСпоступила в продажу, рынок мобильных клиентов, на который она моглапретендовать, был уже занят, в основном, Windows CE, также сложились уже иоперационные среды для сетевых компьютеров, например, IBM Workspace on Demandдля OS/2 и Windows. Поэтому фирмы-производители «законсервировали»проект и его конечный продукт — JavaOS — не представлен на рынке.
Опыт разработки JavaOSфирма Sun Microsystems использовала для создания концепции EmbeddedJava [17].Технология EmbeddedJava является надстройкой над ОС (любой ОС) тонкого клиентаи включает в себя JVM и библиотеку классов Java. Отличие от базовой технологииJava состоят в том, что и JVM, и библиотека классов являются конфигурируемыми,то есть, их объем минимизируется таким образом, чтобы в них включались толькоте свойства, которые необходимы и достаточны для выполнения Java-приложенийконкретного тонкого клиента. Фирма Sun обеспечивает набор инструментальныхсредств для создания такой компактной прикладной среды, в состав которыхвходят:
JavaFilter — инструментдля выявления тех классов, полей и методов, которые необходимы дляфункционирования приложения;
JavaCodeCompact — инструмент для оптимизации кода приложения для экономии RAM- и ROM-памяти;
JavaDataCompact — инструмент для компактного представления внешних по отношению к приложениюданных.
После определениянеобходимых компонент и создания компактных кодов и данных приложение совместнос компонентами среды выполнения компилируется в коды целевой платформы(native-коды), которые могут быть помещены в RAM- или ROM-память«тонкого» устройства. Общий ход процесса разработки приложенияEmbeddedJava показан на рисунке 13.7.
/>
Рисунок 13.7 Процессразработки приложения EmbeddedJava
13.7 Перспективытехнологий Java
Технологии Java были наподъеме несколько последних лет, можно предполагать, что их интенсивноеразвитие и влияние на другие информационные технологии — явлениедолговременное. В настоящее время стандарты технологий Java открыты, в ихразвитии, наряду с Sun Microsystems, активно участвуют ведущие производителирынка информационных технологий (IBM, Hewlett-Packard, Oracle и другие). ФирмаMicrosoft, хотя и производит конкурирующие технологии, также вынужденасчитаться с технологиями и стандартами Java. В условиях распространения средысетевых вычислений технология Java является одним из главных средствобеспечения совместной работы в глобальном информационном пространствеаппаратных и программных средств от разных производителей. Другим такимсредством, обеспечивающим совместимость по данным, является язык XML, с которымJava сейчас интегрируется (стандарт Java Standard Extension for XML).
Первый успех технологийJava был обеспечен прежде всего аплетами, то есть, программами, выполняющимисяна удаленном клиенте. Нынешнее же развитие и перспективы этих технологийсвязаны в основном с серверным программным обеспечением. Основные стандартыэтого направления: Enterprise JavaBeans (EJB) — компонентная архитектурапостроения расширяемых, многоуровневых, распределённых приложений для серверови Java 2 Platform, Enterprise Edition (J2EE), расширение возможностеймежплатформенной переносимости EJB. Важной является также достигнутаясовместимость Java с реляционными базами данных (стандарты SQLJ и JDBC,развиваемые под эгидой ISO).
Развитие«тонких» клиентов сети заставляет технологии Java вновь обратиться и«истокам» (проект Oak) — построению программного обеспечения длянеполнофункциональных клиентских устройств. Поскольку «тонкие»клиенты отличаются большим разнообразием аппаратных и программных платформ,именно Java может стать той технологией, которая позволит таким клиентаминтегрироваться в глобальное информационное пространство. Технология Jini,которая базируется на Java-технологии, позволяет работать с любыми устройствамии отказаться от традиционного использования разнообразных драйверов,громоздкого системного программного обеспечения, привязанного к аппаратнымплатформам и не позволяющего устройствам взаимодействовать в гетерогенной сети.Jini — это сетевая инфраструктура, набор соглашений, специфицирующих методыавтоматического взаимодействия и регистрации устройств, подключаемых к сети.
Таким образом, не исключено,что ближайшие годы развития информационных технологий пройдут «подзнаменем» технологий Java.