Компьютерно-реализуемый способ взаимодействия между компонентами и задачами операционной системы через интерфейсную шину
COMPUTER-IMPLEMENTED METHOD OF INTERACTION BETWEEN COMPONENTS AND TASKS OF OPERATING SYSTEM THROUGH INTERFACE BUS

ОБЛАСТЬ ТЕХНИКИ
Настоящее техническое решение относится к области вычислительной техники, в частности к способу взаимодействия между компонентами и задачами операционной системы через интерфейсную шину.
УРОВЕНЬ ТЕХНИКИ
В настоящее время существует ряд решений, описывающих интерфейсные шины.
Из патента US5337413A (TANDEM COMPUTERS INC, опубл. 09.08.1994) подключение удаленных компонентов к главному процессору посредством стандартной интерфейсной шины, имеющей ограниченное количество адресных портов. В патенте описывается хост-адаптер, включающий стандартный компонент повторителя шины, и компонент мониторинга среды. Компонент мониторинга среды имеет стандартный интерфейс шины и по выбору связан со стандартной интерфейсной шиной и, следовательно, с хост-процессором. Приемопередатчик интерфейса хоста соединен посредством стандартной шины с хост-процессором, а также по выбору соединен с приемопередатчиком интерфейса привода посредством стандартной шины. Приемопередатчик интерфейса привода соединен по стандартной шине с одним или несколькими запоминающими устройствами. Хост-адаптер может переключаться по выбору между двумя режимами так, что-либо приемопередатчик интерфейса привода подключается через приемопередатчик интерфейса хоста к хост-процессору, либо компонент мониторинга среды соединяется с хост-процессором.
Из уровня техники известно решение (EP1690186B1, HONEYWELL INT INC, опубл. 23.07.2008), которое описывает способ и устройство, осуществляющие предотвращение отключения шины при подключении к ней неисправных периферийных устройств (COTS) или неисправных входов/выходов. Устройство имеет изоляторы, соединенные с шиной и входами/выходами. Контроллер подключен между интерфейсами, процессором и памятью, и работает так, что ввод/вывод передачи данных на шину осуществляется только с разрешения самой шины. Изоляционная память хранит раздельные сообщения ввода/вывода и шины. Сообщения ввода/вывода проверяются перед отправкой на шину. В результате этой проверки происходит предотвращение отключения шины неисправными вводом/выводом или периферийным устройством.
Известно также решение, которое описывает интерфейсное подключение устройств в многопроцессорной компьютерной системе. Такое решение раскрыто в патенте EP0534662B1 (SUN MICROSYSTEMS INC, опубл. 10.12.1997).
Однако, известные из уровня техники решения, описывающие взаимодействие между собой устройств с помощью интерфейсной шины в архитектуре операционной системы (ОС), имеют ограниченную функциональность, в частности ни в одном из этих решений не предусмотрена возможность одновременной работы компонентов разных поколений операционной системы. Где под поколением понимается версия операционной системы в процессе развития ОС для поддержки требований аппаратной части и состояний развития науки и техники на момент выпуска данной версии ОС.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Данное техническое решение направлено на устранение недостатков, присущих существующим решениям из известного уровня техники.
Технической проблемой, на решение которой направлено заявленное техническое решение, является создание нового способа взаимодействия между компонентами и задачами операционной системы через интерфейсную шину, которое охарактеризовано в независимом пункте формулы. Дополнительные варианты реализации настоящего изобретения представлены в зависимых пунктах изобретения.
Техническим результатом является расширение функциональных возможностей интерфейсной шины за счет возможности осуществления работы компонентов разных поколений.
Данная возможность обеспечивает работоспособность прикладных приложений, разработанных под разные поколения операционной системы и оборудование между собой, а также взаимодействие системных компонентов разных поколений между собой, без необходимости их переписывания заново.
В предпочтительном варианте реализации заявлен компьютерно-реализуемый способ взаимодействия между компонентами и задачами операционной системы (ОС) через интерфейсную шину, выполняемый с помощью вычислительного устройства и содержащий этапы, на которых:
- загружают компоненты в память и автоматически регистрируют их в интерфейсной шине, при этом:
• в динамическом реестре компонентов интерфейсной шины сохраняется запись о компоненте, и информация к какому поколению он относится в виде идентификатора UGUID (Unlimited Globally Unique Identifier) и указателя на фабрику компонентов самого компонента;
• создается экземпляр системного интерфейса, соответствующий поколению данного компонента, для доступа к интерфейсной шине и зарегистрированным на ней компонентам, адрес указателя на системный интерфейс передается загруженному компоненту;
- осуществляют взаимодействие между компонентом и задачей на основе указателя на системный интерфейс;
- деактивируют соответствующий компонент на основе загруженной задачи;
применяют механизм маршалинга для взаимодействия между компонентами и задачами, находящимися в разных адресных пространствах.
В частном варианте сохраняют в пуле объектов экземпляра системного интерфейса созданные экземпляры интерфейса подключаемых задач и компонентов.
В другом частном варианте интерфейсная шина выполняет роль динамического реестра для поиска компонентов, загруженных в оперативную память.
В другом частном варианте интерфейсная шина нового поколения включает или агрегирует интерфейсную шину раннего поколения.
В другом частном варианте интерфейсная шина выполнена по модульному принципу с возможностью расширяться за счет других компонентов ОС.
ОПИСАНИЕ ЧЕРТЕЖЕЙ
Реализация изобретения будет описана в дальнейшем в соответствии с прилагаемыми чертежами, которые представлены для пояснения сути изобретения и никоим образом не ограничивают область изобретения. К заявке прилагаются следующие чертежи:
Фиг. 1 иллюстрирует интерфейсную шину;
Фиг. 2 иллюстрирует пул объектов;
Фиг. 3 иллюстрирует алгоритм работы интерфейсной шины;
Фиг. 4 иллюстрирует вариант межпроцессного взаимодействия;
Фиг. 5 иллюстрирует вариант межпроцессного взаимодействия.
ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
В приведенном ниже подробном описании реализации изобретения приведены многочисленные детали реализации, призванные обеспечить отчетливое понимание настоящего изобретения. В виду того, что специалистам в области проектирования операционных и компьютерных систем знакомы общеупотребительные термины, компоненты и процедуры, то данные методы, названия и компоненты не были описаны подробно, чтобы не затруднять понимание особенностей настоящего изобретения и отличительные возможности его использования.
Кроме того, из приведенного изложения будет ясно, что изобретение не ограничивается приведенной реализацией. Многочисленные возможные модификации, изменения, вариации и замены, сохраняющие суть и форму настоящего изобретения, будут очевидными для квалифицированных в предметной области специалистов.
Настоящее изобретение направлено на создание компьютерно-реализуемого способа взаимодействия между компонентами и задачами операционной системы через интерфейсную шину.
В заявленном решении основой архитектуры ОС является использование интерфейсной шины для передачи данных между компонентами.
Так как все взаимодействие данной архитектуры ОС построено на интерфейсах, то данными шины, являются только указатели на интерфейсы того или иного компонента, других типов данных шина не использует и не поддерживает, поэтому данная шина является интерфейсной.
При этом в заявленном решении нет необходимости формировать буфер обмена данными, достаточно передать всего один указатель на интерфейс. Исключением является ситуация, когда компоненты находятся в разных адресных пространствах, в этом случае используется механизм Marshalling - процесс преобразования данных того или иного интерфейса в корректный формат для передачи.
Также для эффективного взаимодействия интерфейсная шина выполняет роль динамического реестра для поиска компонентов, загруженных в оперативную память. Для поиска и загрузки других компонентов по запросу интерфейсная шина использует вспомогательные компоненты, такие как файловый менеджер для компонентов, расположенных на файловой системе, или сетевой менеджер для загрузки компонентов с удаленных ресурсов.
В дополнении при наличии вспомогательного компонента с функциями удалённого вызова процедур (Remote Procedure Call, RPC), в реестре шины можно зарегистрировать компоненты, расположенные на удаленных вычислительных машинах, используя ресурсы последних.
Еще одна немаловажная задача, которую решает заявленная интерфейсная шина, это связь между компонентами разных поколений. Используя технологию Адаптированной Модели Компонентных Объектов (аналог технологии COM от Microsoft) повторной применяемости компонентов, как пример, интерфейсная шина второго поколения для 32 разрядной архитектуры процессоров включает в себя интерфейсную шину первого поколения для 16 разрядной архитектуры процессора. Так как внешний компонент контролирует интерфейсы внутреннего компонента, то для корректной и прозрачной работы используется тот же механизм маршалинга.
На Фиг. 1 представлен компьютерно-реализуемый способ (100) взаимодействия между компонентами и задачами операционной системы через интерфейсную шину, выполняемый с помощью вычислительного устройства. Такими компоненты могут быть: менеджер памяти, менеджер устройств, файловый менеджер и т.п.
На этапе (101) загружают компоненты в память и автоматически регистрируют их в интерфейсной шине. При этом на этапе (102) в динамическом реестре компонентов интерфейсной шины сохраняется запись о компоненте и к какому поколению он относится в виде идентификатора UGUID (Unlimited Globally Unique Identifier) и указателя на фабрику компонентов самого компонента.
Идентификатор состоит из трех частей:
- преамбулы (определяет размер отводимый под значение длины данных);
- длины данных;
- непосредственно данные (уникальный идентификатор) генерируемые согласно стандарту, RFC 4122.
Так как, согласно стандарту, длина уникального идентификатора равна 128 бит, то для формата неограниченного уникального идентификатора с размером, к примеру, 64 бита, старшая часть обрезается.
Второй пример для формата неограниченного уникального идентификатора с размером 256 бит, просто генерируется два 128 битных идентификатора согласно стандарту, RFC 4122 и объединяются в 256 бит.
Третий пример, показывает отличие UUID = {96EBAA04-7B4E-4BDE-914D-8C3C57F48F2F}, сгенерированного согласно стандарту, RFC 4122, применяемый в COM технологии компании Майкрософт:
static const GUID IID_IX = { 0x96ebaa04, 0x7b4e, 0x4bde, { 0x91, 0x4d, 0x8c, 0x3c, 0x57, 0xf4, 0x8f, 0x2f } };
и UGUID, применяемый в Адаптированной Объектной Модели компонентов:
static const UGUID IID_IX = { 0x01, 0x10, 0x96ebaa04, 0x7b4e, 0x4bde, { 0x91, 0x4d, 0x8c, 0x3c, 0x57, 0xf4, 0x8f, 0x2f } };
где первый байт 0x01 - преамбула, второй байт 0x10 - длина данных, остальные 16 (0x10) байт непосредственно уникальный идентификатор.
Далее на этапе (103) создается экземпляр на соответствующий поколению компонента системный интерфейс для доступа к интерфейсной шине и зарегистрированным на ней компонентам, адрес указателя на системный интерфейс передается загруженному компоненту (104).
На этапе (105) осуществляют взаимодействие между компонентом и задачей на основе указателя на системный интерфейс.
На этапе (106) деактивируют соответствующий компонент на основе загруженной задачи.
Применяют механизм маршалинга для взаимодействия между компонентами с разной разрядностью адресации и задачами, находящимися в разных адресных пространствах (на этапе 107).
Ниже приведен пример в каких случаях применяется механизм маршалинга:
- при разных способах адресации и разрядности, т.е. зависит от того, в каком режиме работает центральный процессор;
- при разных способах адресации и организации памяти, здесь идет речь о другом адресном пространстве, к примеру страничная память (способ организации виртуальной памяти), когда компоненты изолированы друг от друга.
На фиг. 2 представлена интерфейсная шина, отражающая взаимодействие между компонентами и задачами. Интерфейсная шина является связующим звеном между компонентами и задачами.
Интерфейсная шина содержит в своем реестре информацию только о компонентах, расположенных в памяти. Объем реестра для регистрации компонентов имеет ограниченный размер. Для расширения объема реестра интерфейсной шины выполняется загрузка менеджера памяти загрузчиком при загрузке микроядра и регистрации в реестре интерфейсной шины. Компоненты, расположенные на файловой системе, загружаются через файловый менеджер. В случае использования компонентов, расположенных на файловой системе, загрузчик должен загрузить файловый менеджер в память системы и зарегистрировать его в реестре интерфейсной шины.
При загрузке компонента в память и регистрации его в интерфейсной шине, выполняются две операции:
- в динамическом реестре компонента интерфейсной шины сохраняется запись о компоненте и к какому поколению он относится в виде идентификатора UGUID (Unlimited Globally Unique Identifier) и указателя на фабрику компонентов самого компонента
- создается (захватывается) свободный экземпляр на соответствующий поколению компонента системный интерфейс, представленный на Фиг. 3 согласно алгоритму, представленному на Фиг. 4 для доступа к интерфейсной шине и зарегистрированным на ней компонентам, адрес указателя на системный интерфейс передается загруженному компоненту.
Таким образом, загруженный компонент может запрашивать интерфейсы других компонентов.
При загрузке в память задачи (конкретного прикладного приложения) в интерфейсной шине создается (захватывается) новый экземпляр системного интерфейса, представленный на Фиг. 3. Согласно алгоритму, представленному на Фиг. 4 для доступа к интерфейсной шине и зарегистрированным на ней компонентам, адрес указателя на системный интерфейс передается задаче. Операции регистрации/разрегистрации компонентов и создания(захвата)/освобождение экземпляров на системный интерфейс должны быть атомарными, что регулируется требованиями спецификацией к интерфейсной шине. Системный интерфейс условно можно обозначить как точку подключения к интерфейсной шине.
Экземпляры системных интерфейсов подключаемых задач и экземпляры системных интерфейсов компонентов, могут опционально хранятся в пуле объектов экземпляров Фиг. 3, не требуя процессорного времени на создание и уничтожение объектов (интерфейсов), за исключением случаев, когда в пуле нет свободных объектов и программно разрешено расширение пула.
Важно подчеркнуть, что интерфейсная шина не имеет своей собственной задачи (процесса) для создания(захвата)/освобождения экземпляров. Все эти операции выполняются за счет процессорного времени самих планируемых задач.
На фиг. 5 и фиг. 6 показаны варианты межпроцессного взаимодействия. На диаграммах последовательностей показано как создаются и освобождаются экземпляры.
Алгоритм получения указателя на системный интерфейс представлен на Фиг. 4.
Для создания новой задачи, требуется указатель на системный интерфейс, для его получения, инициирующая задача запрашивает указатель на экземпляр системного интерфейса у интерфейсной шины. Получив свободный экземпляр, инициирующая задача увеличивает счетчик ссылок на объект. При передаче управления новой задаче, новая задача в свою очередь также увеличивает счетчик ссылок на объект. После успешного создания новой задачи, инициирующая задача в зависимости от требуемых решений может уменьшить счетчик ссылок на экземпляр системного интерфейса новой задачи.
В случае если инициирующая задача завершается раньше созданной, она обязана уменьшить счетчик ссылок на объект экземпляра системного интерфейса новой задачи, до своего завершения.
Таким образом все взаимодействие между компонентами и задачами сводится к передаче всего одного указателя на системный интерфейс, через который компоненты или задачи могут получить доступ к запрашиваемым интерфейсам.
При этом стоит отметить, что у компонента или задачи есть свой указатель на экземпляр системного интерфейса. Далее в зависимости от типа и требований решаемых задач, в случаях, когда данный подход подвида межпроцессного взаимодействия недостаточен, разработчик не ограничен в методах межпроцессного взаимодействия, т.е. в интерфейсной шине могут быть зарегистрированы компоненты для работы с сокетами, каналами (пример Фиг. 6), сигналами, механизмами синхронизации и т.д.
При запросе через всего один указатель на системный интерфейс разработчик может выбрать любой механизм межпроцессного взаимодействия, реализованный в компонентах. Это во многом отличается от подхода в той же ОС QNX, где межпроцессное взаимодействие организовано через сообщения (пакеты байтов) на уровне микроядра, при этом, если необходимо передать объект, то нужно сначала его сериализовать, а затем десериализовать данные. В заявленном решении ОС же используется компонентный подход конструктора, для обеспечения которого необходимо связующее звено, которое выполняет интерфейсная шина, выполненная по модульному принципу с возможностью расширяться за счет других компонентов ОС, включая, но не ограничиваясь: Менеджером памяти, Файловым менеджером или Сетевым менеджером, для доступа к удаленным компонентам.
На Фиг. 4 изображен алгоритм предоставления системного интерфейса задаче и компоненту с использованием пула объектов Фиг. 3.
Данный алгоритм оптимизирован по времени выполнения, так как не затрачивает процессорного времени на выделение и освобождение памяти под экземпляры системного интерфейса. И также в свою очередь основывается на свойстве компонентов - времени жизни указателей на интерфейсы с подсчетом ссылок.
Подсчет ссылок для системного интерфейса - это все, что необходимо для удержания экземпляра в памяти. Задача и компонент не освобождают указатель на системный интерфейс до тех пор, пока не закончат с ним работу. Основываясь на данном свойстве, подсчете ссылок, алгоритм на Фиг. 4, состоит из следующих этапов:
1) запроса получения указателя на системный интерфейс, для нового экземпляра компонента или задачи;
2) процесса поиска свободного объекта под данные системного интерфейса для новой задачи или экземпляра компонента в пуле объектов:
- если у объекта счетчик подсчета ссылок равен нулю, т.е. объект не занят, выполняется переход к процессу захвата объекта;
- если в пуле объектов нет свободных объектов, нет ни одного объекта со счетчиком ссылок равным нулю, т.е. все объекты заняты, то принимается одно из двух решений:
а) отклонить запрос, если расширение пула не поддерживается, вернуть нулевой указатель с кодом ошибки;
б) выделить блок памяти под новый объект, если расширение пула поддерживается, перейти к процессу захвата объекта;
3) процесс захвата объекта сводится к инициализации данных объекта и увеличению счетчика подсчета ссылок на единицу, т.е. объект становиться занятым;
4) новой задаче или экземпляру компонента возвращается указатель на системный интерфейс, через который новая задача или экземпляр компонента получают доступ к интерфейсной шине и зарегистрированным в ней компонентам.
Пример диаграммы последовательностей отображенный на Фиг. 5, демонстрирует доступ к общему ресурсу, предоставляемого компонентом “Component A”.
Задачи Task 1 и Task 2, запрашивают через интерфейсную шину интерфейс IFoo компонента “Component A”, который предоставляет доступ к общему ресурсу. В свою очередь, интерфейсная шина обращается к реестру зарегистрированных компонентов для поиска в нем запрашиваемого компонента. Осуществив поиск, через интерфейс фабрики компонента “Component A”, интерфейсная шина создает экземпляр объекта данных интерфейса IFoo для задачи. Получив указатели на интерфейс IFoo компонента “Component A” через интерфейсную шину, задачи Task 1 и Task 2 напрямую взаимодействуют с компонентом “Component A” предоставляющим общий ресурс.
В случае, если задачи находятся в разных адресных пространствах, то применяется механизм маршалинга.
Синхронизация доступа к общему ресурсу осуществляется самим компонентом “Component A”. Таким образом задачи Task 1 и Task 2 могут спокойно выполнять операции чтения и записи, не прибегая к дополнительным механизмам синхронизации.
Пример диаграммы последовательностей отображенный на Фиг. 6, демонстрирует обмен данными через именованный канал предоставляемого компонентом “Component A”.
Задачи Task 1 и Task 2, запрашивают через интерфейсную шину интерфейс INamedPipe компонента “Component A”. Процесс получения интерфейса через интерфейсную шину такой же, как и для примера описывающий Фиг. 5.
Через полученный интерфейс INamedPipe, задачи открывают именованный канал Foo (метод межпроцессного взаимодействия), при открытии которого возвращается указатель на интерфейс IPipe, через который осуществляется обмен данными между задачами. По завершению, задачи отключаются от именованного канала, когда ни одна задача не использует именованный канал, он удаляется.
Приведенные примеры, демонстрирует различные способы межпроцессного взаимодействия для обмена данными, которые можно реализовать в виде компонентов, при этом интерфейсная шина является также своего рода подвидом межпроцессного взаимодействия, которой отводится роль предоставления задачам интерфейсов на те или иные компоненты.
Для осуществления связи между разными поколениями компонентов, интерфейсная шина использует системный интерфейс IEcoSystem* (* - номер поколения).
Для каждого поколения микроядра, системный интерфейс имеет свой уникальный идентификатор UGUID, т.е. для каждого поколения микроядр определен или будет определен, в зависимости от уровня технического развития, свой системный интерфейс, к примеру, IEcoSystem1 (1-го поколения), IEcoSystem2 (2-го поколения), IEcoSystem3 (3-го поколения), и т.д., каждый со своим уникальным идентификатором UGUID. Соответственно при запросе задачей или компонентом системного интерфейса под поколение ядра, под которое было разработано решение через интерфейсную шину поколением или несколькими поколениями выше, интерфейсная шина в запросе QueryInterface по UGUID определяет какого поколения системный интерфейс запрашивается.
При этом в зависимости от технических возможностей (архитектуры вычислительной техники) и реализации самой интерфейсной шины, т.е. использования механизмов повторной применяемости, агрегирования или включения, интерфейсная шина передает запрос интерфейсной шине поколением ниже, которая уже в свою очередь определяет, соответствует ли запрашиваемый системный интерфейс поколению микроядра, которому был переадресован запрос. В случае успеха, запрашиваемому компоненту или задаче возвращается соответствующий системный интерфейс. То есть, в заявленном решении интерфейсная шина нового поколения включает или агрегирует интерфейсную шину раннего поколения
Далее задача или компонент взаимодействует с микроядром своего поколения.
Стоит отметить немаловажную особенность, в ряде решений, существует необходимость поддержки программных приложений, разработанных под более ранение поколения ОС (поколения микроядра), но при этом также возникает необходимость совместного использования приложений, разработанных под новое поколение ОС (новое поколение микроядра), т.е. в связке с поддерживаемым решением для раннего поколения ОС. Для агрегируемой интерфейсной шины раннего поколения известен указатель на внешний компонент нового поколения. Используя эту возможность, поддерживаемые решения ранних поколений микроядра, запущенные под управлением микроядра нового поколения, могут запрашивать интерфейсы компонентов, разработанных под новые версии микроядра через интерфейсную шину. Т.е. как компоненты или задачи нового поколения могут использовать компоненты более раннего поколения, так и задачи или компоненты раннего поколения, могут использовать компоненты нового поколения, осуществляя взаимодействие через интерфейсную шину.
В настоящих материалах заявки было представлено предпочтительное раскрытие осуществление заявленного технического решения, которое не должно использоваться как ограничивающее иные, частные воплощения его реализации, которые не выходят за рамки испрашиваемого объема правовой охраны и являются очевидными для специалистов в соответствующей области техники.