CC BY
28
Математические структуры и моделирование 1999. Вып. 3, с.53-64.
УДК 681.3
СТРУКТУРА СРЕДСТВ КОМПЬЮТЕРНОЙ
ПОДДЕРЖКИ ПРОЦЕССА ПРОТОТИПИРОВАНИЯ ПАРАЛЛЕЛЬНОЙ
СУБД ОМЕГА ДЛЯ МУЛЬТИПРОЦЕССОРНОЙ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ МВС-100/1000
Л.Б. Соколинский
The paper describes a set of computer aided design facilities, which were engaged for prototyping of the parallel DBMS (DataBase Management System), called Omega. This system is designed for MVS-100/1000 massively parallel computer system. These computer-aided facilities consist of a set of universal software tools from third-party vendors, as well as software tools especially designed for this project. The first part includes UNIX/Linux operating system, С++ compilers for MVS-100 and IBM PC, CVS (Concurrent Version System), DOC++ (a documentation system for C/C++), Router - a distributed operating system for MVS-100 and others. The second part corresponds to system software environment and includes topology support system, threads management system, messaging support system, profiler, debugger and disk management system. The paper describes a proper way to integrate these software tools for increasing the productivity of the cooperative development of such complicate software as parallel DBMS for supercomputer. 1
1. Введение
Эффективная разработка больших программных систем сегодня невозможна без использования современных технологий программирования. По определению, данному в работе [1], под технологией программирования понимается
© 1999 Л.Б. Соколинский
E-mail: [email protected] Челябинский государственный университет
1 Работа выполнена при поддержке Российского фонда фундаментальных исследований (грант No. 97-07-90148)
совокупность концептуальных, организационных и программных средств, используемых для создания программного обеспечения. В данной работе рассматривается проблема выбора программных средств, используемых для разработки параллельной СУБД (Системы Управления Базами Данных) Омега [2] для мультипроцессорной вычислительной системы MB С-100/1000 [3].
Инструментарий разработчика может формироваться двумя способами. Первый - это выбрать интегрированную среду разработки (технологический комплекс), поддерживающий все основные этапы технологического цикла разработки программного обеспечения. В свое время было создано большое количество подобных технологических комплексов (см., например, [4]-[7]). Основным недостатком данного подхода является то, что разработчики привязываются к определенному программному обеспечению и, соответственно, ограничиваются рамками его функциональных возможностей. При необходимости использовать функцию, отсутствующую в данном технологическом комплексе, приходится либо дорабатывать данный технологический комплекс, либо переходить на новый комплекс. И то, и другое приводит к существенным накладным расходам, непосредственно не связанным с разрабатываемой программной системой. Использование конкретного технологического комплекса также ограничивает выбор разработчиками аппаратной платформы. Подобный подход оказывается эффективным при разработке прикладного программного обеспечения для решения определенного класса задач, например, при разработке приложений, работающих с базами данных [8].
Второй подход заключается в подборе комплекса независимых инструментальных средств, каждое из которых поддерживает определенный этап технологического цикла. Преимуществом данного подхода является высокая гибкость в формировании технологической среды разработчиков. Разработчики, даже в рамках одного проекта, могут подбирать определенные компоненты технологической среды в соответствии со своими индивидуальными склонностями и навыками. При таком подходе относительно просто заменить технологический компонент, переставший удовлетворять требованиям проекта и разработчиков. Основной проблемой, возникающей при данном подходе, является правильный подбор и интеграция программных продуктов, образующих технологическую среду проекта. Второй подход наиболее часто используется при создании системного программного обеспечения.
В данной работе рассматривается структура программных средств, использованных при создании прототипа параллельной СУБД для МВС-100/1000. Данные программные средства делятся на две части: технологическое окружение и операционное окружение. В разделе 2 дано краткое описание архитектуры МВС-100/1000 и распределенной операционной системы Router. В разделе 3 рассматривается структура технологического окружения СУБД Омега. Особое внимание уделяется вопросам интеграции компонент технологического окружения и описанию технологического цикла разработки. Раздел 4 посвящен описанию структуры операционного окружения СУБД Омега. Рассматриваются основные функции компонент операционного окружения и их реализация. В заключении дается анализ эффективности использованных программ-
ных средств и рассматривается возможность их использования в других разработках.
2. Архитектура МВС-100/1000
По классификации, описанной в [9], суперкомпьютер МВС-100/1000 разработки НИИ «Квант», ИПМ им. М.В. Келдыша РАН, ВНИИТФ и ИММ УрО РАН представляет собой многопроцессорную систему с кластерной архитектурой. В соответствии с таксономией Флинна [10] архитектуру МВС-100/1000 можно отнести к классу MIMD.
МВС-100/1000 состоит из процессорных модулей. Каждый модуль представляет собой двухпроцессорную ЭВМ, состоящую из вычислительного и коммуникационного процессоров. В качестве вычислительного процессора в МВС-100 используется супер скалярный процессор i860 фирмы Intel. Коммуникационный процессор адресует всю оперативную память процессорного модуля, вычислительный процессор - часть этой памяти. Синхронизация коммуникационного и вычислительного процессоров реализована аппаратно. Единственными внешними устройствами процессорного модуля являются скоростные каналы -линки, имеющиеся у коммуникационного процессора. Коммуникационный процессор имеет от четырех (МВС-100) до шести (МВС-1000) линков. С помощью этих линков процессорные модули соединяются друг с другом и с дисковой подсистемой. Система может включать в себя сотни вычислительных модулей и несколько дисковых подсистем, образующих сеть процессорных элементов.
Полученная таким образом сеть связана одним своим линком с управляющей ЭВМ (host-машиной), представляющей собой IBM PC совместимую рабочую станцию.
В качестве операционной системы на МВС-100/1000 используется ОС Router разработки ИПМ им. М.В. Келдыша РАН. В качестве операционной системы host-машины обычно используется ОС UNIX/Linux.
ОС Router представляет собой распределенную операционную систему класса toolset. Она состоит из процессорного сервера, который запускается на каждом коммуникационном процессоре и host-сервера (iserver.exe), запускаемого на host-машине. И процессорный сервер, и host-сервер загружаются всякий раз перед загрузкой задачи пользователя.
ОС Router обеспечивает следующие основные функции:
• загрузку программ пользователя с host-машины на процессорные модули;
• обмен данными между программой и host-машиной в виде некоторого подмножества системных функций ввода/вывода UNIX;
• обмен сообщениями по линкам между программами, запущенными на различных вычислительных процессорах.
Задача пользователя может выполняться только на вычислительных процессорах. Она представляет собой совокупность процессов. На каждом процессорном модуле может выполняться только один пользовательский процесс.
Каждый процесс реализуется в виде программы, которая с точки зрения системы программирования является отдельным загрузочным модулем. В тексте программы в явном виде используются функции ОС Router, реализующие обмен сообщениями с другими программами. Средства написания программ на процессорной сети в целом не предоставляются.
3. Технологическое окружение СУБД Омега
3.1. Структура технологического окружения СУБД Омега
Технологическое окружение СУБД Омега включает в себя редактор GNU Emacs в составе ОС Linux, систему программирования Borland СН—Ь для Windows, систему контроля версий CVS, документатор DOCH—компилятор СН—Ь фирмы Portland Group (PGCC) для i860, отладчик и профилировщик для i860 и ряд утилит ОС Linux и системы программирования СН—Ь для UNIX.
Главной целью при формировании технологического окружения было создание удобной среды, поддерживающей основные этапы технологического цикла разработки системного программного обеспечения для MB С-100 на языке С-|—К Эта среда должна была обеспечить эффективную коллективную работу участников проекта.
Данное технологическое окружение предусматривает два варианта рабочего места разработчика. Первый вариант полностью ориентирован на среду Linux. В качестве редактора используется редактор GNU Emacs, имеющий встроенную поддержку языка С и встроенный интерфейс с системой контроля версий С VS. Фактически Emacs играет роль интегрирующей оболочки, позволяющей редактировать, компилировать и запускать программы на СН—К На рабочих станциях разработчиков устанавливается ОС Windows 95 или Windows NT. Рабочие станции находятся в общей локальной сети с Linux сервером, являющимся host-машиной для МВС-100. Для работы с Linux сервером на рабочих станциях используются Х-терминалы.
Второй вариант в качестве редактора использует среду Borland СН—К Копии исходных текстов находятся на рабочей станции. После редактирования они по FTP пересылаются на Linux сервер. При этом в качестве UNIX терминала используется Telnet, с помощью которого на сервере Linux запускается PGCC компилятор, после чего задача запускается на выполнение на МВС-100. Оба варианта интенсивно используют утилиту Make.
Второй вариант имеет два важных преимущества. Во-первых, он позволяет работать через Internet. В первом варианте этому препятствует недопустимо низкая для X-терминала скорость передачи данных через Internet. Во-вторых, для аппаратно независимых частей программной системы среда Borlan С И—Ь может использоваться также для компилирования, запуска и, что особенно важно, для отладки программ, так как содержит мощный встроенный отладчик, отсутствующий в PGCC.
3.2. Использование системы контроля версий CVS
Система контроля версий CVS [11] является основным инструментом версио-нирования и поддержки коллективной разработки проекта.
Система функционирует в ОС Unix и представляет собой CASE-пакет разработчика (toolkit), который можно использовать на этапе кодирования и сопровождения. В CVS поддерживаются понятия репозитория и рабочей копии проекта. В репозитории хранятся полные копии всех файлов и каталогов проекта. Каждый участник проекта работает со своей индивидуальной рабочей копией проекта.
Создав свою рабочую копию проекта, участник проекта должен затем периодически выполнять ее обновление. Изменения в файлах рабочей копии не будут доступны другим участникам проекта, пока не будет выполнена их синхронизация. Выполняя синхронизацию, CVS заставляет разработчика прокомментировать внесенные изменения. При обновлении и синхронизации рабочей копии проекта CVS осуществляет автоматическое слияние изменений, внесенных другими разработчиками, если эти изменения не затрагивают одни и те же строки файлов. В случае конфликта изменений в рабочей копии файла с содержанием этого файла из репозитория конфликтующие строки помечаются в файле специальными маркерами, и разработчик должен разрешить конфликт «вручную», после чего выполнить синхронизацию изменений.
Разработчик может просмотреть историю изменения заданного файла проекта, сравнить разные версии одного файла, узнать статус файла: нужно ли выполнить его синхронизацию, нуждается ли файл в обновлении и имеются ли конфликты.
Каждая версия файла имеет номер ревизии, который автоматически изменяется при выполнении синхронизации. Номера ревизий могут выглядеть так: 1.1, 1.2, 1.3 или в случае создания ветки проекта 1.2.2.1. и даже 1.3.2.2.4.5. Файлы проекта (или релиз) с различными номерами ревизий можно объединять одним именем. Например, release-1, last_week_release, release-l_patches. Разработчик может получить копию файла или всего проекта по заданному номеру ревизии или имени релиза.
При отладке либо сопровождении предыдущих релизов проекта часто возникает потребность внести в них какие-либо изменения, а затем выполнить слияние этих изменений в текущую разработку. В CVS поддерживаются понятия основного пути (main trunk) и ветки (branch) разработки проекта. Для решения указанной проблемы разработчику необходимо получить копию нужного релиза проекта, создать его ветку, а после внесения необходимых изменений выполнить их слияние и синхронизацию.
Система CVS представляется весьма полезным средством для коллективной разработки сложных программных систем.
3.3. Система документирования DOCH—Ь
Документатор DOCH—Ь [12] позволяет готовить высококачественную документацию по программной системе непосредственно в процессе работы с исходными текстами программ на языке С или С И—К Данный подход позволяет выполнить требование самодокументируемости исходных текстов и при этом избежать дублирования информации в исходных текстах и в документации. Это наиболее эффективный путь обеспечения актуальности документации и ее соответствия исходным текстам.
Основная идея документатора состоит в введении специального вида комментариев следующего формата: * j
Такие комментарии, в отличие от комментариев с одной звездочкой вначале, анализируются документатором и переводятся в формат HTML. При этом документатор использует ряд зарезервированных слов, помещаемых в комментарий, и начинающихся с символа Ниже приведен пример спецификации функции, подготовленной для документатора DOCH—К
/** Создание новой нити. Данная функция порождает новую нить. При этом вычисляется значение ее Т-фактора.Передачи управления новой нити при этом не происходит. Фактически th_fork() создает новую запись в таблице нитей менеджера нитей. Если не указана факторфункция, то в качестве факторфункции берется константа (TH_FACT0R_MAX/2). Если в качестве приоритета указано значение TH_LOWEST_NICE, то данная нить будет выполняться только в том случае, если в данный момент времени в системе отсутствуют готовые к выполнению нити с более высоким приоритетом.
@param proc -указатель на функцию, представляющую тело нити
@param param - указатель на список параметров, или NULL
@param factorfn - указатель на факторфункцию, или NULL
@param type - тип нити:
TH_AND - конъюнктивная
TH_OR - дизъюнктивная
TH_SYS - системная
@param nice - приоритет нити (целое число от -20 до 20).
@returns - положительный tid новой нити, или отрицательное значение, указывающее на ошибку: TH_OVERFLOW - переполнение таблицы нитей, TH_ENOMEM - недостаточно памяти для создания новой нити @see th_proc_t */
extern th_tid_t th_fork(th_proc_ t proc, void* param, th_factorfn_t factorfn, th_type_t type, th_nice_t nice);
Исходные тексты, подготовленные подобным образом, автоматически компилируются документатором в качественную документацию в формате HTML.
Основными преимуществами данного подхода к подготовке документации по проекту являются: постоянная актуальность и адекватность документации, возможность работать с данной документацией на всех аппаратно-программных платформах, имеющих HTML обозреватель (HTML browser), возможность работы с документацией через Internet.
3.4. Отладчик
Среда программирования PGCC для МВС-100 не содержит встроенного отладчика. Поэтому в рамках проекта Омега был разработан простой отладчик, выполняющий трассировку программы и отладочную печать.
Отладчик состоит из функций: Begin_debug() - начать отладочную печать; Print_debug() - вывести значения переменных; End_debug() - закончить отладочную печать.
Отладчик позволяет задавать номера процессоров, для которых следует выводить отладочные сообщения. В них автоматически могут включаться номера процессоров.
Отладчик поддерживает два режима работы: режим выдачи отладочной информации в виде дампа и режим трассировки, обеспечивающий пошаговое выполнение программы.
Разумеется, подобный отладчик не может заменить полноценный символьный, однако его использование, как показывает опыт, позволяет существенно повысить эффективность процесса отладки.
3.5. Профилировщик
Одной из наиболее важных задач, возникающих при проектировании и создании СУБД, является проблема оптимизации запросов. Наибольшие временные затраты при выполнении запроса в параллельных системах управления базами данных для платформ с кластерной архитектурой приходятся на передачу данных между процессорными узлами и обмен с дисками. Поэтому для оценки того или иного плана выполнения запроса к базе данных необходимо знать общий объем данных, вовлекаемых в обмен с дисками и передачу по линкам.
С этой целью в рамках проекта Омега был спроектирован профилировщик, позволяющий решить эту задачу для многопроцессорной среды MB С- 100/1000. Профилировщик имеет следующие основные функции: Create_tag(int tag) - создать тэг;
Begin_profile(int tag) - начать профилирование по указанному тегу; End_profile(int tag) - закончить профилирование по указанному тегу; int Link_read(int tag) - выдает количество операций чтения по линкам; int Link_write(int tag) - выдает количество операций записи по линкам; int Disk_read(int tag) - выдает количество операций чтения с диска; int Disk _write(int tag) - выдает количество операций записи на диск.
Функция Create_tag() создает в таблице профилировщика учетную запись с указанным тегом. Ключевыми атрибутами записи являются тег и идентификатор текущей нити управления. Учетная запись, кроме того, содержит поля, в которых будут суммироваться передачи по линкам (сообщения) и обмены с дисками, инициируемые данной нитью управления.
Функция Е^т_рго:111е() обнуляет счетчики сообщений и обменов и включает режим профилирования для указанного тега. Функция Епс1_ргой1е() выключает режим профилирования для указанного тега. Каждый обмен с диском и каждая передача сообщения, выполняемая некоторой нитью управления, увеличивают соответствующие счетчики всех своих профилировочных записей, для которых включен режим профилирования.
Тэг, по существу, является некоторым идентификатором, позволяющим пользователю суммировать результаты профилирования, полученные при выполнении одного запроса на нескольких процессорах.
4. Операционное окружение СУБД Омега 4.1. Аппаратная архитектура СУБД Омега
Модульный принцип построения MB С дает большие возможности для создания различных аппаратных конфигураций, в первую очередь за счет изменения топологии соединения процессорных модулей высокоскоростными каналами связи - линками. Для системы Омега была разработана оригинальная аппаратная архитектура [2]. В соответствии с этой архитектурой единицей масштабирования системы является так называемый кластер. Кластер имеет сильно связанную структуру и состоит из четырех процессорных модулей и дисковой подсистемы с четырьмя дисковыми накопителями на общей SCSI шине. Каждый процессорный модуль соединен посредством линков с двумя другими процессорными модулями и дисковой подсистемой. Один линк каждого процессорного модуля остается свободным и используется для соединения кластеров между собой. Таким образом, каждый кластер имеет четыре внешних линка.
В минимальной конфигурации система может состоять из двух кластеров. В общем случае система может включать в себя несколько сотен кластеров. Топология межкластерных соединений не фиксируется. Предполагается, что она имеет относительно низкую степень связности. В простейшем случае кластеры образуют двусвязную «линейку», на концах которой стоят две host-машины. Подобная архитектура уже образует систему, отказоустойчивую по всем аппаратным компонентам.
Предложенная архитектура занимает промежуточное место между архитектурой без совместного использования ресурсов и архитектурой с разделением дисков.
4.2. Структура операционного окружения СУБД Омега
Операционное окружение содержит подсистемы, обеспечивающие межкластерный и внутрикластерный обмен сообщениями, операции обмена с дисками и поддержку легковесных процессов. Операционное окружение является аппаратно-зависимой частью системы и абстрагирует ядро СУБД от особенностей аппаратной платформы. Операционное окружение является основой мобильности СУБД Омега при переходе на другие модификации аппаратных платформ.
В качестве нижнего уровня операционного окружения фигурирует модуль поддержки топологии. Модуль топологии инкапсулирует аппаратные особенности топологии MB С и позволяет рассматривать его как совокупность Омега-кластеров. Адресом процессорного узла, таким образом, является пара: адрес кластера и номер узла в кластере. Реализация модуля топологии является ап-паратно зависимой.
Остальные части операционного окружения рассматриваются в следующих разделах.
4.3. Менеджер легковесных процессов
Менеджер легковесных процессов (менеджер нитей) обеспечивает возможность организации параллельных нитей управления [13] в соответствии с дисциплиной, определенной в модели поставщик - потребитель [14]. Менеджер нитей поддерживает два класса нитей: системные нити и пользовательские нити.
Менеджер нитей поддерживает для нитей систему статических приоритетов, назначаемых пользователем при создании нитей. Реальное управление нитями выполняется на основе динамических приоритетов. Алгоритм вычисления динамических описан в работе [14].
Основу интерфейса менеджера нитей составляют следующие три функции: init() - инициализация менеджера нитей; fork() - создание новой нити; scheduleQ - выполнить диспетчеризацию.
Функция init() осуществляет запуск менеджера нитей и оформляет головной процесс в качестве корневой нити.
Функция fork() порождает новую нить. При этом передачи управления новой нити не происходит. Фактически функция fork создает новую запись в таблице нитей менеджера нитей. Функция возвращает уникальный идентификатор вновь созданной нити.
Функция scheduleQ передает управление менеджеру нитей для дальнейшей диспетчеризации. Менеджер нитей просматривает все нити, находящиеся в оперативной памяти и готовые к выполнению, и выбирает среди них наиболее приоритетную нить. Чем меньше значение динамического приоритета нити, тем выше ее приоритетность. Если имеется несколько нитей с одинаково высокой приоритетностью на выполнение, выбирается та, которая дольше всего ждет процессорный ресурс в состоянии готовности к выполнению. Если же не
удается вообще найти нити, готовые к выполнению, менеджер передает управление корневой нити процесса.
4.4. Система обмена сообщениями
Система обмена сообщениями имеет двухуровневую организацию и состоит из кондуктора и маршрутизатора.
Маршрутизатор обеспечивает передачу сообщений и данных между кластерами. Он обладает полным знанием топологии межкластерных соединений, информацией о работоспособности линий связи (линков) и их текущей загрузке. На основе этой информации маршрутизатор пытается выбрать оптимальный путь передачи сообщения от одного кластера к другому, однако в общем случае маршрут, выбранный маршрутизатором, может и не быть «самым» оптимальным. Маршрутизатор позволяет полностью абстрагировать реализацию СУБД Омега от топологии межкластерных соединений. Если рассматривать маршрутизатор как виртуальное устройство, то архитектура системы в целом принимает звездообразную структуру: в центре звезды расположен маршрутизатор, линки образуют лучи, на концах которых расположены кластеры. Реализация маршрутизатора строится на базе ОС Router разработки ИПМ им. М.В. Келдыша РАН. В перспективе может быть выполнена аппаратно - программная реализация маршрутизатора с использованием специальной элементной базы.
Кондуктор играет роль маршрутизатора внутри кластера. В связи с простой фиксированной топологией кластера кондуктор всегда обеспечивает оптимальный выбор маршрута для передачи сообщений и данных внутри кластера. За основу реализации кондуктора берется ОС Router, оптимизированная для структуры кластера и специфики СУБД.
4.5. Система управления дисками
Система управления дисками (СУД) реализует интерфейс ввода-вывода для организации обменов с дисковой подсистемой. СУД позволяет абстрагироваться от особенностей дисковой подсистемы кластера и рассматривать ее как виртуальное устройство, состоящее из N логических дисков со страничной организацией. Количество дисков должно совпадать с количеством процессорных модулей кластера. За каждым процессорным модулем закрепляется свой диск. Процесс не может обращаться к «чужим» дискам.
Размер страницы является параметром генерации системы Омега. Предлагается установить размер страницы равным 4 Кбайтам.
Основу интерфейса СУД составляют следующие функции: с18_\¥п1е() - записать страницу на диск; сЬз_геа(1() - считать страницу с диска.
5. Заключение
Описанный технологический цикл и соответствующее программное обеспечение могут быть использованы при коллективной разработке больших программных систем различного назначения. Предложенная среда разработки позволяет учитывать индивидуальные склонности членов рабочей группы. Она допускает работу на различных программно - аппаратных платформах, как в составе локальной сети, так и через Internet.
Компоненты операционного окружения СУБД Омега могут быть использованы для разработки широкого спектра программного обеспечения для МВС-100. Основной особенностью операционного окружения является возможность использовать в прикладных программах легковесные процессы, что в свою очередь позволяет добиться более эффективного использования дисковой подсистемы и каналов ввода/вывода.
Литература
1. Сафонов В.О. Языки и методы программирования в системе «Эльбрус». - М.: Наука, 1989. - 392 с.
2. Sokolinsky L., Axenov О., Gutova S. Omega: The Highly Parallel Database System Project // Proceedings of the First East-European Symposium on Advances in Database and Information Systems (ADBIS'97), St.-Petersburg. September 2-5, 1997. Vol. 2. P. 88-90.
3. Голъштейн М.Л. Мультипроцессорная вычислительная система на базе транспьютерной идеологии // Алгоритмы и программные средства параллельных вычислений: Сб. науч. тр. - Екатеринбург: УрО РАН, 1995. - С. 61-68.
4. Вельбицкий И.В. Технология программирования. - Киев: Техшка, 1984. - 250 с.
5. Мельников H.A., Раабе A.C., Тамм Б.Е. Инструментарий машинной поддержки цикла жизни программного обеспечения. Обзор западных средств // Прикладная информатика. - 1988. - Вып. 14. - С. 16-40.
6. Соколинский Л.Б. Программная поддержка ТИП-технологии программирования на МВК «Эльбрус» //I Регион, конф. «Технология программирования, инструментальное и системное программное обеспечение ЭВМ»: Тез. докл. - Пермь: ПЕУ, 1989. - С. 32-33.
7. Фуксман A.A. Технологические аспекты создания программных систем // М.: Статистика, 1979. - С. 184.
8. Позин Б. А. Современные средства программной инженерии для создания открытых прикладных информационных систем // СУБД. - 1995. - N 1. - С. 139144.
9. Pfister G. Sizing Up Parallel Architectures // DataBase Programming & Design OnLine (http://www.dbpd.com/9805feat.html). May 1998.
10. Flynn M.J., Rudd K.W. Parallel architectures // ACM Computing Surveys. March 1996. Vol. 28. N. 1. P. 67-70.
11. Berliner B. CVS II: Parallelizing Software Development //http://www.hu.freebsd.org/hu/doc/psd/28.cvs/paper.html
12. Wunderling R., Zockler M. D0C+ + . A Documentation System for C/C++ and Java. //http: //www.zib.de/Visual/software/doc++
13. Кузнецов С.Д. Операционные системы для управления базами данных // СУБД. - 1996. - N. 3. - С. 95-102.
14. Соколинскии Л.Б. Организация легковесных процессов в параллельной СУБД Омега для МВС-100 // Всерос. науч. конф. «Фундаментальные и прикладные аспекты разработки больших распределенных программных комплексов»: Тез. докл. - М: МГУ, 1998.
