Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Распределенная операционная система является система программного обеспечения по набору независимых, подключенных к сети , передач , и физически отдельных вычислительных узлов. Они обрабатывают задания, которые обслуживаются несколькими процессорами. [1] Каждый отдельный узел содержит определенное программное подмножество глобальной совокупной операционной системы. Каждое подмножество состоит из двух отдельных поставщиков услуг. [2] Первое - это вездесущее минимальное ядро или микроядро , которое напрямую управляет оборудованием этого узла. Во-вторых, это высокоуровневый набор компонентов управления системой.которые координируют индивидуальные и совместные действия узла. Эти компоненты абстрагируют функции микроядра и поддерживают пользовательские приложения. [3]

Микроядро и набор компонентов управления работают вместе. Они поддерживают цель системы по интеграции нескольких ресурсов и функций обработки в эффективную и стабильную систему. [4] Эта бесшовная интеграция отдельных узлов в глобальную систему называется прозрачностью или единым образом системы ; описание представленной пользователям иллюзии внешнего вида глобальной системы как единого вычислительного объекта.

Описание [ править ]

Структура монолитного ядра, микроядра и гибридных операционных систем на базе ядра

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

Отделение минимальной функциональности системного уровня от дополнительных модульных сервисов пользовательского уровня обеспечивает « разделение механизма и политики ». Механизм и политику можно просто интерпретировать как «что что-то делается» и «как что-то делается» соответственно. Такое разделение увеличивает гибкость и масштабируемость.

Обзор [ править ]

Ядро [ править ]

В каждой локали (обычно на узле) ядро ​​предоставляет минимально полный набор утилит уровня узла, необходимых для работы с оборудованием и ресурсами, лежащими в основе узла. Эти механизмы включают в себя распределение, управление и размещение ресурсов узла, процессов, связи и функций поддержки управления вводом / выводом . [5] Внутри ядра подсистема связи имеет первостепенное значение для распределенной ОС. [3]

В распределенной ОС ядро ​​часто поддерживает минимальный набор функций, включая низкоуровневое управление адресным пространством, управление потоками и межпроцессное взаимодействие (IPC). Ядро такой конструкции называется микроядром . [6] [7] Его модульный характер повышает надежность и безопасность, важные функции распределенной ОС. [8] Обычно ядро ​​идентично реплицируется на все узлы в системе, и поэтому узлы в системе используют одинаковое оборудование. [9]Комбинация минимального дизайна и повсеместного покрытия узлов увеличивает расширяемость глобальной системы и возможность динамически вводить новые узлы или службы. [10]

Обзор компонентов управления системой

Управление системой [ править ]

Компоненты управления системой - это программные процессы, которые определяют политики узла . Эти компоненты являются частью ОС вне ядра. Эти компоненты обеспечивают связь более высокого уровня, управление процессами и ресурсами, надежность, производительность и безопасность. Компоненты соответствуют функциям одноэлементной системы, добавляя прозрачности, необходимой в распределенной среде. [3]

Распределенный характер ОС требует дополнительных сервисов для поддержки ответственности узла перед глобальной системой. Кроме того, компоненты управления системой принимают на себя «защитные» обязанности по обеспечению надежности, доступности и устойчивости. Эти обязанности могут противоречить друг другу. Последовательный подход, сбалансированная перспектива и глубокое понимание всей системы могут помочь в выявлении убывающей отдачи . Разделение политики и механизма смягчает такие конфликты. [10]

Совместная работа как операционная система [ править ]

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

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

Цена сложности [ править ]

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

Эти соображения при проектировании и разработке критичны и неумолимы. Например, на исключительно раннем этапе требуется глубокое понимание общих деталей архитектуры и дизайна распределенной операционной системы. [1] При разработке распределенной операционной системы необходимо учитывать множество конструктивных соображений. Каждое из этих конструктивных соображений потенциально может в значительной степени повлиять на многие другие. Это приводит к огромным усилиям по сбалансированному подходу с точки зрения индивидуальных дизайнерских соображений и многих их изменений. В качестве помощи в этих усилиях большинство полагается на документально подтвержденный опыт и исследования в области распределенных вычислительных мощностей.

История [ править ]

Серьезные исследования и эксперименты начались в 1970-х годах и продолжались до 1990-х, а пик интереса пришелся на конец 1980-х. В этот период был введен ряд распределенных операционных систем; однако очень немногие из этих реализаций достигли даже скромного коммерческого успеха.

Фундаментальные и новаторские реализации примитивных концепций компонентов распределенной операционной системы относятся к началу 1950-х годов. [12] [13] [14] Некоторые из этих отдельных шагов не были сосредоточены непосредственно на распределенных вычислениях, и в то время многие, возможно, не осознавали их важное влияние. Эти новаторские усилия заложили важную основу и вдохновили на продолжение исследований в областях, связанных с распределенными вычислениями. [15] [16] [17] [18] [19] [20]

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

Ускоряющееся распространение исследований многопроцессорных и многоядерных процессорных систем привело к возрождению концепции распределенных ОС.

1950-е [ править ]

DYSEAC [ править ]

Одной из первых попыток был DYSEAC , синхронный компьютер общего назначения . В одной из самых ранних публикаций Ассоциации вычислительной техники в апреле 1954 года исследователь из Национального бюро стандартов  - ныне Национального института стандартов и технологий ( NIST ) - представил подробную спецификацию DYSEAC. Во введении основное внимание уделялось требованиям предполагаемых приложений, включая гибкую связь, но также упоминались другие компьютеры:

Наконец, внешние устройства могут даже включать другие полномасштабные компьютеры, использующие тот же цифровой язык, что и DYSEAC. Например, SEAC или другие подобные ему компьютеры могут быть подключены к DYSEAC и с помощью скоординированных программ могут работать вместе во взаимном сотрудничестве над общей задачей ... Следовательно, [,] компьютер может использоваться для координации различных деятельность всех внешних устройств в эффективную ансамблевую работу.

-  АЛАН Л. ЛЕЙНЕР, Технические характеристики системы DYSEAC

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

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

-  АЛАН Л. ЛЕЙНЕР, Технические характеристики системы DYSEAC

Это один из самых ранних примеров компьютера с распределенным управлением. В отчетах Министерства армии [21] он подтвержден как надежный и выдержавший все приемочные испытания в апреле 1954 года. Он был завершен и доставлен вовремя в мае 1954 года. Это был « портативный компьютер », размещенный в тягаче с прицепом. , с 2 сопровождающими машинами и холодопроизводительностью 6 тонн .

Lincoln TX-2 [ править ]

Описанный как экспериментальная система ввода-вывода, Lincoln TX-2 делает упор на гибкие, одновременно работающие устройства ввода-вывода, т. Е. Мультипрограммирование . Конструкция TX-2 была модульной, поддерживая высокую степень модификации и расширения. [13]

Система использовала технику многопоследовательной программы. Этот метод позволял нескольким программным счетчикам связываться с одной из 32 возможных последовательностей программного кода. Эти явно приоритетные последовательности могут чередоваться и выполняться одновременно, влияя не только на выполняемые вычисления, но также на поток управления последовательностями и переключение устройств. Много дискуссий было связано с секвенированием устройств.

Подобно DYSEAC, отдельно запрограммированные устройства TX-2 могут работать одновременно, увеличивая пропускную способность . Полная мощность центрального блока была доступна любому устройству. TX-2 был еще одним примером системы, демонстрирующей распределенное управление, ее центральный блок не имел специального управления.

Взаимодействующие клетки [ править ]

Одной из первых попыток абстрагирования доступа к памяти была Intercommunicating Cells, где ячейка состояла из набора элементов памяти . Элемент памяти был в основном двоичным электронным триггером или реле . Внутри ячейки было два типа элементов: символ и ячейка . Каждая структура ячеек хранит данные в виде строки символов, состоящей из имени и набора параметров . Информация связана через клеточные ассоциации. [14]

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

У сотовой памяти будет много преимуществ:
Основная часть логики системы распределена в ассоциациях информации, хранящейся в ячейках,
Этот поток информационных ассоциаций в некоторой степени управляется актом хранения и извлечения,
Время, необходимое для хранения и извлечения, в основном постоянно и совершенно не связано с размером и коэффициентом заполнения памяти.
Ячейки логически неразличимы, что делает их гибкими в использовании и относительно простыми в увеличении.

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

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

-  Чунг-Йол (CY) Ли, Взаимодействующие ячейки, основа для распределенного логического компьютера

Фундаментальная работа [ править ]

Когерентная абстракция памяти [ править ]

 Алгоритмы масштабируемой синхронизации на мультипроцессорах с общей памятью [22]

Абстракция файловой системы [ править ]

 Измерения распределенной файловой системы [23]
  Согласованность памяти в совместно используемых системах виртуальной памяти [24]

Абстракция транзакции [ править ]

 
 Саги о сделках [25]

 Транзакционная память Транзакции с
  составной памятью [26]
  Транзакционная память: архитектурная поддержка структур данных без блокировок [27]
  Программная транзакционная память для структур данных динамического размера [28]
  Программная транзакционная память [29]

Абстракция постоянства [ править ]

 OceanStore: архитектура для постоянного хранилища в глобальном масштабе [30]

Абстракция координатора [ править ]

 Взвешенное голосование за реплицированные данные [31]
  Консенсус при наличии частичной синхронизации [32]

Абстракция надежности [ править ]

 Проверка работоспособности
  Проблема византийских генералов [33]
  Отказоустойчивые процессоры: подход к разработке отказоустойчивых вычислительных систем [34]

 Восстанавливаемость Распределенные моментальные снимки: определение глобального состояния распределенных систем [35] Оптимистичное восстановление в распределенных системах [36]
 
 

Распределенные вычислительные модели [ править ]

Три основных дистрибутива [ править ]

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

Организация [ править ]

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

Подключение [ править ]

Централизованные системы подключают составляющие напрямую к центральному главному объекту в режиме концентратора и луча. Децентрализованная система (также известная как сетевая система ) включает прямые и косвенные пути между составными элементами и центральным объектом. Обычно это конфигурируется как иерархия с одним кратчайшим путем между любыми двумя элементами. Наконец, распределенная операционная система не требует шаблонов; между любыми двумя элементами возможны прямые и косвенные связи. Рассмотрим феномен « струнного искусства » 1970-х годов или рисунок спирографа как полностью связанную систему , а паутину или систему межгосударственных автомагистралей между городами США как примерычастично подключенная система .

Контроль [ править ]

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

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

Соображения по дизайну [ править ]

Прозрачность [ править ]

Прозрачность или образ единой системы относится к способности приложения обрабатывать систему, в которой оно работает, независимо от того, является ли оно распределенным, без учета аппаратного обеспечения или других деталей реализации. Многие области системы могут выиграть от прозрачности, включая доступ, местоположение, производительность, именование и миграцию. Учет прозрачности напрямую влияет на принятие решений во всех аспектах проектирования распределенной операционной системы. Прозрачность может налагать определенные требования и / или ограничения на другие конструктивные особенности.

Системы могут необязательно нарушать прозрачность в различной степени, чтобы соответствовать требованиям конкретного приложения. Например, распределенная операционная система может представлять жесткий диск на одном компьютере как «C:», а диск на другом компьютере как «G:». От пользователя не требуется никаких знаний о драйверах устройств или местонахождении диска; оба устройства работают одинаково с точки зрения приложения. Менее прозрачный интерфейс может потребовать, чтобы приложение знало, на каком компьютере находится диск. Области прозрачности:

  • Прозрачность местоположения. Прозрачность местоположения включает два различных аспекта: прозрачность, прозрачность наименования и мобильность пользователей. Прозрачность именования требует, чтобы ничто в физических или логических ссылках на какой-либо системный объект не отображало какое-либо указание на местоположение объекта или его локальную или удаленную связь с пользователем или приложением. Мобильность пользователей требует согласованной ссылки на системные объекты, независимо от того, из какого местоположения в системе исходит ссылка. [8] : 20
  • Прозрачность доступа - локальные и удаленные системные объекты должны оставаться неразличимыми при просмотре через пользовательский интерфейс. Распределенная операционная система поддерживает это восприятие посредством раскрытия единого механизма доступа для системного объекта, независимо от того, является ли этот объект локальным или удаленным для пользователя. Прозрачность диктует, что любые различия в методах доступа к любому конкретному объекту системы - локальному или удаленному - должны быть как невидимыми, так и необнаруживаемыми пользователем. [3] : 84
  • Прозрачность миграции - ресурсы и действия переносятся из одного элемента в другой, управляемый исключительно системой и без ведома пользователя / приложения или действий. [9] : 16
  • Прозрачность репликации - процесс или факт дублирования ресурса в другом элементе происходит под контролем системы и без ведома или вмешательства пользователя / приложения. [9] : 16
  • Прозрачность параллелизма - пользователи / приложения не знают и не зависят от присутствия / действий других пользователей. [9] : 16
  • Прозрачность отказов - система отвечает за обнаружение и устранение сбоев системы. Никаких знаний / действий пользователя не требуется, кроме ожидания, пока система решит проблему. [10] : 30
  • Прозрачность производительности - система отвечает за обнаружение и устранение локальных или глобальных недостатков производительности. Обратите внимание, что системные политики могут предпочесть одних пользователей / классы / задачи другим. Никаких пользовательских знаний или взаимодействия. впутан. [8] : 23
  • Прозрачность размера / масштаба - система отвечает за управление своим географическим охватом, количеством узлов, уровнем возможностей узла без каких-либо необходимых знаний или взаимодействия с пользователем. [8] : 23
  • Прозрачность редакции - система отвечает за обновления, изменения и изменения в инфраструктуре системы без ведома пользователя или действий. [10] : 30
  • Прозрачность управления - система отвечает за предоставление всей системной информации, констант, свойств, настроек конфигурации и т. Д. В единообразном виде, коннотации и обозначении для всех пользователей и приложений. [3] : 84
  • Прозрачность данных - система отвечает за предоставление данных приложениям без ведома пользователя и без каких-либо действий в отношении того, где система их хранит. [3] : 85
  • Прозрачность параллелизма - система отвечает за использование любой способности распараллеливать выполнение задач без ведома пользователя или взаимодействия с ним. Возможно, это самый сложный аспект прозрачности, который Таненбаум назвал «Святым Граалем» для разработчиков распределенных систем. [37] : 23–25

Межпроцессное взаимодействие [ править ]

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

Управление процессами [ править ]

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

Например, балансировка нагрузки - это обычная функция управления процессами. Балансировка нагрузки контролирует производительность узлов и отвечает за переключение активности между узлами, когда система не сбалансирована. Одна из функций балансировки нагрузки - это выбор процесса для перемещения. Ядро может использовать несколько механизмов выбора, включая выбор на основе приоритета. Этот механизм выбирает процесс на основе такой политики, как «новейший запрос». Система реализует политику

Управление ресурсами [ править ]

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

Надежность [ править ]

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

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

Доступность [ править ]

Доступность - это промежуток времени, в течение которого система может отвечать на запросы.

Производительность [ править ]

Многие контрольные показатели позволяют количественно оценить производительность ; пропускная способность, время отклика, выполнение заданий за единицу времени, использование системы и т. д. Что касается распределенной ОС, производительность чаще всего сводится к балансу между параллелизмом процессов и IPC. [ необходимая цитата ] Управление гранулярностью задач параллелизма в разумном отношении к сообщениям, необходимым для поддержки, чрезвычайно эффективно. [ необходима цитата ] Кроме того, также эффективно определить, когда более выгодно перенести процесс на его данные, а не копировать данные. [ необходима цитата ]

Синхронизация [ править ]

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

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

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

Гибкость [ править ]

Гибкость распределенной операционной системы повышается за счет модульности и характеристик распределенной ОС, а также за счет предоставления более богатого набора сервисов более высокого уровня. Полнота и качество ядра / микроядра упрощает реализацию таких сервисов и потенциально дает поставщикам услуг больший выбор поставщиков для таких сервисов. [ необходима цитата ]

Исследование [ править ]

Реплицируемая модель расширена до объектной модели компонента [ править ]

 Архитектурный дизайн распределенной операционной системы E1 [38]
  Распределенная операционная система Cronus [39]
  Дизайн и разработка распределенной операционной системы MINIX [40]

Сложность / доверие через принятую ответственность [ править ]

Масштаб и производительность изолированного ядра Denali. [41]

Много / многоядерные системы [ править ]

Мультиядерность: новая архитектура ОС для масштабируемых многоядерных систем. [42]
Кори: Операционная система для многих ядер. [43]
Almos: расширенная операционная система управления местоположением для многоядерных процессоров cc-NUMA. [44]

Распределенная обработка крайностей в неоднородности [ править ]

Helios: гетерогенная многопроцессорная обработка со сателлитными ядрами. [45]

Эффективен и стабилен на нескольких уровнях сложности [ править ]

Тесселяция: пространственно-временное разбиение в клиентской ОС Manycore. [46]

См. Также [ править ]

  • Распределенных вычислений
  • План 9 от Bell Labs
  • Inferno
  • МИНИКС
  • Единый образ системы (SSI)
  • Архитектура компьютерных систем
  • Мультиядерность
  • Список важных публикаций по параллельным, параллельным и распределенным вычислениям
  • Проекты операционной системы
  • Премия Эдсгера В. Дейкстры в области распределенных вычислений
  • Список конференций по распределенным вычислениям
  • Список распределенных вычислительных проектов

Ссылки [ править ]

  1. ^ a b Таненбаум, Эндрю S (сентябрь 1993 г.). «Распределенные операционные системы в 1992 году. Что мы узнали на данный момент?» . Распределенная системная инженерия . 1 (1): 3–10. Bibcode : 1993DSE ..... 1 .... 3T . DOI : 10.1088 / 0967-1846 / 1/1/001 .
  2. Перейти ↑ Nutt, Gary J. (1992). Централизованные и распределенные операционные системы . Прентис Холл. ISBN 978-0-13-122326-4.
  3. ^ a b c d e f Gościński, Анджей (1991). Распределенные операционные системы: логический дизайн . Аддисон-Уэсли Паб. Co. ISBN 978-0-201-41704-3.
  4. ^ Фортир, Пол Дж (1986). Дизайн распределенных операционных систем: концепции и технологии . Интертекстовые публикации. ISBN 9780070216211.
  5. ^ Хансен, Пер Бринч, изд. (2001). Классические операционные системы: от пакетной обработки к распределенным системам . Springer. ISBN 978-0-387-95113-3.
  6. ^ Использование LOTOS для указания ядра распределенной операционной системы CHORUS Pecheur, C. 1992. Использование LOTOS для указания ядра распределенной операционной системы CHORUS. Comput. Commun. 15, 2 (март 1992 г.), 93-102.
  7. ^ COOL: поддержка ядра для объектно-ориентированных сред Habert, S. и Mosseri, L. 1990. COOL: поддержка ядра для объектно-ориентированных сред. В материалах Европейской конференции по объектно-ориентированному программированию по системам, языкам и приложениям объектно-ориентированного программирования (Оттава, Канада). ОПСЛА / ЭКООП '90. ACM, Нью-Йорк, Нью-Йорк, 269-275.
  8. ^ а б в г д Синха, Прадип Кумар (1997). Распределенные операционные системы: концепции и дизайн . IEEE Press. ISBN 978-0-7803-1119-0.
  9. ^ a b c d Галли, Дорин Л. (2000). Распределенные операционные системы: концепции и практика . Прентис Холл. ISBN 978-0-13-079843-5.
  10. ^ a b c d Чоу, Рэнди; Теодор Джонсон (1997). Распределенные операционные системы и алгоритмы . Эддисон Уэсли. ISBN 978-0-201-49838-7.
  11. ^ Сураджбали Б., Колсон Г., Гринвуд П. и Грейс П. 2007. Дополнение отражающего промежуточного программного обеспечения слоем поддержки ориентации сторон. В материалах 6-го международного семинара по адаптивному и рефлексивному промежуточному программному обеспечению: проведенного на международной конференции по промежуточному программному обеспечению ACM / IFIP / USENIX (Ньюпорт-Бич, Калифорния, 26–30 ноября 2007 г.). ARM '07. ACM, Нью-Йорк, штат Нью-Йорк, 1-6.
  12. ^ Leiner, Alan L. (апрель 1954). «Технические характеристики системы для DYSEAC» . Журнал ACM . 1 (2): 57–81. DOI : 10.1145 / 320772.320773 .
  13. ^ a b Форги, Джеймс У. (26–28 февраля 1957 г.). Система ввода-вывода Lincoln TX-2 . Совместная западная компьютерная конференция: методы обеспечения надежности. Лос-Анджелес, Калифорния: Ассоциация вычислительной техники. С. 156–160. DOI : 10.1145 / 1455567.1455594 . ISBN 9781450378611.
  14. ^ a b К. Ю. Ли (4–6 декабря 1962 г.). Взаимосвязанные ячейки, основа распределенного логического компьютера . Осенняя совместная компьютерная конференция. Филадельфия, Пенсильвания: Ассоциация вычислительной техники. С. 130–136. DOI : 10.1145 / 1461518.1461531 .
  15. ^ Дрейфус, Филипп (1958-05-08) [1958-05-06], написанный в Лос-Анджелесе, "Системный дизайн гамма 60" (PDF) , Труды 6-8 мая 1958 года, Western Joint Computer Conference : Contrasts in Computers , ACM, New York, NY, USA, стр. 130–133, IRE-ACM-AIEE '58 (Western), заархивировано (PDF) из оригинала 03.04.2017 , извлечено 2017-04- 03
  16. ^ Leiner, AL, Notz, WA, Smith, JL, и Weinberger, A. 1958. Организация сети компьютеров для соблюдения сроков. В статьях и дискуссиях, представленных 9–13 декабря 1957 г., Восточной объединенной компьютерной конференции: компьютеры с соблюдением сроков (Вашингтон, округ Колумбия, 9–13 декабря 1957 г.). IRE-ACM-AIEE '57
  17. ^ Leiner, AL, Smith, JL, Notz, WA, and Weinberger, A. 1958. PILOT, мультикомпьютерная система NBS. В статьях и обсуждениях, представленных на 3–5 декабря 1958 г., Восточной объединенной компьютерной конференции: Современные компьютеры: цели, конструкции, приложения (Филадельфия, Пенсильвания, 3–05 декабря 1958 г.). AIEE-ACM-IRE '58 (восточный). ACM, Нью-Йорк, штат Нью-Йорк, 71–75.
  18. ^ Бауэр, WF 1958. Компьютерный дизайн с точки зрения программиста. В статьях и обсуждениях, представленных на 3–5 декабря 1958 г., Восточной объединенной компьютерной конференции: Современные компьютеры: цели, конструкции, приложения (Филадельфия, Пенсильвания, 3–05 декабря 1958 г.). AIEE-ACM-IRE '58 (восточный). ACM, Нью-Йорк, штат Нью-Йорк, 46-51.
  19. ^ Leiner, AL, Notz, WA, Smith, JL, и Weinberger, A. 1959. PILOT - Новая система для нескольких компьютеров. J. ACM 6, 3 (июль 1959), 313–335.
  20. ^ Эстрин, Г. 1960. Организация компьютерных систем: компьютер с фиксированной плюс переменной структурой . В статьях, представленных на совместной компьютерной конференции IRE-AIEE-ACM 3–5 мая 1960 г. (Сан-Франциско, Калифорния, 03–05 мая 1960 г.). IRE-AIEE-ACM '60 (западный). ACM, Нью-Йорк, штат Нью-Йорк, 33-40.
  21. ^ Мартин Х. Вейк, "Третий обзор отечественных электронных цифровых вычислительных систем", Отчет лабораторий баллистических исследований № 1115, стр. 234-5, Абердинский полигон, Мэриленд, март 1961 г.
  22. ^ Mellor-Crummey, JM и Scott, ML 1991. Алгоритмы масштабируемой синхронизации на мультипроцессорах с общей памятью . ACM Trans. Comput. Syst. 9, 1 (февраль 1991 г.), 21–65.
  23. Перейти ↑ Baker, MG, Hartman, JH, Kupfer, MD, Shirriff, KW, and Ousterhout, JK 1991. Измерения распределенной файловой системы . В материалах тринадцатого симпозиума ACM по принципам операционных систем (Пасифик Гроув, Калифорния, США, 13–16 октября 1991 г.). СОСП '91. ACM, Нью-Йорк, штат Нью-Йорк, 198–212.
  24. ^ Ли, К. и Худак, П. 1989. Согласованность памяти в совместно используемых системах виртуальной памяти. ACM Trans. Comput. Syst. 7, 4 (ноябрь 1989 г.), 321-359.
  25. ^ Гарсия-Молина, Х. и Салем, К. 1987. Саги. В материалах международной конференции ACM SIGMOD 1987 г. по управлению данными (Сан-Франциско, Калифорния, США, 27–29 мая 1987 г.). У. Дайал, Под ред. SIGMOD '87. ACM, Нью-Йорк, штат Нью-Йорк, 249–259.
  26. ^ Харрис, Т., Марлоу, С., Пейтон-Джонс, С. , и Херлихи, М. 2005. Транзакции составной памяти . В материалах десятого симпозиума ACM SIGPLAN по принципам и практике параллельного программирования (Чикаго, Иллинойс, США, 15–17 июня 2005 г.). PPoPP '05. ACM, Нью-Йорк, штат Нью-Йорк, 48-60.
  27. ^ Херлихи, М. и Мосс, JE 1993. Транзакционная память: архитектурная поддержка структур данных без блокировки . В материалах 20-го ежегодного международного симпозиума по компьютерной архитектуре (Сан-Диего, Калифорния, США, 16–19 мая 1993 г.). ISCA '93. ACM, Нью-Йорк, Нью-Йорк, 289-300.
  28. ^ Херлихи, М., Лучанко, В., Мойр, М., и Шерер, В. Н. 2003. Программная транзакционная память для структур данных динамического размера . В материалах двадцать второго ежегодного симпозиума по принципам распределенных вычислений (Бостон, Массачусетс, 13–16 июля 2003 г.). PODC '03. ACM, Нью-Йорк, штат Нью-Йорк, 92-101.
  29. ^ Шавит, Н. и Тоуиту, Д. 1995. Программная транзакционная память . В материалах четырнадцатого ежегодного симпозиума ACM по принципам распределенных вычислений (Оттава, Онтарио, Канада, 20–23 августа 1995 г.). PODC '95. ACM, Нью-Йорк, Нью-Йорк, 204-213.
  30. ^ Kubiatowicz, J., Биндел Д., Chen Y., Czerwinski, S., Eaton, P., Geels Д., Gummadi Р., Рея, S., Weatherspoon, Г. Уэллс, С. , и Чжао, Б. 2000. OceanStore: архитектура для постоянного хранения в глобальном масштабе . В материалах Девятой международной конференции по архитектурной поддержке языков программирования и операционных систем (Кембридж, Массачусетс, США). АСПЛОС-IX. ACM, Нью-Йорк, штат Нью-Йорк, 190-201.
  31. ^ Гиффорд, Д. К. 1979. Взвешенное голосование за реплицированные данные . В материалах седьмого симпозиума ACM по принципам операционных систем (Пасифик Гроув, Калифорния, США, 10–12 декабря 1979 г.). СОСП '79. ACM, Нью-Йорк, NY, 150-162
  32. ^ Дворк, К., Линч, Н., и Стокмейер, Л. 1988. Консенсус при наличии частичной синхронности . J. ACM 35, 2 (апрель 1988 г.), 288-323.
  33. ^ Лампорт, Л., Шостак, Р. и Pease, М. 1982. Византийская Генералы Проблема . ACM Trans. Программа. Lang. Syst. 4, 3 (июл 1982 г.), 382-401.
  34. ^ Schlichting, RD и Schneider, FB 1983. Отказоустойчивые процессоры: подход к разработке отказоустойчивых вычислительных систем. ACM Trans. Comput. Syst. 1, 3 (август 1983 г.), 222-238.
  35. ^ Чанди, К. М. и Лэмпорт, Л. 1985. Распределенные моментальные снимки: определение глобальных состояний распределенных систем. ACM Trans. Comput. Syst. 3, 1 (февраль 1985 г.), 63–75.
  36. ^ Стром, Р. и Йемини, С. 1985. Оптимистическое восстановление в распределенных системах. ACM Trans. Comput. Syst. 3, 3
  37. ^ Таненбаум, Эндрю С. (1995). Распределенные операционные системы . Прентис Холл. ISBN 978-0-13-219908-7.
  38. ^ LB Рыжик, AY Бурцев. Архитектурный проект распределенной операционной системы dE1. Международный научно-технический журнал «Системные исследования и информационные технологии», октябрь 2004 г., Киев, Украина.
  39. ^ Винтер, ST и Шанц, RE 1986. Распределенная операционная система Cronus. В материалах 2-го семинара по обеспечению работы распределенных систем (Амстердам, Нидерланды, 8–10 сентября 1986 г.). EW 2. ACM, Нью-Йорк, штат Нью-Йорк, 1-3.
  40. ^ Рамеш, KS 1988. Проектирование и разработка распределенной операционной системы MINIX. В материалах Шестнадцатой ежегодной конференции ACM 1988 г. по информатике (Атланта, Джорджия, США). CSC '88. ACM, Нью-Йорк, Нью-Йорк, 685.
  41. ↑ Whitaker, A., Shaw, M., and Gribble, SD 2002. В материалах 5-го симпозиума по разработке и внедрению операционных систем.
  42. ^ Baumann, А., Barham П., Dagand П., Харрис Т., Айзекс Р., Питер С., Роско Т., Шупбы А., Сингхание А. 2009. В Трудах 22-го симпозиума ACM SIGOPS по принципам работы операционных систем (Биг Скай, Монтана, США, 11–14 октября 2009 г.). СОСП '09.
  43. ^ С. Бойд-Викизер, Х. Чен, Р. Чен, Ю. Мао, Ф. Кашук, Р. Моррис, А. Пестерев, Л. Штейн, М. Ву, Ю. Дай, Ю. Чжан и З. Чжан. Труды Симпозиума 2008 г. по разработке и внедрению операционных систем (OSDI), декабрь 2008 г.
  44. ^ Almaless, Г. и Wajsbürt Ф. 2011. Труды 5го национального семинара ГДР SoC-SIP, Лион, Франция, 2011.
  45. ^ Соловей, Е. Б., Ходсон, О., McIlroy Р., Hawblitzel, К., и Хант, Г. 2009. В Трудах ACM SIGOPS 22 Симпозиуме по принципам операционных систем (Big Sky, Монтана, США, октябрь 11- 14, 2009). СОСП '09.
  46. ^ Rose Liu, Кевин Klues, и Сара Берд, Калифорнийский университет в Беркли; Стивен Хофмейр, Национальная лаборатория Лоуренса Беркли; Крсте Асанович и Джон Кубятович, Калифорнийский университет в Беркли. HotPar09.

Внешние ссылки [ править ]

  • Распределенные вычисления в Curlie
  • Журналы распределенных вычислений в Curlie
  • Лаборатория параллельных и распределенных операционных систем Массачусетского технологического института
  • Лаборатория параллельных вычислений UCB
  • Лаборатория параллельных данных
  • Распределенная среда Plan 9
  • Распределенная операционная система E1
  • Исходный код Amoeba DOS
  • Домашняя страница амебы
  • USENIX: ассоциация Advanced Computing
  • Как работает Stuff - Операционные системы
  • Алгоритмы масштабируемой синхронизации