К классу СПО относят:

1. ОС;

2. Файловые системы;

3. СУБД;

4. Модули поддержки взаимодействия между различными слоями СПО;

5. Системы разработки ПО;

6. Утилиты и другие вспомогательные модули.

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

Традиционно подсистема ввода/вывода (I/0) содержит наиболее сложно реализуемую часть системной функциональности.

Причины:

1. Разнообразие категорий устройств ввода/вывода (I/O);

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

3. Зависимость согласования интерфейсов и протоколов с вендорами аппаратуры.

Выделения какого-либо аспекта функциональности в отдельный слой может производиться на двух уровнях:

1. На уровне интерфейса;

2. На уровне реализации.

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

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

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

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

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

Каждая ОС реализует, как правило, несколько операционных сред. Пример операционной среды – Win32 (Windows).

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

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

Условно можно отнести к операционной среде также набор средств библиотеки времени исполнения (run – time library) какой-либо широко используемой среды разработки, ставшим стандартным дефактом.

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

1)

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

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

Реентерабельность

Так как любое повторяющееся вхождение имеет свой собственный контекст, пересекающийся с контекстами других вызовов.

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

Для обеспечения свойства повторной входимости (реентерабельности) следует каждый вызов снабжать уникальным контекстом.

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

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

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

Такие ресурсы (объекты), которые сходны с приложениями, создаются на системном уровне, инкапсулируют действия и алгоритмы по вводу/выводу и другим системным операциям, принято называть библиотеками динамической компановки.

dll – dynamic link library

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

Изоляция контекста глобальных данных, уникальных для каждого приложения, характеризуется тем, что загрузчик ОС формирует отдельные элементы данных каждого приложения + отдельный сегмент данных «подключения» к библиотеке.

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

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

Механизм подключения библиотек подразумевает два варианта, отличающиеся только временем их проведения, но не алгоритмом.

1. Библиотека может подключаться непосредственно при загрузке приложения, так что оно начинает работу только после всех библиотек в адресном пространстве (статический вариант).

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

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

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

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

1. Сегменты стека

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

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

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

2. Динамическая память (куча)

Альтернативой стеку для хранения контекста вызовов может являться куча процесса. Каждый процесс имеет возможность часть своего виртуального адресного пространства отдавать для динамического использования. Особенность кучи – возможность выделения блоков разного размера. Куча, как правило, используется для хранения разнородной информации. И так как контексты вызовов разных функций могут отличаться размером, куча является подходящей для их хранения. В то же время в куче удобно сохранять сообщения, т.к. время жизни динамически выделенного блока явно контролируется в программе.

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

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

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

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

3. Устранение отмеченных недостатков может быть произведено при организации динамической памяти в форме пула (pool). Пул использует выделение блоков заданного фиксированного размера, однако операция выделения или освобождения блока имеет сложность 0(1), т.е. не зависит от размера пула.

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

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

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

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