77372

Микроядро RiDE.C

Научная статья

Информатика, кибернетика и программирование

Здесь разумно начать с описания микроядра RiDE. Многие особенности микроядра RiDE.C определяет базовый протокол обмена данными между задачами – RiDE.

Русский

2015-02-02

19.5 KB

0 чел.

Микроядро RiDE.C

М.О. Бахтерев

ИММ УрО РАН, Екатеринбург

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

Распределённые системы (DS) можно строить в рамках традиционных ОС с монолитным ядром (макроядром). Однако при таком подходе усложняется общая структура системы. Ведь, распределённая ОС должна обеспечивать приложениям доступ к ресурсам способом, не зависящим от взаимного расположения приложений и ресурсов на узлах системы. А для достижения этого в архитектурах с макроядром приходится использовать ресурс через транслирующий сервер. Такой сервер при помощи сетевой службы ядра обеспечивает связность с отдалёнными узлами системы: он принимает запросы к ресурсу извне, транслирует (трансляция TQ) их в вызовы службе ядра, поддерживающий ресурс, транслирует результаты вызовов для формирования ответов вовне (TR), и отправляет эти ответы.

Микроядерная же архитектура предполагает организацию управляющих ресурсами служб в виде серверов на уровне пользователя, доступ к которым осуществляется через механизмы межпроцессного взаимодействия (IPC) и стека работающих над IPC протоколов. Традиционно, на этом основании делается вывод о неэффективности подобных архитектур, так как для выполнения запросов приложения требуется переключать контексты задач. Но работа в DS через транслирующий сервер в макроядерной архитектуре тоже требует переключения контекстов, даже тогда, когда ресурс и работающее с ним приложение находятся на одном узле. А необходимость разрабатывать дополнительный протокол и транслировать его (TR, TQ) делает решение с макроядром для распределённой ОС менее эффективным и более громоздким.

Многие особенности микроядра RiDE.C определяет базовый протокол обмена данными между задачами – RiDE.P. Он описывает взаимодействие через области общей памяти, позволяя прозрачно для приложений транслировать акты взаимодействия по сети при помощи агентов, работающих вне микроядра. От микроядра протокол RiDE.P требует поддержки только лишь простого примитива синхронизации – r-ñåìàôîðà (однонаправленный кольцевой, а не со стековым поведением счётчика, point-to-point семафор), операции над которым RiDE.P также  транслирует через агенты (свойство ST).

Опишем некоторые характеристики микроядра RiDE.C в следующем виде.

1. Все выполняемые RiDE.C функции работают по алгоритмам с временной сложность.ю O(1). Даже подсистема работы со временем, алгоритмы для которой в традиционных ОС имеют сложность O(n*n) или O(n*log(n)), n – число используемых программных таймеров.

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

3. Планировщик микроядра RiDE.C разработан для создания хороших условий исполнения как для коротких интерактивных задач (в DS это задачи, управляющие обменами данными), так и для задач с большим временем счета. Оптимизируя работу первых, планировщик отслеживает группы задач, занимающих процессор на долгое время и понижает их уровень интерактивности. Поддерживая выполнение вторых, планировщик программирует таймер, чтобы обеспечивать вычислительным задачам длинные интервалы непрерывной работы. Во многих традиционных ОС оба типа задач прерываются одинаково часто, а пользователь может получить несправедливо много процессорного времени для своего приложения, так как анализируется только индивидуальное поведение составляющих это приложение задач.

4. Лишь два действия с r-ñåìàôîðàìè являются в API RiDE.C системными вызовами. Доступ к остальной функциональности в API определён через протокол над RiDE.P, что вместе со свойством ST позволяет гибко регулировать доступ к микроядру. Стандартными для разрабатываемой ОС могут быть как задачи, работающие с микроядром на отдалённом узле системы, так и задачи, не имеющие контроля над микроядром, работающим на локальном для них процессоре. Такая возможность – важный элемент в предложенной ранее dataflow модели параллельного программирования для неоднородных DS.

5. API микроядра RiDE.C предписывает управлять размещением и настройкой структур данных для микроядра во внешнем менеджере и начинать их использование в самом микроядре после простой регистрации. Такие функции как ?создать задачу? или ?создать r-ñåìàôîð? отсутствуют, так как они требуют работы с памятью на уровне микроядра, приводя к сложностям в системах с памятью виртуальной. Такой подход не снижает общую безопасность системы (менеджер памяти всегда является доверенным компонентом), но позволяет сделать микроядро проще, и, что более важно для больших вычислений, открывает доступ к состояниям задач и связывающих их r-ñåìàôîðîâ с уровня пользователя. В свою очередь, это ведёт к более простой реализации механизмов ортогональной устойчивости: контрольные точки, миграция задач по узлами DS, а также позволяет запускать специализированные под конкретные приложения балансировщики нагрузки на уровне пользователя.

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


 

А также другие работы, которые могут Вас заинтересовать

20434. Программное обеспечение промежуточного уровня 110.5 KB
  Программное обеспечение промежуточного уровня Ни распределенные ни сетевые операционные системы не соответствуют нашему определению распределенных систем данному в разделе 1. На ум приходит вопрос: а возможно ли вообще разработать распределенную систему которая объединяла бы в себе преимущества двух миров масштабируемость и открытость сетевых операционных систем и прозрачность и относительную простоту в использовании распределенных операционных систем Решение было найдено в виде дополнительного уровня программного обеспечения который...
20435. Систе́ма управле́ния ба́зами да́нных 159 KB
  Основные функции СУБД управление данными во внешней памяти на дисках; управление данными в оперативной памяти с использованием дискового кэша; журнализация изменений резервное копирование и восстановление базы данных после сбоев; поддержка языков БД язык определения данных язык манипулирования данными. Обычно современная СУБД содержит следующие компоненты: ядро которое отвечает за управление данными во внешней и оперативной памяти и журнализацию процессор языка базы данных обеспечивающий оптимизацию запросов на извлечение и...
20436. Модель клиент-сервер 39 KB
  Модель клиентсервер До этого момента мы вряд ли сказали чтото о действительной организации распределенных систем более интересуясь тем как в этих системах организованы процессы. Они пришли к выводу о том что мышление в понятиях клиентов запрашивающих службы с серверов помогает понять сложность распределенных систем и управляться с ней. В этом разделе мы кратко рассмотрим модель клиентсервер. Клиенты и серверы В базовой модели клиентсервер все процессы в распределенных системах делятся на две возможно перекрывающиеся группы.
20437. Разделение приложений по уровням 76 KB
  Например сервер распределенной базы данных может постоянно выступать клиентом передающим запросы на различные файловые серверы отвечающие за реализацию таблиц этой базы данных. В этом случае сервер баз данных сам по себе не делает ничего кроме обработки запросов. Однако рассматривая множество приложений типа клиентсервер предназначенных для организации доступа пользователей к базам данных многие рекомендовали разделять их на три уровня: уровень пользовательского интерфейса; уровень обработки; уровень данных. Уровень обработки обычно...
20438. CASE-средства 1.81 MB
  В предыдущей лекции было рассказано о видах диаграмм UML и даны некоторые рекомендации относительно последовательности их построения. Мы уже знаем что нотация UML специально разрабатывалась в расчете на то чтобы диаграммы можно было легко рисовать от руки. В этой лекции мы познакомимся с некоторыми подобными пакетами а именно: IBM Rational Rose; Borland Together; Microsoft Visio; Sparx Systems Enterprise Architect; Gentleware Poseidon; SmartDraw; Dia; Telelogic TAU G2; StarUML; другие программы UML отличное средство моделирования но как...
20439. Rational Rose DataModeler 29.5 KB
  Унифицированный язык объектноориентированного моделирования Unified Modeling Language UML явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств поддерживающих с помощью UML жизненный цикл информационных систем и одновременно UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков. Таким языком оказался UML. Создание UML началось в октябре 1994 г.
20440. CASE-средства 39.5 KB
  Microsoft Visio Visio решение для построения диаграмм от Microsoft. По словам разработчиков Visio помогает преобразовать технические и бизнесконцепции в визуальную форму. Visio имеет некоторые дополнительные возможности но все же повторим по большей мере это только средство для иллюстрирования документов MS Office не дотягивающее до уровня пакетов которые мы описывали ранее. Изобразительные же возможности Visio действительно весьма широки: Используя предопределенные фигуры Visio Professional draganddrop и мастера вы можете...
20441. Эволюция CASE-средств 99.5 KB
  Таким образом CASEтехнологии не могут считаться самостоятельными методологиями они только делают более эффективными пути их применения. CASE ≈ не революция в программо технике: современные CASEсредства являются естественным продолжением эволюции всей отрасли средств разработки ПО. Традиционно выделяют шесть периодов качественно отличающихся применяемой техникой и методами разработки ПО которые характеризуются использованием в качестве инструментальных следующих средств: ассемблеров дампов памяти анализаторов компиляторов...
20442. Варианты архитектуры клиент-сервер 122 KB
  Варианты архитектуры клиентсервер Разделение на три логических уровня обсуждавшееся в предыдущем пункте наводит на мысль о множестве вариантов физического распределения по отдельным компьютерам приложений в модели клиентсервер. Серверы реализующие все остальное то есть уровни обработки и данных. Проблема подобной организации состоит в том что на самом деле система не является распределенной: все происходит на сервере а клиент представляет собой не что иное как простой терминал. Многозвенные архитектуры Один из подходов к организации...