Файл: Сетевые операционные системы (История).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 03.07.2023

Просмотров: 231

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Одна этих структур является стеком который разделяется C и S и отображается в оба пространства для и записи. Для сервера нить C аргументы в разделяемый используя обычную передачи параметров, а прерывает ядро, данный ей в регистр. По идентификатору ядро что вызов локальным. (Если он был то ядро бы его способом для вызовов.) Затем выполняет переключение адресного пространства в адресное пространство и запускает в рамках нити требуемую сервера. При способе вызова уже загружены в место, так копирование или аргументов не требуется. Главный - локальный вызов - будет выполнен способом гораздо быстрее.

Другой широко используется ускорения удаленных RPC. Идея на следующем когда нить-сервер ожидая нового ее контекст всегда не важной информации. Следовательно, нить завершает запроса, то просто удаляют. При на сервер сообщения ядро новую нить обслуживания этого запроса. Кроме ядро помещает в адресное пространство и устанавливает новый нити для к сообщению. Эту иногда называют вызовом.

Этот имеет несколько по сравнению с RPC. Во-первых, не должны ожидая новую следовательно контекст нужно сохранять, создание новой проще, чем существующей приостановленной, как не восстанавливать контекст.

Современные и технологии проектирования систем

Требования, к ОС 90-х

Операционная система сердцевиной сетевого обеспечения, она среду для приложений и во определяет, какими для пользователя эти приложения обладать. В связи с рассмотрим требования, должна удовлетворять ОС.

Очевидно, главным требованием, к операционной системе, способность выполнения функций: эффективного ресурсами и обеспечения интерфейса для и прикладных программ. Современная как правило, реализовывать мультипрограммную виртуальную память, поддерживать многооконный а также выполнять другие, совершенно функции. Кроме функциональных требований к системам предъявляются менее важные требования. К этим относятся:

  1. Расширяемость. Код быть написан образом, чтобы было легко дополнения и изменения, это потребуется, и нарушить целостность системы.
  2. Переносимость. Код легко переноситься с одного типа процессор другого и с аппаратной платформы включает наряду с процессора и способ всей аппаратуры одного типа аппаратную платформу типа.
  3. Надежность и . Система должна защищена как внутренних, так и внешних ошибок, и отказов. Ее должны быть предсказуемыми, а приложения должны быть в наносить вред ОС.
  4. Совместимость. ОС иметь средства выполнения прикладных написанных для операционных систем. Кроме пользовательский интерфейс быть совместим с системами и стандартами.
  5. Безопасность. ОС обладать средствами ресурсов одних от других.
  6. Производительность. Система обладать настолько быстродействием и временем насколько это аппаратная платформа.

Рассмотрим подробно некоторые этих требований.

В время, как часть компьютера за несколько полезная жизнь систем может десятилетиями. Примером служить ОС UNIX. Поэтому системы всегда изменяются со и эти изменения значимы, чем аппаратных средств. Изменения обычно представляют приобретение ею свойств. Например, новых устройств, как CD-ROM, связи с сетями типа, поддержка технологий, таких графический интерфейс или объектно-ориентированное окружение, использование чем одного процессора. Сохранение кода, какие изменения не в операционную систему, главной целью разработки.

Расширяемость достигаться за модульной структуры при которой строятся из отдельных модулей, только через интерфейс. Новые могут быть в операционную систему путем, они свою работу, интерфейсы, поддерживаемые компонентами.

Использование для представления ресурсов также расширяемость системы. Объекты - абстрактные типы над которыми производить только действия, которые специальным набором функций. Объекты единообразно управлять ресурсами. Добавление объектов не существующие объекты и требует изменений кода.

Прекрасные для расширения подход к структурированию по типу с использованием микроядерной технологии. В с этим подходом строится как привилегированной управляющей и набора непривилегированных услуг-серверов. Основная ОС может неизменной в то как могут добавлены новые или улучшены старые.

Средства удаленных процедур также дают расширить функциональные ОС. Новые процедуры могут добавлены в любую сети и немедленно в распоряжение прикладных на других сети.

Некоторые для улучшения поддерживают загружаемые которые могут добавлены в систему время ее работы. Новые системы, устройства и могут поддерживаться написания драйвера драйвера файловой или транспортного и загрузки его в систему.

Требование кода тесно с расширяемостью. Расширяемость улучшать операционную в то время переносимость дает перемещать всю на машину, на другом или аппаратной делая при по возможности изменения в коде. Хотя часто описываются как переносимые, как непереносимые, - это не состояние. Вопрос в том, может быть система а в том, насколько можно это сделать. Написание ОС аналогично любого переносимого - нужно следовать правилам.

Во-первых, часть кода быть написана языке, который на всех куда вы переносить систему. Обычно означает, что должен быть на языке уровня, предпочтительно например, на С. Программа, на ассемблере, является переносимой, только вы собираетесь переносить на машину, командной совместимостью с вашей.


Во-вторых, учесть, в какое окружение программа быть перенесена. Различная требует различных при создании ОС. Например, построенная на адресах, не быть перенесена машину с 16-битовыми (разве что с трудностями).

В-третьих, минимизировать или, возможно, исключить части кода, непосредственно взаимодействуют с средствами. Зависимость аппаратуры может много форм. Некоторые формы зависимости прямое манипулирование и другими аппаратными средствами.

В-четвертых, аппаратно зависимый не может полностью исключен, он должен изолирован в нескольких локализуемых модулях. Аппаратно-зависимый не должен распределен по системе. Например, спрятать аппаратно-зависимую в программно-задаваемые данные типа. Другие системы будут с этими данными, а с аппаратурой, используя некоторых функций. Когда переносится, то только эти и функции, которые манипулируют.

Для переноса ОС ее разработке быть соблюдены требования:

  1. Переносимый высокого уровня. Большинство ОС написано языке С (стандарт X3.159-1989). Разработчики С потому, что стандартизован, и потому, С-компиляторы широко доступны. Ассемблер только для частей системы, должны непосредственно с аппаратурой (например, прерываний) или частей, которые максимальной скорости целочисленная арифметика точности). Однако код должен тщательно изолирован тех компонентов, он используется.
  2. Изоляция . Некоторые низкоуровневые ОС должны доступ к процессорно-зависимым данных и регистрам. Однако который делает должен содержаться в модулях, которые быть заменены модулями для процессоров.
  3. Изоляция . Зависимость от заключается в различиях рабочими станциями производителей, построенными одном и том процессоре (например, R4000). Должен введен программный абстрагирующий аппаратуру контроллеры прерываний и т. п.) со слоем программ таким чтобы высокоуровневый не нуждался в при переносе с платформы на другую.

Одним аспектов совместимости способность ОС программы, написанные других ОС для более версий данной системы, а также другой аппаратной платформы.

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

Совместимость уровне исходных требует наличия компилятора в составе обеспечения, а также на уровне и системных вызовов. При необходима перекомпиляция исходных текстов в выполняемый модуль.


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

Обладает новая ОС совместимостью или исходных текстов с системами, зависит многих факторов. Самый из них - процессора, на работает новая ОС. Если на который ОС, использует же набор (возможно с некоторыми и тот же адресов, тогда совместимость может достигнута достаточно просто.

Гораздо достичь двоичной между процессорами, на разных архитектурах. Для чтобы один выполнял программы (например, DOS-программу Mac), этот должен работать с командами, которые изначально непонятны. Например, типа 680x0 Mac должен двоичный код, для процессора в PC. Процессор имеет свои дешифратор команд, и внутреннюю архитектуру. Процессор не понимает код 80x86, поэтому он должен выбрать каждую команду, декодировать ее, чтобы определить, для чего она предназначена, а затем выполнить эквивалентную подпрограмму, написанную для 680x0. Так как к тому же у 680x0 нет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как в 80x86, он должен имитировать все эти элементы с использованием своих регистров или памяти. И он должен тщательно воспроизводить результаты каждой команды, что требует специально написанных подпрограмм для 680x0, гарантирующих, что состояние эмулируемых регистров и флагов после выполнения каждой команды будет в точности таким же, как и на реальном 80x86.

Это простая, но очень медленная работа, так как микрокод внутри процессора 80x86 исполняется на значительно более быстродействующем уровне, чем эмулирующие его внешние команды 680x0. За время выполнения одной команды 80x86 на 680x0, реальный 80x86 может выполнить десятки команд. Следовательно, если процессор, производящий эмуляцию, не настолько быстр, чтобы компенсировать все потери при эмуляции, то программы, исполняющиеся под эмуляцией, будут очень медленными.

Выходом в таких случаях является использование так называемых прикладных сред. Учитывая, что основную часть программы, как правило, составляют вызовы библиотечных функций, прикладная среда имитирует библиотечные функции целиком, используя заранее написанную библиотеку функций аналогичного назначения, а остальные команды эмулирует каждую по отдельности.

    1. Операционные системы различных фирм производителей программного обеспечения

UNIX зародился в лаборатории Bell Labs фирмы AT&T более 20 лет назад. В то время Bell Labs занималась разработкой многопользовательской системы разделения времени MULTICS (Multiplexed Information and Computing Service) совместно с MIT и General Electric, но эта система потерпела неудачу, отчасти из-за слишком амбициозных целей, не соответствовавших уровню компьютеров того времени, а отчасти и из-за того, что она разрабатывалась на языке PL/1, а компилятор PL/1 задерживался и вообще плохо работал после своего запоздалого появления. Первыми пользователями UNIX'а стали сотрудники отдела патентов Bell Labs, которые нашли ее удобной средой для создания текстов.

Большое влияние на судьбу UNIX оказала перепись ее языке высокого С, разработанного Ритчи специально этих целей. Это в 1973 году, насчитывал к этому уже 25 и в Bell Labs создана специальная поддержки UNIX.

Широкое UNIX получил с года, после этой системы и Ритчи в компьютерном CACM. UNIX широкое распространение в так как них он бесплатно вместе с кодами на С. Широкое эффективных C-компиляторов UNIX уникальной того времени из-за возможности на различные компьютеры. Университеты значительный вклад в UNIX и дальнейшую популяризацию. Еще шагом на получения признания как стандартизованной стала разработка Ритчи библиотеки stdio. Благодаря этой библиотеки компилятора С, для UNIX легко переносимыми.

Микроядро

Ядро любой коммерческой версии представляет собой очень большого функций, с запутанными и очень расплывчатыми между основными подсистемами. В любая модификация таким образом дается тяжело и к появлению в новых большого количества ошибок. Кроме не во инсталляциях нужны компоненты ядра, а монолитном его удаление ненужных затруднено. Недостатки, операционным системам с монолитным ядром это в первую различные версии породили интерес к построенным на микроядра.

Микроядерный заключается в том, базовые функции оформляются в виде небольшой компоненты, в привилегированном режиме, а функции ОС в пользовательском режиме с примитивов микроядра. Ввиду потенциальных преимуществ, сулит этот можно предположить, в ближайшее время новых операционных будет строиться основе микроядра. Наиболее реализациями этого являются микроядра и Chorus.

Основной использования микроядерного на практике замедление скорости системных вызовов передаче сообщений микроядро по с классическим подходом.