Часть V

5.3. Сервисы системного ядра (Core System Services)

Обзор и обоснование

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

Область действия

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

Эталонная модель

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

Рис. 5.5 Эталонная модель POSIX OSE для сервисов системного ядра

    Так как целью сервисов системного ядра является доступ к внутренним ресурсам платформы, не существует системных сервисов, принадлежащих интерфейсу внешнего окружения - EEI, хотя сервисы ядра и могут использовать компоненты EEI других классов сервисов. Например, в случае прозрачного доступа к файлу через сеть, сервисы ядра могут воспользоваться коммуникационными сервисами EEI. Заметим, что приведенная модель может применяться в случае различных архитектурных реализаций прикладной платформы (в частности, для конфигураций с единственной платформой, многокомпонентными или распределенными платформами), так как архитектурные решения не оказывают влияния на APIs.

Сервисы

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

    Именно этот прием применяется и для разработки номенклатуры сервисов ядра. Первоначально определяется состав групп сервисов ядра. Он включает в себя следующие группы сервисов:

• Process and Thread Mgmt Services (сервисы управления процессами и нитями)
• Environment Services (сервисы окружения)
• Node Internal Comm and Sync Services (сервисы связи и синхронизации для внутренних узлов)
• Generalized I/O Services (общие сервисы ввода/вывода)
• File Storage Services (сервисы файлохранилища)
• Event, Error, Exception Mgmt Services (сервисы управления событиями, управления обработкой ошибок и исключениями)
• Time and Timer Services (сервисы управления временем и таймерами)
• Memory Management Services (сервисы управления памятью)
• Logical Naming Services (сервисы логического наименования)

    Далее выполняется детализация функциональности API для каждой группы сервисов. Рассмотрим этот процесс применительно к первой группе сервисов.

Сервисы управления процессами и нитями

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

    Процессы включают некоторое адресное пространство (address space), единственный поток управления (flow of control) и некоторые ассоциированные с ними системные ресурсы. Поэтому, когда процесс получает назначение на процессор, требуется некоторый накладной расход на переключение регистров процессора на контекст (адресное пространство) этого процесса. Разделение контекстов процессов является важным средством защиты их друг от друга.

    В противоположность процессам нити представляют собой вид потенциально параллельной обработки, которая происходит в контексте одного адресного пространства (процесса). Как правило, системные ресурсы, распределенные процессу, доступны всем его нитям, а переключение управления с одной нити на другую не требует переключения контекстов процессов. Поэтому нити иногда называются легковесными процессами "lighter weight". Их применение эффективно, например, при программировании драйверов устройств, оконных систем, функций ввода/вывода.

    Для управления процессами и нитями в спецификациях POSIX вводится следующий состав системных сервисов:

    - Stop and restart execution of a process or thread (suspend, resume) /останов и повторный запуск процесса или нити (приостановить, возобновить)/;- Modify processor allocation to a process or thread (priority, time slice) /изменить распределение процессора для процесса или нити (приоритет, квантование времени)/;- Modify scheduling of the process or thread based on timer (or other) events /изменить планирование процесса или нити в зависимости от времени и других событий/;- Protect the process or thread from interruption during critical periods /защитить процесс или нить от прерывания в течении критического периода/;- Create a process or thread and make it ready for execution /создать процесс или нить и сделать их готовыми для исполнения/;- Destroy a process or thread and recover its resources /разрушить процесс или нить и восстановить занимаемые ими ресурсы/;- Evaluate a reference to a process /вычислить ссылку на процесс/;- Evaluate a connection to a process or thread, where a connection is a logical communication path between any two concurrency entities /определить путь логической связи между параллельными сущностями/.

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

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

    Сервисы окружения:

    - Attributes specific to entity (process/thread): identification, priority, stack size, scheduling attributes, status, memory allocation) /атрибуты процессов или нитей: идентификация, приоритеты, атрибуты планирования, состояние, распределение памяти/- Processor-specific attributes (node identification, electronic nameplate information) /процессорные атрибуты: идентификация узла, марка производителя/- User-specific attributes (user identification and terminal ID, user interaction profile) /атрибуты пользователя: идентификация пользователя, идентификатор терминала, профиль пользователя/- Environment variables (command-line arguments, menu selections) /переменные окружения: аргументы командной строки, выборы меню/- Current time and date /текущие время и дата/Сервисы связи и синхронизации для внутренних узлов:

    - Create, delete, open, close, read, and write shared memory /создать, вычеркнуть, открыть, закрыть, читать и писать для разделяемой памяти/- Create, delete, read, and write event flags /создать, вычеркнуть, читать и писать для флажков событий/- Create, delete, set, and wait on semaphores /создать, вычеркнуть, установить ждать для семафоров/- Create/send and receive signals /создать, послать, получить для сигналов/- Create, delete, open, close, send to, get from, and control message queues (IPC) /создать, вычеркнуть, открыть, закрыть, послать в, получить из, управлять для очередей сообщений/- Create, delete, send, and receive streams /создать, вычеркнуть, послать, получить для потоков ввода/вывода/

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

    В самих стандартах спецификация API, как правило, задается в виде языкового связывания, т.е., например, для языка С - посредством синтаксиса вызовов функций интерфейса на языке С, с помощью которых осуществляется доступ к сервисам ядра.

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

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

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

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

    В заключение кратко охарактеризуем современное состояние стандартов POSIX.