"Зачем?", "Почему?", и "Куда?" или Всякое разное про операционные системы. Часть 2
АрхивТехнологизмы (архив)Самое страшное преступление в области компьютерных технологий или "Всепланетное единое адресное пространство".
Этот текст был написан автором после того, как в одном из наших форумов я увидел постинг с призывом принять участие в разработке новой ОС и предложил автору выразить свои мысли в форме статьи. Поэтому, если Вы разделяете взгляд автора, то свяжитесь с ним — возможно это приведет к новым интересным разработкам.
wsDmitry
Так чего это я всё про взаимодействие, да взаимодействие? Просто, никому не нужна программа сама в себе. Если она ничего не вводит и ничего не выводит, то следует задуматься, зачем она тратит процессорное время? Раз уж всё идёт к тому, что драйверы выравниваются с обычными программами, то выходит только два типа взаимодействия:
Передача сообщений — это единственный способ взаимодействия, когда виртуальные адресные пространства приложений изолированы друг от друга, то есть ни одна логическая страница первого адресного пространства не отображается в ту физическую (в ОЗУ, ПЗУ, диске или ещё где) страницу памяти, в которую отображена хотя бы одна логическая страница второго адресного пространства. Есть существенный недостаток этого метода: информацию нужно копировать. Во многих случаях это существенные затраты. Вот пример: есть у меня мой любимый текстовый редактор, любимый графический, и любимый web-браузер. И хочется мне редактировать текст страницы, и рисовать для нее картинки, да так, чтобы стразу видеть результат своих трудов в этом браузере. Уважаемые господа — любители Windows. OLE не подходит, потому что я не хочу редактировать всё в одном месте, а хочу редактировать в местах разных, да ещё не в режиме «отредактировал — посмотрел», а «редактируй и смотри» (WYSIWYG). Если у меня есть только передача сообщений, то с текстовым редактором совладать можно: тексты хорошо архивируются или занимают мало памяти. А вот с картинкой дела обстоят гораздо хуже. Ладно если я поменял немного пикселей, а вот если я применил фильтр какой-нибудь? Браузер-то фильтрами не занимается, поэтому придётся перекачать ему всю картинку. А это несколько мегабайт. Конечно, с точки зрения человека — это мгновенно, но сколько бы уравнений решила бы за это время Ваша любимая seti@home?
В подобных случаях помогает общая память. Чтобы не мучить себя и процессор надо поместить картинку и html-текст в ту память, которая отображена через страницы в адресные пространства всех трёх приложений. Тогда все изменения сделанные редакторами сразу будут заметны браузеру. При этом экономиться память. Браузеру не нужно хранить копию картинки и текста. Но не всё так просто. Хотя Windows и Linux поддерживают этот механизм, делают они это с большой натугой, ибо каждое приложение имеет своё адресное пространство. И когда нужно корректировать те вхождения таблицы страниц, например, при подкачке, которые отображаются в эту общую память, приходится делать это во многих таблицах и постоянно пересчитывать адреса. Это действительно проблематично, поэтому в Windows NT общая память в таких пертурбациях, как подкачка не участвует.
Несмотря на всё это, общая память для локальной машины (как и для кластера) — вещь нужная и важная. Ещё бы — самый быстрый обмен (на локальной машине) и экономия пресловутой субстанции под названием RAM. Поэтому в этом направлении работали. И вот, что выдумали: если у каждого приложения своё адресное пространство, то делать общую память неудобно? Неудобно. Поэтому сделаем одно адресное пространство для всех приложений, то есть пусткай логические адреса во всех приложениях одинаково отображаются на физические. Если раньше инструкция "сохрани содержимое регистра X в ячейке памяти с адресом A" для одного приложения означала обращение к ячейке физической памяти B, а для другого — к C, при этом B не обязательно совпадало с C, то в новой архитектуре предполагалось, что в обоих приложениях произойдёт обращение к ячейке с одинаковым физическим адресом. Теперь всё адресное пространство — общая память, надо только научиться его защищать, то есть надо уметь разрешать или запрещать доступ к различным областям памяти различным приложениям. Это оказалось не так уж и сложно. Системы реализованы. Есть два замечательных проекта (их, на самом деле, больше, но эти, по мнению экспертов, наиболее удачные). Один на базе L4 — mungi, второй — на базе mach, имя ему opal. Но это не всё: в обоих системах эта общая память ещё распределённая и является единственным местом, где информацию можно хранить. То есть нет никакой файловой системы, удалённых дисков и прочего добра, есть только память. Связано это горе с тем, что делались системы для машин с 64-разрядным адресом. Давайте немного посчитаем. 2 в степени 64 байт — это столько, что записывай мы по гигабайту в секунду, нам понадобиться 544 года, чтобы израсходовать всё место. Поэтому можно использовать 64-битный указатель для обращения ко всем объектам в локальной сети (в смысле, лимит не будет исчерпан за пять лет, а там и 128 бит появиться). На практике это означает следующее: если по адресу 23425234 у Вас лежит любимая процедура распознавания образов, то можно её вызвать из любой программы, написав инструкцию вроде call 23425234, передав ей загадочное число 63456 — адрес по которому находится Ваша любимая картинка (для любой программы по этому адресу будет лежать эта картинка). Если страница, на которую ссылается этот адрес, у вас в локальной памяти, то произойдёт обычный вызов. Если её нет, если она затерялась в просторах сети или на диске, то механизм подкачки её найдёт и загрузит в память. Примерно то же самое произойдёт при считывании из памяти картинки. И никакой явной загрузки библиотек. Вот так. И это работает. И работает быстрее, чем обычные ОС по словам разработчиков и результатам прогонки бенчмарков. При этом, разработчикам пришлось решить ещё одну проблему: если вы выключили ваш кластер, то включив его, вы должны обнаружить всю вашу любимую картинку всё там же, по адресу 63456. Они эту проблему решили, да так, что для системы почти безразлично, как её выключили. То есть после сбоя система оказывается в том состоянии, в котором она была за несколько секунд до сбоя. Какой именно механизм используется в mungi или opal, я не могу сказать. Разработчики не распространяются, а обещанные исходники mungi до сих пор недоступны, зато один из подобных механизмов — checkpoint persistance — реализован в EROS. Эти чудеса программистского маразма (с уважением и почтением сказано) носят гордое название Single Address Space Operating Systems (SASOS). И похоже, что мир катится именно к ним. Так, Intel в IA-64 предусмотрела специальные механизмы для облегчения тяжкого труда ядер подобных систем (раздел 16, Intel IA-64 Software Developer's Manual, Volume 2, IA-64 System Architecture ). А на архитектурах типа PowerPC и Alpha эти ОС живут превосходно. Кроме того, есть проект Sombrero, и, судя по огромному количеству документации в ppt файлах, к которой ведут ссылки со страницы этого проекта, и по тому, что проект выполнен для Windows NT, Microsoft тоже подумывает об обкатке новых идей. Эх! Скоро я буду наслаждаться своим текстовым редактором на тройку с графическим и веб-браузером. Впрочем, мы сами с усами и "мелкуюмяготь" ждать не хотим!
Про кластеры. Как это ни странно, но системы с распределённой памятью оказались более эффективными, чем системы с передачей сообщений. Никто толком не может сказать почему, но проект munin это доказал на практике.
По моему, причина вот в чём. Предположим, вы решает некоторую задачу по физике с некоторым коллективом, сидя в разных комнатах. У вас есть чертёж, на котором необходимо нарисовать все действующие на систему силы. Что проще? Иметь у каждого по чертежу, и когда придёт в голову мысль об очередном векторе, рассказывать о том, как его нарисовать, по телефону, например. Или иметь один чертёж, и когда в голову приходит мысль о новом векторе просто рисовать его на доске, дождавшись, когда её вам принесут? Не знаю. Но на общей доске можно проводить некоторые выкладки, которые будут заметны всем. И если народ понимает о чём идет речь, то Вам не обязательно чётко и до конца сформулировать свою мысль, о ней догадаются по вашим выкладкам. Я к тому, что при использовании общей памяти, не обязательно формулировать конечные сообщения. Более компьютерно: например, при отрисовке 3D сцены при помощи openGL Вам нужно сформировать сцену, а потом, выдать команды драйверу (что вызовет двойное копирование данных сцена —> драйвер —> видеокарта). Но что нам мешает договориться о структуре сцены? Почему не формировать сцену в указанном формате, а драйверу самому решать, что передавать карте, а что нет (при этом исключается столь ненавистное копирование Мне скажут, что вместо него появляется анализ информации, что же, да, но сравните тактовую частоту процессора и памяти!)? Прямо чувствую, что найдётся какой-нибудь ортодоксально настроенный поклонник ООП (чувствую, потому что когда-то был таким сам) и заявит, что связывание по данным — самое страшное преступление в области компьютерных технологий. Что же. Немного пересмотрим наш пример. Путь теперь физики сидят в одной комнате. Что проще? Придумав новый вектор, втихомолку нарисовать его у себя на private-доске, а потом через public-воздух каждому коллеге сообщить о своей гениальной идее. Или просто рисовать на общей доске? Здесь я утверждаю, что последнее не только проще, но и эффективнее.
Третье. Одиночество. Так уж получилось, что раньше у каждого пользователя компьютера была одна программа, просто работать со многими одновременно он не мог эффективно. Поэтому ОС и строились на принципах изоляции одной программы от другой. Строились они строились, программисты ничего другого думать не хотели. Вот так и дожили мы до монстров в виде Ворда, а через монструозные программы дожили мы до ООП.
Принцип изолированности всему причина. Я не говорю, что это плохо. Если у Вас такая ситуация, что Вы обязаны в хакерстве подозревать всех, в том числе и самого себя, а это вполне реальная ситуация (по крайней мере именно такой расклад вещей пытаются внедрить в наши неокрепшие умы преподаватели по компьютерной безопасности), то Вам ничего не остаётся кроме того, чтобы изолировать каждую программу от других. Это норма, потому что информацию можно передавать и через структуру доступного адресного пространства. А что если это не так? Например, сохранять конфиденциальность мне нужно только для пары строчек — логина и пароля для доступа в Интернет, зато мне хочется, да, именно этого — браузера и двух редакторов, для текста и картинок, причём от разных производителей, потому что один всё это одновременно хорошо не напишет. Я уже указал, как это можно сделать. Но то, что я рассказал, невозможно сделать, если приложение будет "думать", что оно одно в системе, потому что нужно будет хотя бы договориться о том, где нужный текст и картинки расположены в памяти. А чтобы об этом договориться надо знать с кем договариваться. Таким образом нужен механизм для того, чтобы программа могла понять, в какое окружение она попала. На самом деле это хоть и даёт скрытый канал утечки информации, но помогает поднять уровень защищённости. Вот пример, если бы программа, работающая с супре-пупер секретными данными могла узнать, существует ли в системе приложение, которое имеет доступ к сети, то она могла бы "испугаться", не запуститься и не начать дешифрование, предполагая, что подобная программа вполне может быть хитрой закладкой, которая может пролезть в память данной программе, и выкачать расшифрованные данные. Вот так. И потом, сможете ли вы эффективно работать с людьми, если можете общаться только с помощью открывания и закрывания век? При чём здесь люди? А вы наблюдали когда-нибудь, как программисты объясняют то, как работает программа? Обычно они говорят о том, что она делает от первого лица! Наверное, это естественно, потому что программирование — это изложение своих мыслей, пусть в контекстно-свободном виде.
В той же Windows можно очень много узнать о компьютере: сколько памяти, какие PCI-карты есть, и т.д. А вот получить информацию о том, сообщения от каких приложений находятся в очереди — нельзя. А ведь это могло бы помочь: проанализировав этот список, можно было бы решить на какие отвечать, а на какие — нет.
Четвёртое. Синхронизация. Единственная область, где менять ничего не надо. Потому что умные люди давно придумали "мутекс" или "простой семафор". С помощью него можно создать любой механизм синхронизации, даже упорядоченный. Поэтому в этой области никто ничего и не меняет, кроме как ускорения работы этих семафоров. Впрочем, они и так уже требуют не более трёх инструкций для своей реализации.
Так что же нас ждёт? Всепланетное единое адресное пространство (когда процессоры станут 512 разрядными), в котором мы будем парить с помощью наноядер (потому, что микроядра предоставляют избыточный интерфейс для реализации SASOS) как птицы и синхронизироваться токмо с помощью мутексов (что, в принципе, возможно — возьмите хотя бы кластеры, кажущиеся прикладному программисту одной машиной и предоставляющие ему возможность обмена информацией между программами) и не будет нигде никаких объектных интерфейсов, потому что не будет самих объектов, потому что структура информации будет известна, потому что всё будет храниться в виде XML…
PS: много ссылок на сайты разработчиков операционных систем можно найти на dmoz.org/Computers/Software/Operating_Systems.
