extracted_text:
билет 4 тема 3
Классическая архитектура ОС.
од архитектурой операционной системы понимают структурную и функциональную организацию ОС на
основе некоторой совокупности программных модулей. В состав ОС входят исполняемые и объектные
модули стандартных для данной ОС форматов, программные модули специального формата (например,
загрузчик ОС, драйверы вводавывода), конфигурационные файлы, файлы документации, модули
справочной системы и т.д.
На архитектуру ранних операционных систем обращалось мало внимания: вопервых, ни у кого не было
опыта в разработке больших программных систем, а вовторых, проблема взаимозависимости и
взаимодействия модулей недооценивалась. В подобных монолитных ОС почти все процедуры могли
вызывать одна другую. Такое отсутствие структуры было несовместимо с расширением операционных
систем. Первая версия ОС OS/360 была создана коллективом из 5000 человек за 5 лет и содержала более 1
млн строк кода. Разработанная несколько позже операционная система Mastics содержала к 1975 году уже
20 млн строк [17]. Стало ясно, что разработка таких систем должна вестись на основе модульного
программирования.
Большинство современных ОС представляют собой хорошо структурированные модульные системы,
способные к развитию, расширению и переносу на новые платформы. Какойлибо единой
унифицированной архитектуры ОС не существует, но известны универсальные подходы к
структурированию ОС. Принципиально важными универсальными подходами к разработке архитектуры
ОС являются [5, 10, 13, 17]:
    модульная организация;
    функциональная избыточность;
    функциональная избирательность;
    параметрическая универсальность;
    концепция многоуровневой иерархической вычислительной системы, по которой ОС представляется
многослойной структурой;
    разделение модулей на две группы по функциям: ядро – модули, выполняющие основные функции ОС,
и модули, выполняющие вспомогательные функции ОС;
    разделение модулей ОС на две группы по размещению в памяти вычислительной системы: резидентные,
постоянно находящиеся в оперативной памяти, и транзитные, загружаемые в оперативную память только
на время выполнения своих функций;
    реализация двух режимов работы вычислительной системы: привилегированного режима (режима ядра –
Kernel mode), или режима супервизора (supervisor mode), и пользовательского режима (user mode), или
режима задачи (task mode);
    ограничение функций ядра (а следовательно, и количества модулей ядра) до минимального количества
необходимых самых важных функций.
Первые ОС разрабатывались как монолитные системы без четко выраженной структуры (рис. 1.2).
Для построения монолитной системы необходимо скомпилировать все отдельные процедуры, а затем
связать их вместе в единый объектный файл с помощью компоновщика (примерами могут служить ранние
версии ядра UNIX или Novell NetWare). Каждая процедура видит любую другую процедуру (в отличие от
структуры, содержащей модули, в которой большая часть информации является локальной для модуля, и
процедуры модуля можно вызвать только через специально определенные точки входа).
Однако даже такие монолитные системы могут быть немного структурированными. При обращении к
системным вызовам, поддерживаемым ОС, параметры помещаются в строго определенные места, такие
как регистры или стек, а затем выполняется специальная команда прерывания, известная как вызов ядра
или вызов супервизора. Эта команда переключает машину из режима пользователя в режим ядра,
называемый также режимом супервизора, и передает управление ОС. Затем ОС проверяет параметры
вызова, для того чтобы определить, какой системный вызов должен быть выполнен. После этого ОС
индексирует таблицу, содержащую ссылки на процедуры, и вызывает соответствующую процедуру.
Монолитная архитектура
Такая организация ОС предполагает следующую структуру [13]:
    главная программа, которая вызывает требуемые сервисные процедуры; набор сервисных процедур, реализующих системные вызовы;
    набор утилит, обслуживающих сервисные процедуры.
В этой модели для каждого системного вызова имеется одна сервисная процедура. Утилиты выполняют
функции, которые нужны нескольким сервисным процедурам. Это деление процедур на три слоя показано
на рис. 1.3.
Классической считается архитектура ОС, основанная на концепции иерархической многоуровневой
машины, привилегированном ядре и пользовательском режиме работы транзитных модулей. Модули ядра
выполняют базовые функции ОС: управление процессами, памятью, устройствами вводавывода и т.п.
Ядро составляет сердцевину ОС, без которой она является полностью неработоспособной и не может
выполнить ни одну из своих функций. В ядре решаются внутрисистемные задачи организации
вычислительного процесса, недоступные для приложения.
Структурированная архитектура
Особый класс функций ядра служит для поддержки приложений, создавая для них так называемую
прикладную программную среду. Приложения могут обращаться к ядру с запросами – системными
вызовами – для выполнения тех или иных действий, например, открытие и чтение файла, получение
системного времени, вывода информации на дисплей и т.д. Функции ядра, которые могут вызываться
приложениями, образуют интерфейс прикладного программирования – API (Application Programming
Interface).
Для обеспечения высокой скорости работы ОС модули ядра (по крайней мере, большая их часть)
являются резидентными и работают в привилегированном режиме (Kernel mode). Этот режим, вопервых,
должен обезопасить работу самой ОС от вмешательства приложений, и, вовторых, должен обеспечить
возможность работы модулей ядра с полным набором машинных инструкций, позволяющих собственно
ядру выполнять управление ресурсами компьютера, в частности, переключение процессора с задачи на
задачу, управлением устройствами вводавывода, распределением и защитой памяти и др.
Остальные модули ОС выполняют не столь важные функции, как ядро, и являются транзитными.
Например, это могут быть программы архивирования данных, дефрагментации диска, сжатия дисков,
очистки дисков и т.п.
Вспомогательные модули обычно подразделяются на группы:
    утилиты – программы, выполняющие отдельные задачи управления и сопровождения вычислительной
системы;
    системные обрабатывающие программы – текстовые и графические редакторы (Paint, Imaging в
Windows 2000), компиляторы и др.;
    программы предоставления пользователю дополнительных услуг (специальный вариант
пользовательского интерфейса, калькулятор, игры, средства мультимедиа Windows 2000);
    библиотеки процедур различного назначения, упрощения разработки приложений, например,
библиотека функций вводавывода, библиотека математических функций и т.п.
Эти модули ОС оформляются как обычные приложения, обращаются к функциям ядра посредством
системных вызовов и выполняются в пользовательском режиме (user mode). В этом режиме запрещается
выполнение некоторых команд, которые связаны с функциями ядра ОС (управление ресурсами,
распределение и защита памяти и т.п.).
В концепции многоуровневой (многослойной) иерархической машины структура ОС также представляется
рядом слоев. При такой организации каждый слой обслуживает вышележащий слой, выполняя для него
некоторый набор функций, которые образуют межслойный интерфейс. На основе этих функций
следующий верхний по иерархии слой строит свои функции – более сложные и более мощные и т.д. Такая
организация системы существенно упрощает ее разработку, т.к. позволяет сначала "сверху вниз"
определить функции слоев и межслойные интерфейсы, а при детальной реализации, двигаясь "снизу
вверх", – наращивать мощность функции слоев. Кроме того, модули каждого слоя можно изменять без
необходимости изменений в других слоях (но не меняя межслойных интерфейсов!).
Многослойная структура ядра ОС может быть представлена, например, вариантом, показанным на рис. 1
В данной схеме выделены следующие слои. Средства аппаратной поддержки ОС. Значительная часть функций ОС может выполняться аппаратными
средствами [10]. Чисто программные ОС сейчас не существуют. Как правило, в современных системах
всегда есть средства аппаратной поддержки ОС, которые прямо участвуют в организации вычислительных
процессов. К ним относятся: система прерываний, средства поддержки привилегированного режима,
средства поддержки виртуальной памяти, системный таймер, средства переключения контекстов
процессов (информация о состоянии процесса в момент его приостановки), средства защиты памяти и др.
    Машиннозависимые модули ОС. Этот слой образует модули, в которых отражается специфика
аппаратной платформы компьютера. Назначение этого слоя – "экранирование" вышележащих слоев ОС от
особенностей аппаратуры (например, Windows 2000 – это слой HAL (Hardware Abstraction Layer), уровень
аппаратных абстракций).
    Базовые механизмы ядра. Этот слой модулей выполняет наиболее примитивные операции ядра:
программное переключение контекстов процессов, диспетчерскую прерываний, перемещение страниц
между основной памятью и диском и т.п. Модули этого слоя не принимают решений о распределении
ресурсов, а только обрабатывают решения, принятые модулями вышележащих уровней. Поэтому их часто
называют исполнительными механизмами для модулей верхних слоев ОС.
    Менеджеры ресурсов. Модули этого слоя выполняют стратегические задачи по управлению ресурсами
вычислительной системы. Это менеджеры (диспетчеры) процессов вводавывода, оперативной памяти и
файловой системы. Каждый менеджер ведет учет свободных и используемых ресурсов и планирует их
распределение в соответствии запросами приложений.
    Интерфейс системных вызовов. Это верхний слой ядра ОС, взаимодействующий с приложениями и
системными утилитами, он образует прикладной программный интерфейс ОС. Функции API,
обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной компактной
форме, без указания деталей их физического расположения.
Повышение устойчивости ОС обеспечивается переходом ядра в привилегированный режим. При этом
происходит некоторое замедление выполнения системных вызовов. Системный вызов привилегированного
ядра инициирует переключение процессора из пользовательского режима в привилегированный, а при
возврате к приложению – обратное переключение. За счет этого возникает дополнительная задержка в
обработке системного вызова (рис. 1.5). Однако такое решение стало классическим и используется во
многих ОС (UNIX, VAX, VMS, IBM OS/390, OS/2 и др.).
Обработка системного вызова
Многослойная классическая многоуровневая архитектура ОС не лишена своих проблем. Дело в том, что
значительные изменения одного из уровней могут иметь трудно предвидимое влияние на смежные уровни.
Кроме того, многочисленные взаимодействия между соседними уровнями усложняют обеспечение
безопасности. Поэтому, как альтернатива классическому варианту архитектуры ОС, часто используется
микроядерная архитектура ОС.
Суть этой архитектуры состоит в следующем. В привилегированном режиме остается работать только
очень небольшая часть ОС, называемая микроядром. Микроядро защищено от остальных частей ОС и
приложений. В его состав входят машиннозависимые модули, а также модули, выполняющие базовые
механизмы обычного ядра. Все остальные более высокоуровневые функции ядра оформляются как
модули, работающие в пользовательском режиме. Так, менеджеры ресурсов, являющиеся неотъемлемой
частью обычного ядра, становятся "периферийными" модулями, работающими в пользовательском
режиме. Таким образом, в архитектуре с микроядром традиционное расположение уровней по вертикали
заменяется горизонтальным. Это можно представить, как показано на рис. 1.6.
Внешние по отношению к микроядру компоненты ОС реализуются как обслуживающие процессы. Между
собой они взаимодействуют как равноправные партнеры с помощью обмена сообщениями, которые
передаются через микроядро. Поскольку назначением этих компонентов ОС является обслуживание
запросов приложений пользователей, утилит и системных обрабатывающих программ, менеджеры
ресурсов, вынесенные в пользовательский режим, называются серверами ОС, т.е. модулями, основным
назначением которых является обслуживание запросов локальных приложений и других модулей ОС.
Переход к микроядерной архитектуре Рис. 1.6. Переход к микроядерной архитектуре
Схематично механизм обращений к функциям ОС, оформленным в виде серверов, выглядит, как показано
на рис. 1.7.
Клиентсерверная архитектура
Рис. 1.7. Клиентсерверная архитектура
Схема смены режимов при выполнении системного вызова в ОС с микроядерной архитектурой выглядит,
как показано на рис. 1.8. Из рисунка ясно, что выполнение системного вызова сопровождается четырьмя
переключениями режимов (4 t), в то время как в классической архитектуре – двумя. Следовательно,
производительность ОС с микроядерной архитектурой при прочих равных условиях будет ниже, чем у ОС
с классическим ядром.
Обработка системного вызова в микроядерной архитектуре
Рис. 1.8. Обработка системного вызова в микроядерной архитектуре
В то же время признаны следующие достоинства микроядерной архитектуры [17]:
    единообразные интерфейсы;
    простота расширяемости;
    высокая гибкость;
    возможность переносимости;
    высокая надежность;
    поддержка распределенных систем;
    поддержка объектноориентированных ОС.
По многим источникам вопрос масштабов потери производительности в микроядерных ОС является
спорным. Многое зависит от размеров и функциональных возможностей микроядра. Избирательное
увеличение функциональности микроядра приводит к снижению количества переключений между
режимами системы, а также переключений адресных пространств процессов.
Может быть, это покажется парадоксальным, но есть и такой подход к микроядерной ОС, как уменьшение
микроядра.
Для возможности представления о размерах микроядер операционных систем в ряде источников [17]
приводятся такие данные:
    типичное микроядро первого поколения – 300 Кбайт кода и 140 интерфейсов системных вызовов;
    микроядро ОС L4 (второе поколение) – 12 Кбайт кода и 7 интерфейсов системных вызовов.
В современных операционных системах различают следующие виды ядер.
    Наноядро (НЯ). Крайне упрощённое и минимальное ядро, выполняет лишь одну задачу – обработку
аппаратных прерываний, генерируемых устройствами компьютера. После обработки посылает
информацию о результатах обработки вышележащему программному обеспечению. НЯ используются для
виртуализации аппаратного обеспечения реальных компьютеров или для реализации механизма
гипервизора.
    Микроядро (МЯ) предоставляет только элементарные функции управления процессами и минимальный
набор абстракций для работы с оборудованием. Большая часть работы осуществляется с помощью
специальных пользовательских процессов, называемых сервисами. В микроядерной операционной системе
можно, не прерывая ее работы, загружать и выгружать новые драйверы, файловые системы и т. д. Микроядерными являются ядра ОС Minix и GNU Hurd и ядро систем семейства BSD. Классическим
примером микроядерной системы является Symbian OS. Это пример распространенной и отработанной
микроядерной (a начиная c версии Symbian OS v8.1, и наноядерной) операционной системы.
    Экзоядро (ЭЯ) предоставляет лишь набор сервисов для взаимодействия между приложениями, а также
необходимый минимум функций, связанных с защитой: выделение и высвобождение ресурсов, контроль
прав доступа и т. д. ЭЯ не занимается предоставлением абстракций для физических ресурсов – эти
функции выносятся в библиотеку пользовательского уровня (так называемую libOS). В отличие от
микроядра ОС, базирующиеся на ЭЯ, обеспечивают большую эффективность за счет отсутствия
необходимости в переключении между процессами при каждом обращении к оборудованию.
    Монолитное ядро (МнЯ) предоставляет широкий набор абстракций оборудования. Все части ядра
работают в одном адресном пространстве. МнЯ требуют перекомпиляции при изменении состава
оборудования. Компоненты операционной системы являются не самостоятельными модулями, а
составными частями одной программы. МнЯ более производительно, чем микроядро, поскольку работает
как один большой процесс. МнЯ является большинство Unixсистем и Linux. Монолитность ядер
усложняет отладку, понимание кода ядра, добавление новых функций и возможностей, удаление
ненужного, унаследованного от предыдущих версий кода. "Разбухание" кода монолитных ядер также
повышает требования к объёму оперативной памяти.
    Модульное ядро (Мод. Я) – современная, усовершенствованная модификация архитектуры МЯ. В
отличие от "классических" МнЯ, модульные ядра не требуют полной перекомпиляции ядра при изменении
состава аппаратного обеспечения компьютера. Вместо этого они предоставляют тот или иной механизм
подгрузки модулей, поддерживающих то или иное аппаратное обеспечение (например, драйверов).
Подгрузка модулей может быть как динамической, так и статической (при перезагрузке ОС после
переконфигурирования системы). Мод. Я удобнее для разработки, чем традиционные монолитные ядра.
Они предоставляют программный интерфейс (API) для связывания модулей с ядром, для обеспечения
динамической подгрузки и выгрузки модулей. Не все части ядра могут быть сделаны модулями.
Некоторые части ядра всегда обязаны присутствовать в оперативной памяти и должны быть жёстко
"вшиты" в ядро.
    Гибридное ядро (ГЯ) – модифицированные микроядра, позволяющие для ускорения работы запускать
"несущественные" части в пространстве ядра. Имеют "гибридные" достоинства и недостатки. Примером
смешанного подхода может служить возможность запуска операционной системы с монолитным ядром
под управлением микроядра. Так устроены 4.4BSD и MkLinux, основанные на микроядре Mach.
Микроядро обеспечивает управление виртуальной памятью и работу низкоуровневых драйверов. Все
остальные функции, в том числе взаимодействие с прикладными программами, осуществляются
монолитным ядром. Данный подход сформировался в результате попыток использовать преимущества
микроядерной архитектуры, сохраняя по возможности хорошо отлаженный код монолитного ядра.
    Наиболее тесно элементы микроядерной архитектуры и элементы монолитного ядра переплетены в
ядре Windows NT. Хотя Windows NT часто называют микроядерной операционной системой, это не
совсем так. Микроядро NT слишком велико (более 1 Мбайт), чтобы носить приставку "микро".
Компоненты ядра Windows NT располагаются в вытесняемой памяти и взаимодействуют друг с другом
путем передачи сообщений, как и положено в микроядерных операционных системах. В то же время все
компоненты ядра работают в одном адресном пространстве и активно используют общие структуры
данных, что свойственно операционным системам с монолитным ядром.

file_name: билет 4 тема 3.docx

intro:
од архитектурой операционной системы понимают структурную и функциональную организацию ОС на основе некоторой совокупности программных модулей. В состав ОС входят исполняемые и объектные модули стандартных для данной ОС форматов, программные модули специального формата (например, загрузчик ОС, драйверы ввода-вывода), конфигурационные файлы, файлы документации, модули справочной системы и т.д.
На архитектуру ранних операционных систем обращалось мало внимания: во-первых, ни у кого не было опыта в разработке больших программных систем, а во-вторых, проблема взаимозависимости и взаимодействия модулей недооценивалась.

title: Лекция "Классическая архитектура ОС."


extracted_text:
билет 4 тема 4
139 Управление доступом к предающей среде. Методы и протоколы доступа.
Метод доступа к передающей среде  это совокупность правил, по которым узлы сети получают
доступ к ресурсу. Иначе: это способ «захвата» передающей среды, способ определения того, какая из
рабочих станций сети может следующей использовать ресурсы сети. Так же называется набор правил
(алгоритм), используемых сетевым оборудованием, чтобы направить поток сообщений через сеть, а
также один из основных признаков, по которым различают сетевое оборудование.
Методы доступа к передающей среде реализуются протоколами передачи данных (ППД) нижнего уровня
(протоколами управления каналом). ППД нижнего уровня  это совокупность процедур, выполняемых на
нижних уровнях модели ВОС по управлению потоками данных между рабочими станциями сети на
одном физическом канале связи.
Методы доступа к передающей среде и соответствующие ППД нижнего уровня могут быть разделены на
следующие классы:
• методы, основанные на резервировании времени, принадлежат к числу наиболее ранних и простых.
Любая PC осуществляет передачу только в течение временных интервалов (слотов, определяющих
начало и продолжительность передачи), заранее для нее зарезервированных. В неприоритетных системах
слоты распределяются между станциями поровну, в системе с учетом приоритетов некоторые станции за
фиксированный интервал времени получают большее число слотов. Станция, владеющая слотом,
получает канал в свое полное распоряжение. Такие методы целесообразно применять в сетях с малым
числом PC, так как канал используется неэффективно;
• селективные методы, при реализации которых с помощью соответствующих ППД рабочая станция
осуществляет передачу только после получения разрешения, направляемого каждой PC по очереди
центральным управляющим органом сети (такой алгоритм называется циклическим опросом), или это
разрешение передается от станции к станции (алгоритм передачи маркера);
• методы, основанные на соперничестве (методы случайного доступа, методы «состязаний» рабочих
станций), когда каждая PC пытается «захватить» передающую среду;
• кольцевые методы, предназначенные только для ЛКС с кольцевой топологией. К ним относятся два
метода  вставка регистров и сегментированная передача (метод временных сегментов).
Реализация метода вставки регистра связана с необходимостью наличия в PC регистра (буфера),
подключаемого параллельно к кольцевому моноканалу. В регистр записывается кадр для передачи, и
станция ожидает межкадровый промежуток в моноканале. С его появлением регистр включается в
моноканал и содержимое регистра передается в линию. Если во время передачи станция получает кадр,
он записывается в буфер и передается вслед за кадром, передаваемым этой станцией. Допускается
«подсадка» в моноканал нескольких кадров.
В случае использования сегментированной передачи временные сегменты одинаковой протяженности
формируются управляющей станцией сети и циркулируют по кольцевому моноканалу. Каждая станция,
периодически обращаясь в сеть, может дождаться временного сегмента, помеченного меткой
«свободен». В этот сегмент станция помещает свой кадр и при этом метка «свободен» заменяется
меткой «занят». После доставки кадра адресату сегмент вновь освобождается. Важным преимуществом
такого метода является возможность одновременной передачи кадров несколькими станциями, однако
управление сетью, где этот метод используется, значительно сложнее.
Детализация такого деления методов доступа и ППД нижнего уровня приведена на рис. 4. Все ППД
делятся на два класса: ППД типа первичный/вторичный и одноранговые ППД. Первые из них
предполагают наличие в сети первичного (главного) узла, который управляет всеми остальными
(вторичными) узлами, подключенными к каналу, и определяет, когда и какие узлы могут производить
обмен данными. В сетях, где реализуются одноранговые (одноуровневые, равноранговые) протоколы, все
узлы имеют одинаковый статус. Однако, если предварительно узлам присвоить разные приоритеты, то
для них устанавливается неравноправный доступ в сеть.
ППД типа первичный/вторичный могут быть реализованы на основе нескольких технологий, образующих
две группы: с опросом и без опроса (см. рис. 4).
Наибольшее распространение в сетях с опросом получили протоколы «опрос с остановкой и
ожиданием» и «непрерывный автоматический запрос на повторение». Оба протокола относятся к классу ППД, реализующих селективные методы доступа к передающей среде, хорошо известные по применению
в многоточечных линиях глобальных сетей. Суть таких технологий доступа заключается в том, что
первичный узел последовательно предлагает вторичным узлам подключиться к общему каналу передачи.
В ответ на такой запрос вторичный узел, имея подготовленные данные, осуществляет передачу. В
противном случае выдается короткий пакет данных типа «данных нет», хотя в современных системах,
как правило, вместо этого пакета реакцией является «молчание».
Получил распространение способ организации запроса  циклический опрос, т.е. последовательное
обращение к каждому вторичному узлу в порядке очередности, определяемом списком опроса. Цикл
завершается после опроса всех вторичных узлов из списка. Для сокращения потерь времени, связанных с
опросом неактивных вторичных узлов, применяются специальные варианты процедуры опроса: наиболее
активные узлы в течение одного цикла опрашиваются несколько раз; наименее активные узлы
опрашиваются один раз в течение нескольких циклов; частота опроса отдельных узлов меняется
динамически в соответствии с изменением их активности. В сетях с многоточечными линиями
применяется также опрос по принципу «готов  вперед». В каждой многоточечной линии опрос
начинается с самого удаленного вторичного узла к другому, пока не достигнет узла, ближайшего к
опрашивающему органу. Реализация такого принципа позволяет сократить время на распространение
сигнала опроса от первичного узла к вторичным.
Системы с опросом отличаются простотой реализации протокола и невысокой стоимостью
используемого оборудования.
Недостатки таких систем:
• неэффективное использование дорогостоящих ресурсов канала, связанное с передачей служебной
информации (сигналов опроса, сигналов ответной реакции);
• простаивание вторичного узла, имеющего готовые для передачи данные, в ожидании поступления
сигнала «опрос» (этот недостаток особенно ощущается при большом количестве вторичных узлов);
• наличие узкого места по надежности (отказ первичного узла приводит к отказу всей сети) и по
пропускной способности, так как обмен данными между вторичными узлами осуществляется только
через первичный узел.
Простейшей модификацией ППД типа первичный/вторичный с опросом является протокол, называемый
опрос с остановкой и ожиданием. При его использовании узел после передачи кадра ожидает от
адресата подтверждения в правильности его пересылки, что сопряжено с дополнительными затратами
времени.
Другой пример протоколов типа первичный/вторичный с опросом  непрерывный автоматический
запрос на повторение передачи данных. Применяется в дуплексных системах (в системах передачи
данных с решающей обратной связью), допускающих одновременную передачу данных в обоих
направлениях между взаимодействующими узлами. В системах с таким протоколом (он называется также
протоколом ARQ) узел связи может автоматически запрашивать другой узел и повторно производить
передачу данных. На передающей и принимающей станциях устанавливаются так называемые
передающие и принимающие окна и выделяется время и необходимые ресурсы на непрерывную передачу
(прием) фиксированного числа кадров. Кадры, принадлежащие данному окну, передаются без
периодических подтверждений со стороны адресата о приеме очередного кадра. Подтверждение
передается после получения всех кадров окна, что обеспечивает экономию времени на передачу
фиксированного объема информации по сравнению с предыдущим протоколом. Однако приемник
должен иметь достаточный объем зарезервированной памяти для обработки непрерывно поступающего
трафика.
В системах ARQ важное значение имеет размер окна (количество кадров в окне). Чем больше окно, тем
большее число кадров может быть передано без ответной реакции со стороны приемника и,
следовательно, тем большая экономия достигается за счет сокращения служебной информации. Но
увеличение размера окна сопровождается выделением больших ресурсов и буферной памяти для
обработки поступающих сообщений. Кроме того, это негативно отражается на эффективности
реализуемых способов защиты от ошибок. В настоящее время в сетях с протоколом ARQ
предусматриваются семикадровые окна. Концепция скользящих окон, реализованная в этом протоколе,
достаточно проста. Сложность заключается лишь в том, что первичный узел, связанный с десятками и даже сотнями вторичных узлов, должен поддерживать окно с каждым из них, обеспечивая управление
потоками данных и эффективность их передачи.
Протоколы типа «первичный/вторичный без опроса» также получили определенное
распространение. К ним относятся:
• запрос передачи/разрешение передачи;
• разрешить/запретить передачу;
• множественный доступ с временным разделением.
Общим для этих протоколов является то, что инициатива в подаче запроса на обслуживание
принадлежит, как правило, вторичному органу, причем запрос подается первичному органу, если
действительно имеется необходимость в передаче или в получении данных от другого органа.
Эффективность протоколов по сравнению с ППД с опросом будет тем выше, чем в большей степени
вторичные органы отличаются друг от друга по своей активности, т.е. по частоте подачи запросов на
обслуживание. Первые два протокола без опроса реализуют селективные методы доступа к передающей
среде, а третий  методы, основанные на резервировании времени.
Протокол типа «запрос передачи/разрешение передачи» применяется в полудуплексных каналах
связи ЛКС, так как взаимосвязан с распространенным короткодистанционным физическим интерфейсом
RS232C. Организация передачи данных между вторичным и первичным органами производится в такой
последовательности: выдача вторичным органом запроса на передачу  выдача первичным органом
сигнала разрешения на передачу вторичным органом  передача данных от вторичного органа к
первичному  сброс сигнала первичным органом по завершении передачи.
Протокол типа «разрешить/запретить передачу» часто используется периферийными устройствами
(принтерами, графопостроителями) для управления входящим в них трафиком. Первичной орган
(обычно компьютер) посылает данные в периферийный узел (вторичный орган), скорость работы
которого существенно меньше скорости работы компьютера и скорости передачи данных каналом. В
связи с этим возможно переполнение буферного ЗУ периферийного узла. Для предотвращения
переполнения периферийный узел посылает к компьютеру сигнал «передача выключена», получив
который компьютер прекращает передачу и сохраняет данные до тех пор, пока не получит сигнал
«разрешить передачу», означающий, что буферное ЗУ освободилось и периферийный узел готов принять
новые данные.
Множественный доступ с временным разделением используется в спутниковых сетях связи.
Первичный орган (главная, эталонная станция сети) принимает запросы от вторичных (подчиненных)
станций на предоставление канала связи и, реализуя ту или иную дисциплину обслуживания запросов,
определяет, какие именно станции и когда могут использовать канал в течение заданного промежутка
времени, т.е. предоставляет каждой станции слот. Получив слот, вторичная станция осуществляет
временную подстройку, чтобы произвести передачу данных за заданный слот.
Одноранговые протоколы разделяются на две группы: без приоритетов (в неприоритетных системах) и
с учетом приоритетов (в приоритетных системах).
Мультиплексная передача с временным разделением  наиболее простая равноранговая
неприоритетная система, где реализуются методы доступа к передающей среде, основанные на
резервировании времени. Используется жесткое расписание работы абонентов: каждой станции
выделяется интервал времени (слот) использования канала связи, и все интервалы распределяются
между станциями поровну.
Недостатки такого протокола:
• возможность неполного использования канала, когда станция, получив слот, не может полностью
загрузить канал изза отсутствия необходимого объема данных для передачи;
• нежелательные задержки в передаче данных, когда станция, имеющая важную и срочную информацию,
вынуждена ждать своего слота или когда выделенного слота недостаточно для передачи подготовленных
данных и необходимо ждать следующего слота.
Множественный доступ с прослушиванием несущей частоты и разрешением коллизий,
английская аббревиатура которого CSMA/CD Caner Sense Maltiple Access with Collection Detection. Это
наиболее распространенный недерминированный метод случайного доступа к передающей среде.
Работа сети под управлением такого протокола осуществляется следующим образом. Все станции сети, будучи равноправными, перед началом передачи работают в режиме прослушивания канала. Если канал
свободен, станция начинает передачу; если занят, станция ожидает завершения передачи. Сеть является
равноранговой, поэтому в результате соперничества за канал могут возникнуть коллизии: станция В
может передать свой кадр, не зная, что станция А уже захватила канал, поскольку от станции А к
станции В сигнал распространяется за конечное время. В результате станция В, начав передачу, вошла в
конфликт со станцией А. Возникает коллизия, которая представляет собой явление взаимного искажения
кадров, отправленных почти одновременно несколькими станциями сети. Результатом коллизии является
«затор» или «пробка»  короткая последовательность бит с хаотическим распределением единиц и нулей.
«Пробка» распространятся по всей сети, ее получают все станции, в том числе и те, которые только что
отправили в канал свои кадры. Для них это сигнал («пробка» во много раз короче кадра), что
отправленные кадры потеряны, и необходима их повторная передача.
Важным аспектом коллизии является «окно коллизии»  интервал времени, необходимый для
распространения «пробки» по каналу и обнаружения ее любой станцией сети. В наихудших для
одноканальной сети условиях время, необходимое для обнаружения коллизии, в два раза больше
задержки распространения сигнала в канале, так как образовавшаяся «пробка» должна достигнуть всех
станций сети. Чтобы окно коллизии было меньше, такой способ доступа целесообразно применять в
сетях с небольшими расстояниями между станциями, т.е. , в локальных сетях (вероятность появления
коллизий возрастает с увеличением этого расстояния).
Коллизия  это нежелательное явление, приводящее к ошибкам в работе сети и поглощающее много
времени для ее обнаружения и ликвидации последствий. Поэтому необходимо реализовать некоторый
алгоритм, позволяющий либо избежать коллизий, либо минимизировать их последствия. В сети
CSMA/CD эта проблема решается на уровне управления доступом к среде. При обработке коллизии
компонент управления доступом к среде передающей станции выполняет две функции:
• усиливает эффект коллизии путем передачи специальной последовательности битов с целью удлинения
«пробки» так, чтобы ее смогли заметить все другие передающие станции, вовлеченные в коллизию
(«пробка» должна быть по меньшей мере длиной в 32 бита, но не более 48 бит). Ограничение длины
«пробки» сверху необходимо для того, чтобы станции ошибочно не приняли ее за действительный кадр.
Любой кадр длиной менее 64 байт считается фрагментом испорченного сообщения и игнорируется
принимающими станциями сети;
• после выполнения первой функции прекращает передачу и планирует ее на более позднее время,
определяемое на основе случайного выбора интервала ожидания перед повторной выдачей испорченного
кадра.
Сети CSMA/CD реализуются достаточно просто и при малой загрузке обеспечивают быстрый доступ к
передающей среде, а также позволяют легко подключить и отключить станции. Они обладают высокой
живучестью, поскольку большинство ошибочных и неблагоприятных условий приводит либо к молчанию,
либо к конфликту (а обе эти ситуации поддаются обработке) и, кроме того, нет необходимости в
центральном управляющем органе сети. Их основной недостаток: при больших нагрузках время
ожидания доступа к передающей среде становится большим и меняется непредсказуемо, следовательно,
не гарантируется обеспечение предельно допустимого времени доставки кадра. Такие системы доступа
применяются в незагруженных локальных сетях с небольшим числом абонентских станций (с
увеличением числа станций увеличивается вероятность возникновения коллизий).
Метод передачи маркера широко используется в неприоритетных и приоритетных сетях с
магистральной (шинной), звездообразной и кольцевой топологией. Он относится к классу селективных
методов: право на передачу данных станции получают в определенном порядке, задаваемом с помощью
маркера, который представляет собой уникальную последовательность бит информации (уникальный
кадр). Магистральные сети, использующие этот метод, называются сетями типа «маркерная шина», а
кольцевые сети  сетями типа «маркерное кольцо».
Протокол типа «маркерная шина» (рис. 5) применяется в локальных сетях с шинной или
звездообразной топологией. Право пользования каналом передается организованным путем. Маркер
содержит адресное поле, где записывается адрес станции, которой предоставляется право доступа в
канал. Станция, получив маркер со своим адресом, имеет исключительное право на передачу данных
(кадра) по физическому каналу. Вслед за своим кадром станция отправляет маркер другой станции, которая является очередной по установленному порядку владения правом на передачу (для этого в
адресном поле маркера стирается свой адрес и вместо него записывается адрес очередной станции, так
как каждой станции известен идентификатор очередной станции). Станции получают маркер в
циклической последовательности, при этом в физическом канале формируется так называемое
логическое кольцо. Все станции «слушают» канал, но захватить его для передачи данных может только
та станция, которая указана в адресном поле маркера. Работая в режиме прослушивания канала, принять
переданный кадр может станция, адрес которой указан в поле адреса получателя этого кадра.
В сетях типа «маркерная шина», помимо передачи маркера, решается проблема потери маркера изза
повреждения одного из узлов сети и реконфигурации логического кольца, когда в кольцо добавляется
или из него удаляется один из узлов.
Преимущества таких сетей:
• не требуется физического упорядочения подключенных к шине станций, так как с помощью механизма
логической конфигурации можно обеспечить любой порядок передачи маркера;
• имеется возможность использования в загруженных сетях;
• возможна передача кадров произвольной длины.
Протокол типа «маркерное кольцо» применяется в локальных сетях с кольцевой топологией, где
сигналы распространяются через однонаправленные двухточечные пути между узлами. Узлы и
однонаправленные звенья соединяются последовательно, образуя кольцо (рис. 6). В отличие от сетей с
шинной типологией, где узлы действуют только как передатчики или приемники и отказ узла или
удаление его из сети не влияет на передачу сигнала к другим узлам, здесь все узлы играют активную
роль, участвуя в ретрансляции, усилении, анализе и модификации приходящих сигналов.
Рис. 6. Протокол типа «маркерное кольцо»: а  маркер свободен; б  маркер занят; М  маркер; К  кадр;
КИУ  кольцевое интерфейсное устройство
В качестве маркера также используется уникальная последовательность битов, но он не имеет адреса.
Маркер снабжается полем занятости, в котором записывается один из кодов, обозначающих его
состояние  свободное или занятое. Если ни один из узлов сети не имеет данных для передачи, свободный
маркер циркулирует по кольцу, совершая однонаправленное (против часовой стрелки) перемещение. В
каждом узле маркер задерживается на время, необходимое для его приема, анализа с целью установления
занятости и ретрансляции. В выполнении этих функций задействованы кольцевые интерфейсные
устройства (КИУ).
Свободный маркер означает, что кольцевой канал свободен и что любая станция, имеющая данные для
передачи, может его использовать. Получив свободный маркер, станция с готовым для передачи кадром
меняет состояние маркера на «занятый», передает его дальше по кольцу и добавляет к нему кадр.
Занятый маркер вместе с кадром совершает полный оборот по кольцу и возвращается к станции
отправителю. По пути станцияполучатель, удостоверившись по адресной части кадра, что именно ей он
адресован, снимает копию с кадра. Изменить состояние маркера снова на свободное может только тот
узел, который изменил его на занятое. По возвращении занятого маркера с кадром данных к станции
отправителю кадр удаляется из кольца, а состояние маркера меняется на свободное, после чего любой
узел может захватить маркер и начать передачу данных. С целью предотвращения монополизации канала
станцияотправитель не может повторно использовать возвращенный к ней маркер для передачи другого
кадра данных. Если после передачи свободного маркера в кольцо он, совершив полный оборот,
возвращается к станцииотправителю в таком же состоянии (это означает, что все другие станции сети не
нуждаются в передаче данных), станция может совершить передачу другого кадра.
В кольцевой сети с передачей маркера также решается проблема потери маркера в результате ошибок
при передаче или при сбоях в узле. Отсутствие передач в сети означает потерю маркера. Функции
восстановления работы сети в таких случаях выполняет сетевой мониторный узел.
Можно указать на следующие преимущества протокола типа «маркерное кольцо»: • протокол может быть использован в загруженных сетях;
• имеется принципиальная возможность (и в некоторых сетях она реализована) осуществлять
одновременную передачу несколькими станциями сети;
• имеется возможность проверки ошибок при передаче данных: станцияотправитель, получив свой кадр
от станцииполучателя, сверяет его с исходным вариантом кадра. В случае наличия ошибки кадр
передается повторно.
Недостатки такого протокола:
• протокол целесообразно использовать только в локальных сетях с относительно небольшим
количеством станций, так как в противном, случае время на передачу сообщения, состоящего из многих
кадров, может оказаться неприемлемо большим;
• невозможность передачи кадров произвольной длины;
• в простейшем (описанном выше) исполнении не предусматривается использование приоритетов,
вследствие чего станция, имеющая для передачи важную информацию, вынуждена ждать освобождения
маркера, что сопряжено с опасностью несвоевременной доставки данных адресату.
Приоритетные системы однорангового типа представлены тремя подходами, реализованными в
приоритетных слотовых системах (в системах с приоритетами и временным квантованием), в системах с
контролем несущей частоты без коллизий и в системах с передачей маркера с приоритетами.
Приоритетные слотовые системы подобны бесприоритетным системам с мультиплексной передачей
и временным разделением, однако использование канала производится на приоритетной основе.
Критериями для установления приоритетов могут быть: предшествующее владение слотом; объем
передаваемых данных (чем он меньше, тем вышеприоритет) и др. Здесь возможно децентрализованное
обслуживание, но для этого необходима загрузка параметров приоритетов в память каждой станции.
Недостатки системы: длина данных строго ограничена (в течение заданного слота они должны быть
переданы); существует возможность простоя канала, присущая всем протоколам, которые реализуют
методы доступа, основанные на резервировании времени.
В системах с контролем несущей частоты без коллизий используется специальная логика для
предотвращения коллизий. Каждая станция сети имеет дополнительное устройство  таймер или арбитр.
Оно определяет, когда станция может вести передачу без опасности появления коллизий. Главная
станция для управления использованием канала не предусматривается. Установка времени на таймере,
по истечении которого станция может вести передачу данных, осуществляется на приоритетной основе.
Для станции с наивысшим приоритетом переполнение таймера наступает раньше, однако если она не
намерена вести передачу, канал будет находиться в состоянии покоя, т.е. свободен, и тогда следующая
по приоритету станция может захватить канал. Такие системы могут использоваться в более
загруженных и протяженных сетях. Уменьшается также время простоя канала. Все это достигается за
счет усложнения оборудования системы.
Системы с передачей маркера с приоритетами применяются обычно в локальных сетях с кольцевой
топологией.
Для каждой станции сети устанавливается свой уровень приоритета, причем чем выше уровень, тем
меньше его номер. Назначение приоритетной схемы предусматривает цель: дать возможность каждой
станции зарезервировать использование канала для следующей передачи. Каждая станция анализирует
перемещающийся по кольцу маркер, который содержит поле резервирования (ПР). Если собственный приоритет выше, чем значение приоритета в ПР маркера, станция увеличивает значение приоритета в ПР
до своего уровня, резервируя тем самым маркер на следующий цикл. Если в данном цикле какаято
другая станция не увеличит еще больше значение уровня приоритета в ПР, этой станции разрешается
использовать маркер и канал во время следующего цикла передачи по кольцу (за время цикла маркер
совершает полный оборот по кольцу). Для того чтобы запросы на обслуживание со стороны станций с
низким приоритетом не были потеряны, станция, захватившая маркер, должна запомнить в своей памяти
предыдущее значение уровня приоритета в поле резервирования. После «высвобождения» маркера, когда
он завершит полный оборот по кольцу, станция восстанавливает в ПР предыдущий запрос к сети,
имеющий более низкий приоритет.
Такой протокол более приемлем для обслуживания запросов, существенно отличающихся по степени их
важности и срочности. Однако его применение требует значительного усложнения процедуры
обслуживания запросов.

file_name: билет 4 тема 4.docx

intro:
Метод доступа к передающей среде - это совокупность правил, по которым узлы сети получают доступ к ресурсу. Иначе: это способ «захвата» передающей среды, способ определения того, какая из рабочих станций сети может следующей использовать ресурсы сети. Так же называется набор правил (алгоритм), используемых сетевым оборудованием, чтобы направить поток сообщений через сеть, а также один из основных признаков, по которым различают сетевое оборудование.
Методы доступа к передающей среде реализуются протоколами передачи данных (ППД) нижнего уровня (протоколами управления каналом). ППД нижнего уровня - это совокупность процедур, выполняемых на нижних уровнях модели ВОС по управлению потоками данных между рабочими станциями сети на одном физическом канале связи.

информатика

group: Дисциплины

title: Лекция "Управление доступом к предающей среде. Методы и протоколы доступа."


extracted_text:
билет 5 тема 3
100 Микроядерная архитектура ОС.

  составляющие   многослойное   ядро,
Микроядерная   архитектура   является   альтернативой   классическому   способу   по
строения   операционной   системы.   Под   классической   архитектурой   в   данном   случае
понимается структурная организация ОС, в соответствии с которой все основные функции
операционной   системы,
  выполняются   в
привилегированном   режиме.   При   этом   некоторые   вспомогательные   функции   ОС
оформляются в виде приложений и выполняются в пользовательском режиме наряду с
обычными   пользовательскими   программами   (становясь   системными   утилитами   или
обрабатывающими программами). Каждое приложение пользовательского режима работает
в   собственном   адресном   пространстве   и   защищено   тем   самым   от   какоголибо   вмеша
тельства других приложений. Код ядра, выполняемый в привилегированном режиме, имеет
доступ   к   областям   памяти   всех   приложений,   но   сам   полностью   от   них   защищен,
Приложения обращаются к ядру с запросами на выполнение системных функций.
Суть   микроядерной   архитектуры   состоит   в   следующем.   В   привилегированном
режиме остается работать только очень небольшая часть ОС, называемая микроядром (рис.
10). Микроядро защищено от остальных частей ОС и приложений.  В состав микроядра
обычно входят машиннозависимые модули, а также модули, выполняющие базовые (но не
все!)   функции   ядра   по   управлению   процессами,   обработке   прерываний,   управлению
виртуальной  памятью, пересылке  сообщений и  управлению  устройствами вводавывода,
связанные   с   загрузкой   или   чтением   регистров   устройств.   Набор   функций   микроядра
обычно соответствует функциям слоя базовых механизмов обычного ядра. Такие функции
операционной   системы   трудно,   если   не   невозможно,   выполнить   в   пространстве
пользователя.
ядра   оформляются   в   виде   приложений,   работающих   в   пользовательском   режиме.
Однозначного   решения   о   том,   какие   из   системных   функций   нужно   оставить   в
привилегированном   режиме,   а   какие   перенести   в   пользовательский,   не   существует.   В
общем случае многие менеджеры ресурсов, являющиеся неотъемлемыми частями обычного
ядра — файловая система, подсистемы управления виртуальной памятью и процессами,
менеджер безопасности и т. п., — становятся «периферийными» модулями, работающими в
пользовательском режиме.
Работающие   в   пользовательском   режиме  менеджеры  ресурсов   имеют   принципи
альные   отличия   от   традиционных   утилит   и   обрабатывающих   программ   операционной
системы, хотя при микроядерной архитектуре все эти программные компоненты также
оформлены   в   виде   приложений.   Утилиты   и   обрабатывающие   программы   вызываются   в
основном   пользователями.   Ситуации,   когда   одному   приложению   требуется   выполнение
функции   (процедуры)   другого   приложения,   возникают   крайне   редко.   Поэтому   в
операционных системах с классической архитектурой отсутствует механизм, с помощью
которого одно приложение могло бы вызвать функции другого.
Совсем другая ситуация возникает, когда в форме приложения оформляется часть
операционной системы. Основным назначением такого приложения (т.к. оно представляет
собой часть ОС) является обслуживание запросов других приложений, например создание
процесса, выделение памяти, проверка прав доступа к ресурсу и т. д. Такие приложения,
вынесенные     в   пользовательский   режим   и   выполняющие   роль     менеджеров   ресурсов, называются  серверами ОС, то есть модулями, основным назначением которых является
обслуживание запросов локальных приложений и других модулей ОС. Очевидно, что для
реализации   микроядерной   архитектуры   необходимым   условием   является   наличие   в
операционной   системе   удобного   и   эффективного   способа   вызова   процедур   одного
процесса из другого. Поддержка такого механизма и является одной из главных задач
микроядра.
Схематично механизм обращения к функциям ОС, оформленным в виде серверов,
выглядит следующим образом (рис. 11).
Каждый  сервер  выполняется   в   пользовательском   режиме,   выполняя   циклическую
проверку, не появился ли запрос от клиента на одну из его сервисных функций. Клиент,
которым   может   быть   либо   прикладная   программа,   либо   другой   компонент   ОС,
запрашивает выполнение некоторой функции у соответствующего  сервера, посылая ему
сообщение. Непосредственная передача сообщений между приложениями невозможна, так
как их адресные пространства изолированы друг от друга. Микроядро, выполняющееся в
привилегированном   режиме,   имеет   доступ   к   адресным   пространствам   каждого   из   этих
приложений   и   поэтому   может   работать   в   качестве   посредника.   Микроядро   сначала
передает   сообщение,   содержащее   имя   и   параметры   вызываемой   процедуры   нужному
серверу,   затем   сервер   выполняет   запрошенную   операцию,   после   чего   ядро   возвращает
результаты клиенту с помощью другого сообщения. Таким образом, работа микроядерной
операционной   системы   соответствует   известной   модели   клиентсервер,   в   которой   роль
транспортных средств выполняет микроядро.

file_name: билет 5 тема 3.docx

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

title: Лекция "Микроядерная архитектура ОС. "


extracted_text:
билет 6 тема 3
Задачи, возлагаемые на интерфейс прикладного программирования.
Интерфейс прикладного программирования предназначен для
использования прикладными программами системных ресурсов ОС и
реализуемых ею функций. API описывает совокупность функций и
процедур, принадлежащих ядру или надстройкам ОС.
  API (application programming interface, в переводе– интерфейс
программирования приложений) используется в том случае, если
необходимо предоставить сторонним разработчикам часть
низкоуровневого функционала некоторой системы.
•    Класс задач, в которых используется API, разнообразен. Вот несколько примеров: вы
являетесь   владельцем   базы   данных   всех   жителей   страны   и   хотите   предоставить
возможность   различным   компаниям   через   их   корпоративные   приложения   пользоваться
вашей   базой.   В   этом   случае,   вам   необходим   API,   т.к.   просто   продать   базу   данных
экономически невыгодно и несёт в себе риск по утечке информации. Другой пример: у вас
есть   некоторая   мультифункциональая   система   и   вы   хотите   предоставить   её   часть   для
эволюции другим программистам.

file_name: билет 6 тема 3.docx

intro:
Интерфейс прикладного программирования предназначен для использования прикладными программами системных ресурсов ОС и реализуемых ею функций. API описывает совокупность функций и процедур, принадлежащих ядру или надстройкам ОС.
•  API (application programming interface, в переводе– интерфейс программирования приложений) используется в том случае, если необходимо предоставить сторонним разработчикам часть низкоуровневого функционала некоторой системы.
•  Класс задач, в которых используется API, разнообразен. Вот несколько примеров: вы являетесь владельцем базы данных всех жителей страны и хотите предоставить возможность различным компаниям через их корпоративные приложения пользоваться вашей базой.

title: Лекция "Задачи, возлагаемые на интерфейс прикладного программирования."


extracted_text:
билет 7 тема 3
Реализация интерфейсов прикладного программирования.
Существует несколько вариантов реализации API:
 реализация на уровне ОС;
 реализация на уровне системы программирования;
 реализация на уровне внешней библиотеки процедур и функций.
Возможности API можно оценивать со следующих позиций:
 эффективность выполнения функций API — включает в себя скорость выполнения
функций и объем вычислительных ресурсов, потребных для их выполнения;
 широта предоставляемых возможностей;
 зависимость прикладной программы от архитектуры целевой вычислительной системы.
В идеале хотелось бы иметь набор функций API, выполняющихся с наивысшей
эффективностью, предоставляющих пользователю все возможности современных ОС и
имеющих минимальную зависимость от архитектуры вычислительной системы (еще лучше
— лишенных такой зависимости).
Добиться наивысшей эффективности выполнения функций API практически трудно по тем
же причинам, по которым невозможно добиться наивысшей эффективности выполнения
для любой результирующей программы. Поэтому об эффективности API можно говорить
только в сравнении его характеристик с другим API.
Что касается двух других показателей, то в принципе нет никаких технических
ограничений на их реализацию. Однако существуют организационные проблемы и узкие
корпоративные интересы, тормозящие создание такого рода библиотек.

file_name: билет 7 тема 3.docx

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

title: Лекция "Реализация интерфейсов прикладного программирования."


extracted_text:
билет 8 тема3
103
Виды совместимости
    Виды совместимости ОС.
Свойство ОС, характеризующее возможность выполнения в ОС приложений, написанных для других
ОС, называется совместимостью.
Существует два принципиально отличающихся вида совместимости, которые не следует путать:
совместимость на двоичном уровне
  и

обычно хранятся в компьютере в виде исполняемых файлов, содержащих двоичные образы кодов и
данных.
 совместимость на уровне исходных текстов. Приложения
 Двоичная совместимость достигается в том случае, если можно взять исполняемую программу,
работающую в среде одной ОС, и запустить ее на выполнение в среде другой ОС.
Совместимость на уровне исходных текстов требует наличия соответствующих компиляторов в
составе программного обеспечения компьютера, на котором предполагается использовать данное
приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима
перекомпиляция исходных текстов программ в новые исполняемые модули.
Таким образом, совместимость на уровне исходных текстов наиболее важное значение имеет для
разработчиков приложений, в распоряжении которых находятся эти исходные тексты. Для конечных же
пользователей практическое значение имеет только двоичная совместимость, так как только в этом
случае они могут без специальных навыков и умений использовать программный продукт, поставляемый
в виде двоичного исполняемого кода, в различных операционных средах и на разных компьютерах. Для
пользователя, купившего в свое время пакет программ для MSDOS, важно, чтобы он мог запускать этот
привычный ему пакет без какихлибо изменений или ограничений на своей новой машине, работающей,
например, под управлением Windows NT. Множественные прикладные среды как раз и обеспечивают
совместимость данной ОС с приложениями, написанными для других ОС и процессоров, на двоичном
уровне, а не на уровне исходных текстов.
Каким типом совместимости – двоичной или совместимостью исходных текстов обладает ОС,
зависит от многих факторов. Самый значительный из них – архитектура процессора, на котором работает
ОС. Только в том случае, если процессор использует тот же набор команд (возможно, даже более
расширенный, но ни в коем случае не уменьшенный) и тот же диапазон адресов, двоичная совместимость
может быть достигнута довольно просто. Достаточно соблюсти несколько следующих условий:
 вызовы функций API, которые содержит приложение, должны поддерживаться данной ОС;
 внутренняя структура исполняемого файла приложения должна соответствовать структуре
исполняемых файлов данной ОС.
Несравнимо сложнее достигнуть двоичной совместимости операционным системам,
предназначенным для выполнения на процессорах, имеющих различающиеся архитектуры. Кроме
соблюдения приведенных выше условий, необходимо также организовать эмуляцию двоичного кода.
Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного
 Способы реализации совместимости
приложения. В таких ОС, построенных с использованием микроядерной концепции, как, например
Windows NT или Workspace OS, прикладные среды выполняются в виде серверов пользовательского
режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены
глубоко в ОС.
Стандартная многоуровневая структура ОС является основой для наиболее очевидного варианта
реализации множественных прикладных сред. На рис. 9 операционная система ОС1 поддерживает кроме
своих “родных” приложений приложения операционных систем ОС2 и ОС3. Для этого   в ее составе
имеются специальные приложения – прикладные программные среды, которые транслируют интерфейсы
“чужих” операционных систем API ОС2 и API ОС3 в интерфейс своей “родной” операционной системы
API ОС1. Так, например, в случае, если бы в качестве ОС2 выступала операционная система UNIX, а в
качестве OC1 – OS/2, для выполнения системного вызова создания процесса fork() в UNIXприложении
программная среда должна была обратиться к ядру операционной системы OS/2 с системным вызовом
DosExecPgm(). Трудности при такой реализации возникают вследствие того, что поведение почти всех функций,
составляющих  API  одной  ОС, как  правило,  существенно  отличается   от поведения  соответствующих
(если   они   вообще   есть)   функций   другой   ОС.   Например,   чтобы   функция   создания   процесса   в   OS/2
DosExecPgm()   полностью   соответствовала   функции   создания   процесса   fork()   в   UNIXподобных
системах,   ее   нужно   изменить   таким   образом,   чтобы   она   поддерживала   возможность   копирования
адресного пространства родительского процесса в пространство процессапотомка, хотя при нормальном
поведении   этой   функции   память   процессапотомка   инициализируется   на   основе   данных   нового
исполняемого файла.
Другой   вариант   реализации   множественных   прикладных   сред   подразумевает   наличие   в   ОС
нескольких равноправных прикладных программных интерфейсов. В приведенном на рис. 10 примере
операционная система поддерживает приложения, написанные для ОС1, ОС2 и ОС3. Это достигается
путем   размещения   непосредственно   в   пространстве   ядра   системы   прикладных   программных
интерфейсов всех этих ОС: API ОС1, API   ОС2 и API ОС3. В этом варианте функции уровня API
обращаются к функциям нижележащего уровня ОС, которые должны поддерживать все три в общем
случае несовместимые прикладные среды. Несмотря на то, что в разных ОС поразному осуществляется
управление системным временем, используется разный формат времени дня, на основании собственных
алгоритмов   разделяется   процессорное   время   и   т.д.,   функции   каждого   прикладного   программного
интерфейса реализуются с учетом специфики соответствующей ОС. Для каждой ОС будет полностью
реализован свой прикладной интерфейс даже   в том случае, если некоторые из функций   различных
интерфейсов имеют аналогичное назначение. Выбор того или иного варианта API осуществляется на
основании идентифицирующих характеристик, передаваемых в ядро соответствующим процессом.
Естественно, существует и способ построения множественных прикладных сред, использующий
концепцию микроядерного подхода. При этом крайне важно отделить базовые, общие для всех
прикладных сред, механизмы ОС от специфических для каждой из прикладных сред высокоуровневых
функций, решающих стратегические задачи. В соответствии с микроядерной архитектурой все функции
ОС реализуются микроядром и серверами пользовательского режима. Важно заметить, что каждая
прикладная среда оформляется в виде отдельного сервера пользовательского режима и не включает
базовых механизмов (рис. 11). Приложения, используя API, обращаются с системными вызовами к
соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает запрос,
выполняет его (возможно, обращаясь для этого за помощью к базовым функциям микроядра) и отсылает
приложению результат. В ходе выполнения запроса прикладной среде приходится, в свою очередь,
обращаться к базовым механизмам ОС, реализуемым микроядром и другими серверами ОС.
Такому подходу к конструированию множественных прикладных средств присущи все достоинства
и недостатки микроядерной архитектуры, в частности:
 очень просто можно добавлять и исключать прикладные среды, что является следствием хорошей
расширяемости микроядерных ОС;
 надежность и стабильность выражаются в том, что при отказе одной из прикладных сред все
остальные сохраняют работоспособность;
 низкая производительность микроядерных ОС сильно сказывается на скорости работы прикладных
сред, а значит, и на скорости выполнения приложений.
Создание в рамках одной ОС нескольких прикладных сред для выполнения приложений различных
ОС представляет собой путь, который позволяет иметь единственную версию программы и переносить ее
между ОС. Множественные прикладные среды обеспечивают совместимость на двоичном уровне данной
ОС   с   приложениями,   написанными   для   других   ОС.   В   результате   пользователи   получают   большую
свободу выбора ОС и более легкий доступ к качественному программному обеспечению. Однако следует
заметить,   что   реализация   совместимости   прикладных   сред   ОС,   кардинально   отличающихся
используемым аппаратным обеспечением, весьма трудоемкая и сложная работа, а эффект от нее может
оказаться слишком малым.
К   усовершенствованным   ОС,   явно   содержащим   средства   множественных   прикладных   сред,
относятся: IBM OS/2 2.x  и Workplace OS, Microsoft Windows NT, PowerOpen  компании PowerOpen
Association, версии UNIX от Sun Microsystems, IBM и HewlettPackard. Кроме того, некоторые компании
переделывают свои интерфейсы пользователя в модули прикладных сред, а другие предлагают продукты
для эмуляции и трансляции прикладных сред, работающие в качестве прикладных программ. Рассмотрим, каким образом реализуются множественные прикладные среды  в уже описанной нами
ранее ОС Windows NT. При разработке NT важнейшим рыночным требованием являлось обеспечение
поддержки по крайней мере двух уже существующих на то время программных интерфейсов – OS/2 и
POSIX, а также возможности достаточно легкого добавления других API в будущем.
Как   уже   отмечалось,   для   того   чтобы   программа,   написанная   для   одной   ОС,   могла   быть
выполнена   в   рамках   другой   ОС,   недостаточно   лишь   совместимости   API.   Кроме   этого,   ей
необходимо   “родное”   окружение:   структура   процесса,   средства   управления   памятью,   средства
обработки ошибок и исключительных ситуаций, механизмы защиты ресурсов и семантика файлового
доступа.   Отсюда   ясно,   что   поддержка   нескольких   прикладных   программных   сред   является   очень
непростой задачей, тесно связанной со структурой ОС. Эта задача была успешно решена в Windows NT,
при этом в полной мере использовался опыт разработчиков ОС Mach из университета КарнегиМеллона,
которые   смогли   в   своей   клиентсерверной   реализации   UNIX   отделить   базовые   механизмы   ОС   от
серверов API различных операционных систем.
Windows NT поддерживает пять прикладных сред операционныхсистем: MSDOS, 16разрядный
Windows, OS/2 1.x, POSIX и 32разрядный Windows (Win32). Все пять прикладных сред реализованы как
подсистемы окружения. Каждая работает в собственном защищенном пользовательском пространстве.
Подсистема Win32 обеспечивает поддержку дисплея, клавиатуры и мыши для четырех оставшихся
подсистем.
16битовые приложения DOS и Windows работают на VDM (virtual DOS machines – виртуальные
машины DOS), каждая из которых эмулирует полный 80x86 процессор с MSDOS. В NT VDM является
приложением Win32, значит, как и обычные модули прикладных сред для UNIX, приложения DOS и 16
битовой Windows расположены в слое непосредственно над подсистемой Win32.
Подсистемы   OS/2   и   POSIX  построены   подругому.   В  качестве   полноценных   подсистем   NT   они
могут взаимодействовать с подсистемой Win32 для получения доступа к вводу и выводу, но также могут
обращаться непосредственно к исполнительной системе NT за другими средствами ОС. Подсистема OS/2
может выполнять многие имеющиеся приложения OS/2 символьного режима, включая OS/2 SQL Server, а
также поддерживает именованные каналы и NetBIOS.
Однако возможности подсистемы POSIX весьма ограничены, несмотря на непосредственный доступ
ее к службам ядра. Приложения POSIX должны быть откомпилированы специально для Windows NT. NT
не работает двоичным кодом, предназначенным для таких POSIXсовместимых систем, как UNIX. К
тому же подсистема POSIX NT не поддерживает печать, сетевой доступ, за исключением доступа к
удаленным файловым системам, и многие другие средства Win32, например, отображение на память
файлов и графику.
  NT executive выполняет базовые функции ОС и является той основой, на которой подсистемы
окружения   реализуют   свои   приложения.   Все   подсистемы   равноправны   и   могут   вызывать   “родные”
функции NT для создания соответствующей среды приложений.

file_name: билет 8 тема3.docx

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

title: Лекция "Виды совместимости ОС."


extracted_text:
билет 9 тема 3
1. Эволюция ОС.
Операционная Система это - комплекс управляющих и
обрабатывающих программ, которые, с одной стороны, выступают как
интерфейс между устройствами вычислительной системы и прикладными
программами, а с другой стороны — предназначены для управления
устройствами, управления вычислительными процессами, эффективного
распределения вычислительных ресурсов между вычислительными
процессами и организации надёжных вычислений. Это определение
применимо к большинству современных операционных систем общего
назначения.
В логической структуре типичной вычислительной системы
операционная система занимает положение между устройствами с их
микроархитектурой, машинным языком и, возможно, собственными
(встроенными) микропрограммами — с одной стороны — и прикладными
программами с другой.
Разработчикам программного обеспечения операционная система
В большинстве вычислительных систем операционная система
позволяет абстрагироваться от деталей реализации и
функционирования устройств, предоставляя минимально
необходимый набор функций (см.: интерфейс программирования
приложений).
является основной, наиболее важной (а иногда и единственной) частью
системного программного обеспечения. С 1990-х годов наиболее
распространёнными операционными системами являются системы
семейства Windows и системы класса UNIX (особенно Linux и Mac OS).
Предшественником операционных систем следует считать служебные
программы (загрузчики и мониторы), а также библиотеки часто
используемых подпрограмм, начавшие разрабатываться с появлением
универсальных компьютеров 1го поколения (конец 1940х годов). Служебные
программы минимизировали физические манипуляции оператора с
оборудованием, а библиотеки позволяли избежать многократного
программирования одних и тех же действий (осуществления операций
вводавывода, вычисления математических функций и т. п.).
В 1950—1960х годах сформировались и были реализованы основные
идеи, определяющие функциональность ОС: пакетный режим,
разделение времени и многозадачность, разделение полномочий,
реальный масштаб времени, файловые структуры и файловые системы.
I. 1945-1955 г.г. В восемнадцатом веке английский математик
Чарльз Бэббидж изобрёл компьютер (теоретически). ОС он не
имел. С середины 40-х годов были изобретены первые
ламповые вычислительные устройства. Занимался
разработкой, программированием и использованием один
коллектив. ОС ещё не было. Были только библиотеки
служебных и математических программ.
II. 1955-1965 г.г. Появление полупроводниковых элементов.
Выполнение практических задач. Разделение персонала на
программистов, операторов и так далее. Появились
алгоритмические языки, а следовательно, и компиляторы. Из-
за высокой стоимости процессорного времени появились
системы пакетной обработки. Формируется группа задач, а затем они выполняются на тачке. Пакет заданий тогда был на
перфокартах.
III. 1965-1980 г.г. Переход от полупроводников к ИС. Появление
семейства программно совмести-мых машин. Семейство IBM
360, ЕС ЭВМ. Возникла необходимость создания ОС. OS/360.
Важней-шее достижение - мультипрограммирование, то есть
попеременно выполняются несколько программ. Данная
система использовала обработку как пакетную, так и с
разделением времени.
IV. 1980-2002 г.г. Появление СБИС. Удешевление тачек.
Особенность: доступ к тачке получили ламеры. ОС стали иметь
дружественный интерфейс. Идёт бурное развитие сетей.

file_name: билет 9 тема 3.docx

title: Лекция "Эволюция ОС."


extracted_text:
билет 10 тема 3
105  Понятие мультипрограммирования. Способы управления процессом в режиме
мультипрограммирования.
С понятиями процесс и поток тесно связано понятие мультипрограммирования.
Мультипрограммирование, или многозадачность (multitasking),  это способ организации
вычислительного процесса, при котором на одном процессоре попеременно выполняются
сразу несколько задач (программ).
Общие критерии эффективности мультипрограммирования:
∙ пропускная способность;
∙ удобство работы пользователей;
∙ реактивность системы (заданные интервалы времени).
В зависимости от критерия различают:
∙ системы пакетной обработки;
∙ разделения времени;
∙ системы реального времени.
Мультипрограммирование в системах пакетной обработки
Главная цель: минимизация простоев всех устройств компьютера. Это, как правило, задачи
вычислительного характера. Оператор формирует пакет заданий и вводит его тем или
иным способом во внешнюю память. ОС выбирает из пакета мультипрограммную смесь из
программ, таким образом, чтобы максимально загрузить систему.
В этом режиме невозможно гарантировать выполнение задачи в течении определенного
времени. Мультипрограммирование организованно за счет параллельной работы канала или
контроллера и процессора.
Переключение процессора с одной задачи на другую  инициатива самой задачи. В
подобных системах пользователь отстраняется от вычислительного процесса. Примерами
ОС пакетной обработки являются ОС для мэйнфреймов IBM 360/370/390.
Мультипрограммирование в системах разделения времени
Основной критерий систем разделения времени  повышение удобств и эффективности
работы пользователей. Такие ОС позволяют организовать интерактивную работу
пользователей с несколькими приложениями.
Мультипрограммирование организуется путем выделения каждой задаче некоторого,
достаточно небольшого отрезка времени  кванта. Задача принудительно
приостанавливаются по завершению кванта и в соответствии с заложенным алгоритмом,
выбирается на выполнение новая задача.
Системы разделения времени имеют меньшую пропускную способность по сравнению с
системами пакетной обработки при прочих равных условиях. Это обусловлено потерей
времени на переключение процессора с задачи на задачу.
ОС MS Windows 98/NT/2000/XP, Unix являются примерами систем разделения времени.
ОС реального времени используются при управлении техническими объектами или
технологическими процессами
Особенность: наличие предельного времени в течении которого должна быть выполнена та
или иная задача (реактивность системы).
Мультипрограммная смесь (т.е. набор задач, одновременно выполняемых) представляет
собой: фиксированный набор заранее разработанных программ, а выбор на выполнение  по
прерываниям (или по расписанию).
Для систем реального времени важна скорость обработки прерываний. Задача
максимальной загрузки устройств  не актуальна.
Мультипроцессорная обработка
Мультипроцессорная обработка  это способ организации вычислительного процесса в
системах с несколькими процессорами. В отличие от организации
мультипрограммирования на одном процессоре, мультипроцессорная обработка предполагает действительно одновременное выполнение нескольких процессов. Это
приводит к усложнению всех алгоритмов ОС.
Симметричная архитектура предполагает однородность всех процессоров и единообразное
их включение в общую схему. Традиционно все процессоры при этом разделяют одну
память и как следствие находятся в одном корпусе.
При асимметричной архитектуре процессоры могут отличаться своими техническими
характеристиками и функциональной ролью. Требование единого корпуса отсутствует.
Система может состоять из нескольких корпусов (в каждом может быть один или
несколько процессоров). Такие устройства называются кластерами.
Для симметричной архитектуры вычислительный процесс может строится симметричным
образом (все процессоры равноправны) или асимметричным (процессоры различаются
функционально).
Для асимметричной архитектуры возможен только асимметричный способ организации.
Мультипрограммирование на основе прерываний
Прерывание – это способ переключения процессора на выполнение потока команд,
отличного от того который выполнялся, с последующим возвратом.
Различают следующие типы прерываний:
∙ внешние (аппаратные);
∙ внутренние (исключения exception);
∙ программные.
Внешние прерывания происходят асинхронно, т.е. происходят в случайный момент времени
в процессе выполнения программы (например, от внешних устройств), внутренние –
синхронно, т.е. возникают по конкретной причине и можно предугадать возникновение
такого прерывания (например, при делении на ноль).
Программные прерывания не являются "истинными" прерываниями. Они возникают при
выполнении определенной команды процессора и применяются в том случае, когда
необходимо выполнить некоторые привилегированные действия (например обратится к
порту компьютера).
Прерываниям равного значения приписываются уровни приоритетов (уровни  IRQ).
Каждое из прерываний обслуживается обработчиком прерываний (Interrupt Service
Routine).
Внешние – обрабатываются драйверами, внутренние – модулями ядра, программные –
процедурами из API.
Механизм прерываний
Механизм прерываний поддерживается аппаратными и программными средствами ОС.
Различают векторный (vectored) и опрашиваемый (polled) типы прерываний. В обоих
способах процессору передается информация об уровне приоритета.
При векторном типе прерывания в процессор передается также адрес обработчика
прерывания.
Для векторного типа схема обработки такова: электрический сигнал  запрос на
подтверждение  вектор  обработчик (например, для шины VMEbus).
Для опрашиваемого схема обработки такова: сигнал  запрос на подтверждение  уровень
приоритета (например, шина ISA). Каждый уровень связан с несколькими устройствами.
Вызываются все обработчики данного уровня. Один опознает свое устройство. (Примеры
шин: ISA, EISA, MCA, PCi, SBus).
Intel Pentium объединяет два типа. устройство выдает сигнал некоторого уровня (IRQ
Interrupt Request), а контроллер вектор. Вектор  это число 0255.
Приоритеты обслуживания могут быть: относительные (обработка прерывания не
прекращается при появлении более приоритетного прерывания) и абсолютные.
Для упорядочивания работы обработчиков введен механизм приоритетных очередей,
которые обслуживает модуль ОС диспетчер прерываний.
Системные вызовы С понятием прерываний тесно связано понятие системных вызовов. Системный вызов
позволяет приложению обратится к процедуре ОС, при этом используется механизм
программных прерываний. В результате упрощается структура приложения, позволяются
действия, запрещенные в пользовательском режиме.
В большинстве ОС системные вызовы осуществляются через диспетчер системных вызовов.
Например для транслятора Си системный вызов – это обычный вызов функции. Транслятор
имеет специальные функции «заглушки» (Stab). В этих функциях присутствует Си
функция с вызовом программного прерывания.
Системные вызовы могут выполнятся синхронно и асинхронно. Большинство выполняются
синхронно. Операции вводавывода – асинхронно. В новых ОС количество асинхронных
вызовов – увеличивается.
Операционные   системы,   поддерживающие   мультипрограммирование,   в  зависимости   от
выбранного   критерия   эффективности   вычислительной   системы   можно   разделить   на
несколько основных типов:  системы пакетной обработки, системы разделения времени и
системы   реального   времени.   Некоторые   операционные   системы   могут   поддерживать
одновременно несколько режимов, например часть задач может выполняться в режиме па
кетной   обработки,   а   часть   –   в   режиме   реального   времени   или   в   режиме   разделения
времени.
Мультипрограммирование (многозадачность, multitasking) – это такой способ
организации вычислительного процесса, при котором на одном процессоре попеременно
выполняются несколько программ. Чтобы поддерживать мультипрограммирование, ОС
должна определить для себя внутренние единицы работы, между которыми будут
разделяться процессор и другие ресурсы компьютера. В ОС пакетной обработки,
распространенных в компьютерах второго и сначала и третьего поколения, такой
единицей работы было задание. В настоящее время в большинстве операционных систем
определены два типа единиц работы: более крупная единица – процесс, или задача, и
менее крупная – поток, или нить. Причем процесс выполняется в форме одного или
нескольких потоков.

file_name: билет 10 тема 3.docx

intro:
С понятиями процесс и поток тесно связано понятие мультипрограммирования.
Мультипрограммирование, или многозадачность (multitasking), - это способ организации вычислительного процесса, при котором на одном процессоре попеременно выполняются сразу несколько задач (программ).
Общие критерии эффективности мультипрограммирования:
• пропускная способность;
• удобство работы пользователей;
• реактивность системы (заданные интервалы времени).
В зависимости от критерия различают:
• системы пакетной обработки;
• разделения времени;
• системы реального времени

title: Лекция "Понятие мультипрограммирования. Способы управления процессом в режиме мультипрограммирования."


extracted_text:
билет 11 тема 2
Структурированные типы данных: массивы, записи, множества в языке Турбо Паскаль
Структурированные типы данных определяют наборы однотипных или разнотипных компонент.
СТРУКТУРИРОВАННЫЕ ТИПЫ
Любой из структурированных типов характеризуется множественностью образующих этот тип
элементов, т.е. переменная или константа структурированного типа всегда имеет несколько
компонентов. Каждый компонент, в свою очередь, может принадлежать структурированному типу,
что позволяет говорить о возможной вложенности типов. В Турбо Паскале допускается произвольная
глубина вложенности типов, однако суммарная длина любого из них во внутреннем представлении не
должна превышать 65520 байт.
Массивы в Турбо Паскале во многом схожи с аналогичными типами данных в других языках
программирования. Отличительная особенность массивов заключается в том, что все их компоненты
суть данные одного типа (возможно структурированного). Эти компоненты можно легко упорядочить
и обеспечить доступ к любому из них простым указанием порядкового номера.
Описание массива задаётся следующим образом:<имя типа> = array [<сп.инд.типов>] of <тип>
Здесь <имя типа>  правильный индификатор;
Array, of – зарезервированные слова (массив, из);
<спюиндютипов>  список из одного или нескольких индексных типов, разделённых запятыми;
квадратные скобки, обрамляющие список,  требование синтаксиса;
<тип>  любой тип Турбо Паскаля.
В качестве индексных типов в Турбо Паскале можно использовать любые порядковые типы, кроме
LongInt и типовдиапазонов с базовым типом LongInt. Глубина вложенности структурированных типов
вообще, а следовательно, и массивов – произвольная, поэтому количество элементов в списке
индексов типов (размерность массива) не ограничено, однако суммарная длина внутреннего
представления любого массива не может быть больше 65520 байт.
ЗАПИСИ
Запись – это структура данных, состоящая из фиксированного числа компонентов, называемых
полями записи. В отличие от массива, компоненты (поля) записи могут быть различного типа. Чтобы
можно было ссылаться на тот или иной компонент записи, поля именуются.
Структура объявления типа записи такова:<имя типа> = RECORD <спюполей> END
Здесь <имя типа>  правильный идентификатор;
RECORD, END – зарезервированные слова (запись, конец);
<сп.полей>  список полей; представляет собой последовательность разделов записи, между которыми
ставится точка с запятой.
МНОЖЕСТВА Множества – это набор однотипных логических связанных друг с другом объектов.
Характер связей между объектами лишь подразумевается программистом и никак не контролируется
Турбо Паскалем. Количество элементов, входящих в множество, может меняются в пределах от 0до
256 (множество, не содержащее элементов, называется пустым).именно непостоянством количества
своих элементов множества отличаются от массивов и записей.
Два множества считаются эквивалентными тогда и только тогда, когда все их элементы одинаковы,
причём порядок следования элементов множества безразличен. Если все элементы одного множества
входят также и в другое, говорят о включении первого множества во второе. Описание типа множества имеет вид:<имя типа> = SET OF <баз.тип>
Здесь <имя типа>  правильный индификатор;
SET, OF – зарезервированные слова (множество, из);
<баз.тип>  базовый тип элементов множества, в качестве которого может использоваться любой
порядковый тип, кроме WORD, INTEGER и LONGINT.
Для задания множества используется так называемый конструктор множества: список спецификаций
элементов множества, отделяемых друг от друга запятыми; список обрамляется квадратными
скобками. Спецификациями элементов могут быть константы или выражения базового типа, а также –
типдиапазон того же базового типа.
СТРОКИ
Тип STRING (строка) в Турбо Паскале широко используется для обработки текстов. Он во многом
похож на одномерный массив символов ARRAY [0..N] OF CHAR, однако, в отличие от последнего,
количество символов в строке – переменной может меняться от 0 до N, где N – максимальное
количество символов в строке. Значение N определяется объявлением типа STRING[N] N и может
быть любой константой порядкового типа, но не больше 255. Турбо Паскаль разрешает не указывать
N, в том случае длина строки принимается максимально возможной, а именно N=255.
Строка в Турбо Паскале трактуется как цепочка символов. К любому символу в строке можно
обратиться точно так же, как к элементу одномерного массива ARRAY [0..N] OF CHAR.
ФАЙЛЫ
Под файлом понимается либо именованная область внешней памяти ПК, либо логическое устройство
– потенциальный источник или приёмник информации. Любой файл имеет три характерные
особенности. Вопервых, у него есть имя, что даёт возможность программе работать одновременно с
несколькими файлами. Вовторых, он содержит компоненты одного типа. Типом компонентов может
быть любой тип Турбо Паскаля, кроме файлов. Иными словами, нельзя создать "файл файлов". В
третьих, длина вновь создаваемого файла никак не оговаривается при его объявлении и
ограничивается только ёмкостью устройств внешней памяти. Файловый тип или переменную
файлового типа можно задать одним из трёх способов:
<имя>= FILE OF <тип>;
<имя>=TEXT;
<имя> = FILE;
Здесь <имя>  имя файлового типа (правильный индификатор);
FILE, OF – зарезервированные слова (файл, из);
TEXT – имя стандартного типа текстовых файлов;
<тип>  любой тип Турбо Паскаля, кроме файлов.
В зависимости от способа объявления можно выделить три вида файлов:
•
•
•
ПРОЦЕДУРНЫЕ ТИПЫ
Процедурные типы — это нововведение фирмы Borland (в стандартном Паскале таких типов нет).
Основное назначение этих типов — дать программисту гибкие средства передачи функций и процедур
в качестве фактических параметров обращения к другим процедурам и функциям.
Для объявления процедурного типа используется заголовок процедуры (функции), в котором
опускается её имя, например:
типизированные файлы (задаются предложением FILE OF…);
текстовые файлы (определяются типом TEXT);
нетипизированные файлы (определяются типом FILE).
type
Proc = procedure;
Proc1 = procedure(var X, Y: Integer);
StrProc = procedure(S: String);
MathFunc = function(X: Real): Real:
DeviceFunc = function(var F: Text): Integer; MaxFunc = function(A, B: Real; F: MathFunc): Real;

Как видно из приведённых примеров существует два вида процедурных типов: типпроцедура и тип
функция.
В программе могут быть объявлены переменные процедурных типов, например, так:
Var
P1: Proc1;
F1, f2: MathFunc;
Ap: array [1..N] of Proc1
Переменным процедурных типов допускается присваивать в качестве значений имена
соответствующих подпрограмм. После такого присваивания имя переменной становится синонимом
имени подпрограммы.
ТИП ОБЪЕКТ
Тип объект — это структура, состоящая из фиксированного числа компонент. Каждая компонента —
это или поле, которое содержит данные определенного типа, или метод, который производит операции
над объектом. Аналогично объявлению переменных, объявление поля, указывает тип данных поля и
идентификатор имени этого поля; и аналогично объявлению процедуры или функции объявление
метода указывает заголовок процедуры, функции, конструктора или деструктора.
Тип объект может наследовать компоненты от другого типа объекта.
Сфера действия типа объекта состоит из него самого и всех его порожденных типов.
В отличие от других типов, тип объект может быть объявлен в части объявления типов в самой
внешней части программы или модуля.
Так, тип объекта не может быть объявлен в части объявления переменных или внутри процедуры,
функции или метода.

ТИП УКАЗАТЕЛЬ
Тип указатель (ссылочный тип) определяет множество значений, которые указывают на динамические
переменные определенного типа, называемого базовым типом. Переменная с типом указатель
содержит адрес динамической переменной в памяти.
Если базовый тип является еще не описанным идентификатором, то он должен быть описан в той же
самой части описания типов, что и тип указатель.
Переменнойуказателю можно присвоить значение с помощью процедуры New, операции @ или
функции Ptr. Процедура New отводит новую область памяти в динамически распределяемой области
для динамических переменных и сохраняет адрес этой области в переменной указателя. Операция @
ориентирует переменную указателя на область памяти, содержащую существующую переменную,
включая и те переменные, которые имеют идентификаторы. Функция Ptr ориентирует переменную
указателя на определенный адрес в памяти.
Зарезервированное слово nil обозначает константу со значением указателя, которая ни на что не
указывает.
Встроенный указатель типа обозначает нетипизованный указатель, то есть указатель, который не
указывает ни на какой определенный тип. Переменные типа Pointer могут быть разыменованы;
указание символа ^ после такой переменной вызывает появление ошибки. Как и значение,
обозначаемое словом nil, значения типа Pointer совместимы со всеми другими типами указателей. В
разделе "Указатели и динамические переменные" в Главе 4 вы можете найти синтаксис ссылки на
динамические переменные, которые указываются с помощью указателяпеременной.
ТИПИЗИРОВАННЫЕ КОНСТАНТЫ
В Турбо Паскале допускается использование типизированных констант. Они задаются в разделе
объявления констант следующим образом: <индификатор> : <тип> = <значение>
паскаль массив константа программа
Здесь <индификатор>  индификатор константы;
<тип>  тип константы;
<значение>  значение константы.
Типизированным константам можно присваивать другие значения в ходе выполнения программы,
поэтому фактически они представляют собой переменные с начальными значениями. Типизированная
константа приобретает указанное в её объявлении значение, т.е. инициируется, лишь один раз: к
моменту начала работы программы. При повторном входе в блок (процедуру или функцию), в
котором она объявлена, инициация типизированной константы не производится и она сохраняет то
значение, которое имела к моменту выхода из блока.
Типизированные константы могут быть любого типа, кроме файлов. Нельзя также объявить
типизированную константу – запись, если хотя бы одно из её полей является полем файлового типа.
Поскольку типизированная константа фактически не отличается от переменной, её нельзя
использовать в качестве значения при объявлении других констант или границ типадиапазона.
КОНСТАНТЫ ПРОСТЫХ ТИПОВ И ТИПА STRING
Объявление таких констант обычно не вызывает трудностей, так как в качестве их значения
используется нетипизированные константы или их идентификаторы.
КОНСТАНТЫМАССИВЫ
В качестве начального значения типизированной константымассива используются список констант,
отделённых друг от друга запятыми; список заключается в круглые скобки.
При объявлении многомерных константмассивов множество констант, соответствующих каждому
измерению, заключается в дополнительные круглые скобки и отделяется от соседнего множества
запятыми. В результате образуются вложенные структуры множеств, причём глубина вложения
должна соответствовать количеству измерений (размерности) массива. Самые внутренние множества
констант связываются с измерением самого правого индекса массива.
КОНСТАНТЫЗАПИСИ
Определение константызаписи имеет следующий вид:
<индификатор> : <тип> (<сп.знач.полей>)
Здесь <индификатор> – индификатор константы;
<тип> – тип записи;
<сп.инд.полей> – список значений полей.
Список значений полей представляет собой список из последовательностей вида: имя поля, двоеточие
и константа. Элементы списка отделяются друг от друга двоеточиями.
КОНСТАНТЫМНОЖЕСТВА
Значение типизированной константымножества задаётся в виде правильного конструктора множеств.
КОНСТАНТЫУКАЗАТЕЛИ
Единственным значением типизированной константыуказателя может быть только NIL.

file_name: билет 11 тема 2.docx

title: Лекция "Структурированные типы данных: массивы, записи, множества в языке Турбо Паскаль"