Диссертация (1148255), страница 8
Текст из файла (страница 8)
С этой задачей система справилась, однако производительность решения была не очень высока.Для ликвидации этого недостатка были разработаны системы Munin и Midway(см. ниже), которые просят разработчика явно указывать, где допустимы более слабые модели консистентности – таким образом, изначальное ПО в случаеэтих систем приходится не сильно, но всё же модифицировать.1.6.3. MuninMunin [14, 17, 18] создавался в качестве заменя IVY, ставя перед собой теже цели, но стараясь достичь гораздо более высокой производительности.
Организация памяти, как и в IVY, в Munin страничная (с использованием MMU),однако Munin умеет размещать отдельные переменные (точнее структуры данных) на разных страницах, что создает видимость DSM основанной на переменных.С целью повышения производительности вместо последовательной конси44стентности реализует модель консистентности по выходу (см. раздел 1.4.5), икаждый выход из критической секции сопровождает рассылкой по узлам системы дельты изменений соответствующих страниц. Другой способ повышенияпроизводительности – требование к программисту явным образом указывать категорию (одну из четырех предопределенных: read only, migratory, write-shared,conventional) каждой из общих переменных, с целью применения к ним наиболееэффективных алгоритмов.Обладая высокой производительностью, Munin все же оказался сложенв использовании (программисту сложно контролировать у какой переменнойкакая должна быть категория и какие на каждой из переменных из-за этогоограничения), а программирование с ним должно вестись очень аккуратно – кпримеру, доступ к общим переменным разрешен и за пределами критическихсекций, что может приводить к сложноуловимым ошибкам, так как консистентность памяти для такого доступа моделью не обеспечивается.1.6.4.
MidwayMidway [15, 16] появился чуть позже Munin, с той же целью, но иными подходами. В отличие от Munin, имеющего четыре категории общих переменныхи одну модель консистентности, Midway имеет только одну категорию переменных, зато поддерживает три модели консистентности. Для корректной работыпрограммисту необходимо явным образом связать общие переменные с синхронизационными.Недостатком у Midway стало то, что если программист не выполнит требований системы (маркировка переменных как общих, связывание с синхронизационной переменной, доступ к общим переменным только внутри критическихсекций) – на этапе компиляции никаких ошибок выдано не будет, и, как и вслучае с Munin, система будет работать некорректно при крайне затрудненныхвозможностях для обнаружения причин такого поведения.451.6.5.
OrcaOrca [12] представляет собой систему параллельного программирования собщением между узлами через DSM, организованную в виде объектов. Системасостоит из языка программирования (причем не надстройки, а принципиальнонового, хотя и похожего на Modula-2), соответствующего компилятора и системы выполнения. Последняя при этом независима и может использоваться вразличных языках. Объекты в системе похожи на структуры языка Си – в нихесть и члены, и методы, наследование же отсутствует.Система немного похожа на Linda, но только на первый взгляд – объектыOrca гораздо богаче, а алгоритмы сложнее.
Так как объекты Orca могут содержать методы, для возможности их удаленного вызова Orca поддерживает RPCпротокол. В Orca имеется множество интересных алгоритмов. Например, Orcaумеет работать как в сетях, поддерживающих надежные широковещательныесообщения, так и в сетях их не поддерживающих – в последнем случае Orcaреализует этот функционал самостоятельно, поверх функционала сообщенийточка-точка.
Решение же о том, реплицировать ли ту или иную переменнуюили хранить локально, принимает компилятор, основываясь на своих расчетахсоотношения операций записи и чтения соответствующего объекта (учитываяи циклы и наличие широковещательных сообщений в системе).В целом, система очень мощная, но, следовательно, и «тяжелая» – Orcaтребует наличия собственного компилятора (соответственно имеет сложности спортированием на другие платформы) и изучения довольно экзотического посовременным меркам языка программирования.1.6.6. TreadMarksTreadMarks [47, 48] пошел иным путём чем Orca и постарался стать для разработчика максимально понятным за счет API, очень схожего с POSIX Threads.TreadMarks – страничная DSM для Unix систем, написанная на Си и реализую46щая модель ленивой консистентности по выходу (см.
раздел 1.4.6), причём сразутри разновидности этой модели (lazy invalidate, lazy hibrid, eager invalidate). Подобно Munin, TreadMarks обнаруживает обращения к страницам через MMU,и, подобно, Munin рассылает затем дельту изменений. Однако так как модельленивой консистентности не требует выполнять рассылку сразу же, системаожидает запросов с других узлов, зачастую накапливая дельту за нескольковходов-выходов из критической секции.Вероятно благодаря эффективной модели консистентности, качественнойреализации, распространенной платформе (Unix) и удобстве для программиста,система стала очень популярна.1.6.7.
GrappaGrappa [26] - современный DSM фреймворк для программирования кластеров, осуществляющих большие объемы вычислений в памяти и активно работающих с данными. Система исполнения реализована на Си++. Поддерживается оптимизация работы с общими переменными на уровне компилятора.Поддерживает модель последовательной консистентности (в случае отсутствиятак называемых «гонок», англ. data-race, иначе говоря, в отсутствие в ПО фрагментов, зависящих от порядка выполнения кода относительно других узлов).Доступ к общей памяти осуществляется через операции делегирования – данные не обязательно перемещаются на узел, совершающий операцию записи,возможно перемещение самой операции в узел, владеющий данными.
Для повышения эффективности использования каналов передачи данных, агрегируетотдельные сообщения в блоки.В целом перспективно выглядящая система с четкой областью применения.471.6.8. Перечень известных DSM решенийВ таблице 1.1 представлен список существующих DSM решений. Переченьдалеко не полон (в него не вошли Amber, Piranha, Mirage+, Samhita и многие другие). Однако в нём представлены наиболее известные решения1 . Длябольшей наглядности список расположен в хронологическом порядке2 . Решения сопровождаются отсылками на соответствующие работы, а также краткимкомментарием3 .1.6.9.
ЗаключениеМы кратко рассмотрели наиболее известные системы, реализующие концепцию DSM. Первыми решениями стали своеобразные эксперименты – попытки популризации DSM за счет облегчения миграции ПО для мультипроцессоровв распределённую вычислительную среду. Решения постепенно усложнялись впоисках «золотой середины» между удобством использования и производительностью.
Вершиной на этом пути, стало, пожалуй, решение TreadMarks, но и ононе оказалось абсолютным. Развитие концепции сделало виток, и, обладая ужегораздо большим опытом, сегодняшние исследователи (по-прежнему замечая вDSM не полностью раскрытый потенциал) создают решения, как и на заре возникновения этой концепции – узконаправленные, но максимально эффективнорешающие конкретные задачи в конкретном окружении.1На субъективный взгляд автора. К тому же известность наиболее «молодых» решений оценивать покарано.2Следует учесть, что год создания того или иного решения довольно затруднительно определить точнои обычно в его качестве используется год ключевой публикации по теме.3Который, пожалуй, более полезен для автора, так как позволяет быстро вспомнить решение, но ни вкоем случае не является его исчерпывающей характеристикой.48Год Название, публикации Комментарий1985 Linda [24]Языковая надстройка для работы с кортежами1986 IVY [32]Последовательная консистентность, страничная DSM1987 Emerald [22]Объектная DSM1989 Mirage [23]Страничная, как расширение UNIX System V1990 Munin [14, 17, 18]DSM на переменных1991 Midway [15, 16]DSM на переменных1991 Orca [12]Отказоустойчивая, объектная, язык программирования, построена на Amoeba1992 Mermaid [27]Гетерогенная DSM1994 TreadMarks [47, 48]Unix, lazy release, Pthreads, команда Munin1995 Calypso [13]Простая DSM, расширяющая Си++1999 JIAJIA [28]DSM для расширения памяти2006 VODCA [50]Реализует view-based модель консистентности2014 Grappa [26]DSM система для разработки ПО кластеров2015 Tardis [53]DSM протокол, не требующий широковещательных рассылок2017 Naplus [39]Система DSM-коммуникации виртуальных машин (используется JIAJIA)Таблица 1.1 – Известные DSM решения491.7.
ВыводыВ данной главе были рассмотрены предпосылки возникновения концепцииDSM, приведено её описание, история развития, а также проанализированыисследования других авторов.Развитие вычислительных систем привело к широкому распространениюмногопроцессорных архитектур. От архитектур с общей памятью, характерныхдля тесносвязанных систем, наблюдается движение к слабосвязанным или распределённым системам, представляющим собой совокупность независимых вычислительных устройств, объединённых для решения некоторой задачи и формирующих таким образом мультиагентную систему, устройства которой общейпамяти уже не имеют.
Программирование распределённых систем оказывается гораздо более сложной задачей, чем разработка ПО для однопроцессорныхили сильносвязанных систем, что стимулирует поиски альтернативных концепций организации обмена информацией в подобных системах. Концепция DSMпредложила существенно более простой (с точки зрения пользователя) способорганизации коммуникаций в распределённых системах, скрывая сложность реализации данной концепции под относительно простым интерфейсом, работа скоторым напоминает программирование систем с общей памятью.
На прикладном уровне DSM позволяет относительно легко создавать механизмы, традиционно считающиеся непростыми и характерными, ввиду высокой стоимости ихразработки, скорее для «больших» систем (промышленных, военных, медицинских и др.)Ранние реализации концепции DSM обладали низкой производительностью, что стимулировало активные исследования с целью дополнить удобствоиспользования таких систем приемлемыми показателями производительности.Результатом стало создание множества моделей консистентности данных, наиболее поздние из которых позволяют достигать результатов производительности, сравнимых с результатами систем, созданных в рамках классической кон50цепции обмена сообщениями. Однако так как условия функционирования систем и требования к ним со временем изменяются, продолжаются исследования, направленные на выработку новых моделей, более подходящих к тем илииным условиям использования.С целью эффективной реализации той или иной модели консистентностимножеством исследователей создаются алгоритмы, отвечающие разнообразнымтребованиям функционирования конкретных систем и обладающие различными характеристиками производительности и надёжности.