Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

2.6. Итоги 161

заголовок, содержащий всю контрольную информацию, было бы более эф-

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

лается?

Почему коммуникационные службы транспортного уровня обычно не подхо-

дят для построения распределенных приложений?

Надежная массовая рассылка требует от отправителя надежной посылки со-

общений группе получателе^!. Может ли подобная служба находиться на про-

межуточном уровне или должна быть частью нижнего уровня?

Рассмотрим процедуру incr с двумя целыми параметрами. Эта процедура до-

бавляет к каждому из параметров единицу. Представим себе, что в качестве

обоих параметров используется одна и та же переменная -- incrd . 1). Если

переменная 1 изначально равна О, какое значение будет у нее при вызове по

ссылке? А при использовании механизма копирования/восстановления?

В языке С существует конструкция, называемая объединением (union), в ко-

торой поле записи — в С называемой структурой (struct) — может хранить

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

способа определить, что там находится, не существует. Должна ли эта особен-

ность языка С как-то поддерживаться при удаленном вызове процедур? По-

ясните свой ответ.

6. Один из способов преобразования параметров в системах RPC — требовать

от каждой машины передачи параметров в их натуральном виде, с тем чтобы

преобразованием занимался получатель сообщения. Базовая система пред-

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

подобная система, если учесть, что нахождение первого байта в первом сло-

ве

—

само по себе проблема?

Рассмотрим клиент, посылающий на сервер асинхронный вызов RPC и ожи-

дающий возвращения сервером результата, который также будет послан при

помощи асинхронного вызова RPC. Будет ли это аналогично использованию

клиентом обычного вызова RPC? Что произойдет, если мы заменим асин-

хронные вызовы RPC синхронными?

8. Вместо регистрации некоего сервера с помощью демона, как это сделано

в DCE, мы могли бы навсегда закрепить его за одной из конечных точек.

Конечная точка затем может использоваться в качестве ссылки на объект

в адресном пространстве сервера. Каково основное неудобство подобной схемы?

9. Приведите пример реализации ссылки на объект, которая позволила бы кли-

енту выполнить привязку к нерезидентному удаленному объекту.

10.

Java и другие языки поддерживают обработку исключений, которые возбуж-

даются при возникновении ошибки. Каким образом можно применить ис-

ключения в RPC и RMI?

И. Можно ли использовать механизм исключений также и для того, чтобы отли-

чать статические вызовы RPC от динамических?

162 Глава 2. Связь

12.

Некоторые реализации систем промежуточного уровня на базе распределен-

ных объектов целиком базируются на динамическом обращении к методам.

СтатическР1е обращения при компиляции преобразуются в динамические.

В чем преимущества подобного подхода?

13.

Опишите, как реализуется связь без образования соединения между клиен-

том и сервером при использовании сокетов.

14.

Объясните разницу между примитивами MPI_bsend и MPI_isend в MPI.

15.

Предположим, что мы в состоянии использовать только примитивы нерези-

дентной асинхронной связи, причем исключительно примитивы асинхронного

приема. Как в таком случае реализовать примитивы для нерезидентной сип-

хроппой связи?

16.

Теперь предположим, что мы в состоянии использовать только примитивы

для нерезидентной синхронной связи. Как при этом реализовать примитивы

для нерезидентной

асинхронной

связи?

17.

Имеет ли смысл реализовывать сохранную асинхронную связь средствами

RPC?

18.

В тексте мы упоминали, что для автоматического запуска процесса, извле-

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

следит за ее состоянием. Опишите альтернативную реализацию, не требую-

щую использования демона.

19.

Таблицы маршрутизации в системе MQSeries фирмы IBM и множестве дру-

гих систем очередей сообщений настраиваются вручную. Опишите простой

способ автоматизации этой работы.

20.

Как встроить сохранную асинхронную связь в коммуникационную модель на

базе удаленных объектов RMI?

21.

В случае сохранной связи получатель обычно имеет свой собственный буфер,

в котором в период его пассивности хранятся сообщения. Чтобы создать по-

добный буфер, нам может понадобиться информация о его размере. Приведи-

те аргументы за и против указания размера.

22.

Опишите, почему нерезидентная синхронная связь имеет «врожденные» про-

блемы с масштабируемостью, и как эти проблемы могут решаться.

23.

Приведите пример, когда групповая рассылка может быть полезной для дис-

кретных потоков данных.

24.

Как можно было бы гарантировать максимальную сквозную задержку пере-

даче!

при организации группы компьютеров в кольцо (физическое или логи-

ческое)?

25.

Как можно было бы гарантировать минимальную сквозную задержку переда-

чи при организации группы компьютеров в кольцо (физическое или логиче-

ское)?

26.

Представьте, что у вас есть спецификация корзины элементарных пакетов с

максимальным размером элемента данных

—

1000 байт, скоростью работы

2.6.

Итоги 163

корзины

—

10 Мбайт/с, емкостью корзины

— 1

Мбайт и максимальной скоро-

стью передачи

—

50 Мбайт/с. Как долго она сможет работать на максималь-

ной скорости?

27.

В этом упражнении вам следует реализовать простую систему клиент-сервер

на базе RPC. Сервер предоставляет одну процедуру next, которая в качестве

входного параметра получает целое число и возвравдает следующее за ним

число. Напишите процедуру-заглушку next для использования на стороне

клиента. Она должна будет пересылать параметры на сервер, используя про-

токол UDP, и ожидать ответа, причем следует рассчитывать на очень дли-

тельное время ожидания. Серверная процедура должна следить за соответст-

вующим портом, принимать запрос, выполнять его и возвращать результат

клиенту.

Глава 3

Процессы

3.1.

Потоки выполнения

3.2. Клиенты

3.3. Серверы

3.4. Перенос кода

3.5. Программные агенты

3.6. Итоги

В предыдущей главе мы обсуждали взаимодействие в распределенных системах.

Взаимодействие происходит между процессами, и в этой главе мы поближе рас-

смотрим то, какую роль играют в распределенных системах различные типы про-

цессов. Концепция процесса зародилась в операционных системах, где этим

понятием обычно обозначают выполняемую программу. С точки зрения операци-

онных систем наиболее важные для обсуждения вопросы

—

это управление про-

цессами и планирование процессов. Однако при переходе к распределенным сис-

темам другие вопросы становятся столь же или еще более важными.

Так, например, для эффективной организации систем клиент-сервер часто

бывает удобно использовать многопоточные технологии. Как мы обсудим в пер-

вом разделе этой главы, основной вклад потоков выполнения в работу распреде-

ленных систем заключается в том, что они позволяют создавать клиенты и сер-

веры так, что взаимодействие и локальная обработка выполняются параллельно,

давая выигрыш в производительности.

Как мы говорили в главе 1, модель клиент-сервер крайне важна для распреде-

ленных систем. В этой главе мы детально рассмотрим основные типы органи-

зации клиентов и серверов. Мы также уделим внимание общим вопросам по-

строения серверов. Кроме того, мы обсудим общедоступные серверы объектов,

которые предоставляют базовые средства для построения распределенных объ-

ектов.

Серьезной проблемой, особенно в глобальных системах, является перенос

процессов между различными машинами. Миграция процессов, или, более точно,

миграция кода, может помочь повысить масштабируемость и, кроме того, помо-

гает динамически конфигурировать клиенты и серверы. Что на самом деле под-

3.1.

Потоки выполнения 165

разумевается под миграцией кода и как она реализуется, также будет рассмотре-

но в этой главе.

Последняя наша тема связана с относительно новым явле1Н1ем

—

программ-

ными агентами. В отличие от асимметричной программной модели клиент-

сервер, мультиагентные системы в основном состоят из набора одршаково

важных агентов, совместная работа которых приводит к достижению общей

цели. Программные агенты — это еще один тип процессов, которые могут

существовать в различных формах. В последнем разделе рассказывается, что

такое агенты с точки зрения распределенных систем и каковы принципы их

совместной работы.

3.1.

Потоки выполнения

Хотя процессы являются строительными блоками распределенных систем, прак-

тика показывает, что дробления на процессы, предоставляемого операционны-

ми системами, на базе которых строятся распределенные системы, недостаточно.

Вместо этого оказывается, что наличие более тонкого дробления в форме не-

скольких потоков выполнения {threads) на процесс значительно упрощает по-

строение распределенных приложений и позволяет добиться лучшей производи-

тельности. В этом разделе мы подробно рассмотрим роль потоков выполнения

в распределенных системах и объясним, почему они так важны. Дополнительную

информацию о потоках выполнения и о том, как они используются для построе-

ния приложений, можно найти в [263, 439].

3.1.1.

Знакомство с потоками выполнения

Для понимания роли потоков выполнения в распределенных системах важно по-

нять,

что такое процесс и как соотносятся между собой процессы и потоки вы-

полнения. Для выполненрш программ операционная система создает несколько

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

вать эти виртуальные процессоры, операционная система поддерживает таблицу

процессов {process

table),

содержащую записи для сохранения значений регистров

процессора, карт памяти, открытых файлов, учетных записях пользователей, при-

вилегиях и т. п.

Процесс {process)

часто определяют как выполняемую программу,

то есть программу, которая в настоящее время выполняется на одном из вирту-

альных процессоров операционной системы. Следует отметить, что операцион-

ная система уделяет огромное внимание гарантиям того, чтобы эти независимые

процессы по злому умыслу или ненамеренно не нарушили правильную работу

других процессов. Другими словами, тот факт, что множество процессов совмест-

но используют один и тот же процессор и другие аппаратные ресурсы, прозрачен.

Обычно для того, чтобы подобным образом отделять процессы друг от друга, опе-

рационной системе требуется аппаратная поддержка.

Прозрачность параллельной работы обходится довольно дорого. Так, напри-

мер,

каждый раз при создании процесса операционная система должна создавать

166 Глава 3. Процессы

абсолютно независимое адресное пространство. Выделение памяти требует ини-

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

пирования соответствующей программы в сегмент кода и помещения в стек вре-

менных данных. Переключение процессора между двумя процессами

—

также

довольно дорогостоящая операция. Кроме сохранения контекста процессора (в ко-

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

операционная система должна также изменить регистры блока управления

памятью (Memory Management Unit, MMU) и объявить некорректным содержи-

мое кэша трансляции адресов, например ассоциативного буфера страниц (Trans-

lation Lookaside Buffer, TLB). Кроме того, если операционная система поддерживает

больше процессов, чем может одновременно поместиться в оперативной памя-

ти,

перед действительным переключением с одного процесса на другой может

потребоваться подкачка {swapping) процессов между оперативной памятью и

диском.

Поток выполнения очень похож на процесс, в том смысле, что он также мо-

жет рассматриваться как программа, выполняемая на виртуальном процессоре.

Однако в отличие от процесса не следует пытаться достичь высокой степени

прозрачности параллельного выполнения потоков, поскольку это приводит к па-

дению производительности. Тем не менее система потоков выполнения обычно

обеспечивает лишь тот минимум информации, который позволяет совместно ис-

пользовать процессор для различных потоков выполнения. В частности, кон-

текст потока выполпепия {thread context) нередко содержит просто контекст

процессора и некоторую другую информацию, необходимую для управления по-

током выполнения. Так, например, система потоков может отслеживать факт бло-

кировки потока переменной мьютекса и вытекающую из этого невозможность

переключения на выполнение такого потока. Информация, не являющаяся абсо-

лютно необходимой для управления многочисленными потоками, обычно игно-

рируется. По этой причине задача защиты данных в потоках выполнения одного

процесса от несанкционированного доступа возлагается на разработчиков при-

ложения.

У подобного подхода имеется два аспекта. Во-первых, высокая производи-

тельность многопоточных приложений достижима с гораздо меньшими усилия-

ми,

чем в случае их однопоточного аналога. На самом деле многопоточные систе-

мы обычно дают выигрыш в производительности. Во-вторых, поскольку потоки

выполнения одного процесса не защищаются автоматически друг от друга, раз-

работка многопоточных приложений требует дополнительных интеллектуальных

усилий. Обычно хорошо помогает правильное проектирование и ясность мысли.

К сожалению, текущая практика показывает, что эти принципы не всегда вос-

принимаются должным образом.

Потоки выполнения в нераспределенных системах

До того как мы примемся обсуждать роль потоков выполнения в распределенных

системах, рассмотрим сначала, как они используются в системах обычных, нерас-

пределенных. Многопоточные процессы способны принести определенные выго-

ды,

повышающие популярность систем с их поддержкой.

3.1.

Потоки выполнения 167

Наиболее важное преимущество вытекает из того факта, что процессы с од-

ним потоком выполнения целиком блокируются при любом блокирующем сис-

темном вызове. В качестве иллюстрации рассмотрим какое-либо приложение,

например электронные таблицы. Представим себе, что пользователь хочет по-

стоянно изменять значения ячеек в интерактивном режиме. Важным свойством

электронных таблиц является поддержка функциональных зависимостей между

различными ячейками таблицы или различными таблицами. Таким образом, ка-

ждый раз при модификации ячейки все ячейки, связанные с ней, автоматически

обновляются. После того как пользователь изменит значение одной из ячеек,

внесенное

PIM

изменение вызовет значительный объем вычислений. Если мы бу-

дем работать только с одним потоком выполнения, во время ожидания ввода эти

вычисления окажутся невозможными. Точно так же нелегко будет организовать

ввод в процессе вычислений. Самым простым решением было бы создать как

минимум два потока выполнения

—

один для поддержания работы с пользовате-

лем, другой для обновления таблиц.

Другим преимуществом многопоточности является возможность обеспече-

ния параллелизма выполнения программ в мультипроцессорной системе. В этом

случае каждый поток выполняется на своем процессоре, а совместно используе-

мые данные размещаются в общей (разделяемой) памяти. При правильном про-

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

работать так же хорошо и в однопроцессорной системе, разве что немного мед-

леннее. Многопоточная структура в связи с доступностью относительно недорогих

мультипроцессорных рабочих станций становится все важнее в плане поддерж-

ки параллельного выполнения. На подобных компьютерных системах обычно ра-

ботают серверы в приложениях клиент-сервер.

Многопоточная структура часто используется при построении больших при-

ложений. Подобные приложения часто разрабатываются в виде наборов совме-

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

сом. Этот подход типичен для среды UNIX. Кооперация между программами

реализуется в виде межпроцессного взаимодействия (через механизмы IPC).

Для UNIX-систем эти механизмы обычно включают в себя каналы (ршенован-

ные),

очереди сообщений и совместно используемые сегменты памяти

[436].

Ос-

новной оборотной стороной механизмов IPC является необходимость интенсив-

ного переключения контекстов, продемонстрированная тремя точками на

ppic.

3.1.

Поскольку IPC требует вмешательства в ядро, процесс обычно вынужден

сначала переключиться из пользовательского режима в режим ядра (точка S1 на

рисунке). Это требует изменения карты памяти в блоке MMU, а также сброса

буфера TLB. В ядре происходит переключение контекста процесса (точка 52),

после чего второй процесс может быть активизирован очередным переключени-

ем из режима ядра в пользовательский режим (точка S3). Последнее переключе-

ние вновь потребует изменения карты памяти в блоке MMU и буфера сброса

TLB.

Вместо использования процессов приложение может быть построено так,

чтобы различные части выполнялись в отдельных потоках. Связь между этими

частями обеспечивается только через разделяемую память. Переключение между

168 Глава 3. Процессы

потоками выполнения может происходить исключительно в пространстве поль-

зователя, хотя в некоторых реализациях за потоки выполнения отвечает (управ-

ляет ими) ядро. Результатом может быть значительное повышение производи-

тельности.

S1:

переключение

из пространства

пользователя

в пространство ядра

S3:

переключение

из пространства ядра

в пространство пользователя

S2:

переключение контекста

из процесса А в процесс В

Рис. 3.1. Переключение контекстов в результате вызова IPC

И, наконец, у разработчиков имеется особая причина использовать потоки

выполнения: многие приложения просто легче разрабатывать, структурировав их

в виде набора взаимосвязанных потоков выполнения. Рассмотрим приложение,

требующее выполнения нескольких (более или менее независимых) задач. На-

пример, в случае текстового редактора в отдельные потоки можно выделить об-

работку ввода пользователя, проверку орфографии и грамматики, оформление

внешнего вида документа, создание индекса и т. п.

Реализация потоков выполнения

Потоки выполнения обычно существуют в виде пакетов. Подобные пакеты содер-

жат механизмы для создания и уничтожения потоков, а также для работы с пере-

менными синхронизации, такими как мьютексы и условные переменные. Суще-

ствует два основных подхода к реализации пакетов для потоков выполнения.

Первый из них состоит в создании библиотеки для работы с потоками выполне-

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

предполагает, что за потоки выполнения отвечает (и управляет ими) ядро.

Библиотека для работы с потоками выполнения на пользовательском уровне

имеет множество преимуществ. Во-первых, дешевле обходится создание и унич-

тожение потоков выполнения. Поскольку все управление потоками реализуется

в адресном пространстве пользователя, стоимость создания потока выполнения

определяется в первую очередь затратами на память, выделяемую для создания

стека под поток. Аналогично и уничтожение потока выполнения в основном со-

стоит в освобождении памяти, задействованной под стек, после того как надоб-

ность в потоке отпадает. Обе операции достаточно дешевы.

Второе преимущество потоков выполнения на пользовательском уровне со-

стоит в том, что переключение контекста требует всего нескольких инструкций.

3.1.

Потоки выполнения

169

В основном в сохранении и последующем восстановлении сохраненных значе-

ний при переключении с потока на поток нуждаются исключительно значения

регистров процессора. Нет необходимости изменять карты памяти, сбрасывать

буфер TLB, контролировать загрузку процессора и т. д. Переключение контекста

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

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

Основным недостатком потоков выполнения на пользовательском уровне яв-

ляется тот факт, что обращение к блокирующему системному вызову приводит

к немедленной блокировке как процесса, к которому принадлежит поток выпол-

нения, так и всех остальных потоков выполнения этого процесса. Как мы гово-

рили, потоки выполнения используются, в частности, для структурирования

больших приложений в виде набора одновременно исполняемых частей. В этом

случае блокировка по вводу-выводу не должна мешать работе исполняемых в то

же самое время частей программы. Для подобных приложений реализация пото-

ков выполнения на пользовательском уровне неприемлема.

Эти проблемы обычно можно обойти путем реализации потоков выполнения

в ядре операционной системы. К сожалению, плата за это весьма высока: любая

операция с потоками выполнения (создание, уничтожение, синхронизация и т. п.),

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

токов выполнения становится столь же дорогостоящим, как и переключение

контекстов процессов. В результате сходят на нет основные преимущества от за-

мены процессов потоками выполнения.

Пространство пользователя

Состояние (данные)

потока выполнения

JHL

2^-%

ш^

Облегченный процесс,

выполняющий один из потоков

Пространство ядра

- Поток выполнения

- Облегченный процесс

Рис. 3.2. Сочетание облегченных процессов уровня ядра

и потоков выполнения уровня пользователя

Решение состоит в использовании «гибрида» из реализованных на уровне

пользователя и на уровне ядра потоков выполнения (рис. 3.2). Такой гибрид но-

сит название

облегченных процессов (LightWeight

Processes,

LWP). Процессы LWP

работают в контексте едх^ного полновесного процесса. На один процесс может

приходиться несколько LWP. Кроме LWP система предоставляет также пакет

170 Глава 3. Процессы

потоков выполнения пользовательского уровня, предоставляющего приложени-

ям операции по созданию и уничтожению потоков выполнения. Кроме того, этот

пакет предоставляет средства синхронизации потоков выполнения, такие как мью-

тексы и условные переменные (см. также раздел 1.4). Важным моментом здесь

является то, что пакет для работы с потоками выполнения реализован целиком

в пространстве пользователя. Другими словами, все операции с потоками выпол-

нения производятся без участия ядра.

Как показано на рисунке, пакет потоков выполнения может совместно ис-

пользоваться несколькими облегченными процессами. Многопоточное приложе-

ние реализуется путем создания потоков выполнения с последующим назна-

чением каждого из них своему облегченному процессу. Назначение потока

выполнения облегченному процессу обычно производится неявно и скрыто от

программиста.

Сочетание потоков выполнения пользовательского уровня и облегченных

процессов работает так, как показано на рисунке. Подключение следующего по-

тока выполняется специальной планирующей процедурой, входящей в пакет пото-

ков.

При создании (путем срютемного вызова) облегченного процесса он получает

собственный стек и указание выполнить планирующую процедуру д.яя поиска

потока, который он должен исполнять. Если создается несколько облегченных

процессов, планирующую процедуру выполняет каждый из них. Таблица потоков

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

ется облегченными процессами совместно. Защита этой таблицы для предотвра-

щения одновременного доступа к ней реализуется при помощи мьютексов, соз-

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

облегченными процессами не требует поддержки со стороны ядра.

Когда облегченный процесс находит готовый к выполнению поток, он пе-

реключает свой контекст на этот поток. В это время другие облегченные про-

цессы могут искать себе другие готовые к выполнению потоки. Если поток

выполнения требуется заблокировать по значению мьютекса или условной пе-

ременной, он выполняет необходимое администрирование и, в конце концов,

вызывает планирующую процедуру. Если будет обнаружен другой готовый к

выполнению поток, контекст может переключиться на него. Прелесть всего

этого состоит в том, что облегченный процесс, выполняющий поток, не уведом-

ляется о переключении контекста, оно происходит исключительно в простран-

стве пользователя и воспринимается облегченным процессом как обычный код

программы.

Рассмотрим теперь, что происходит, когда поток делает блокирующий сис-

темный вызов. В этом случае выполнение переходит от пользовательского режима

к режиму ядра, продолжая при этом оставаться в контексте текущего облегчен-

ного процесса. В тот момент, когда текущий облегченный процесс можно будет

прервать, операционная система может принять решение переключиться на дру-

гой облегченный процесс, в результате чего контекст переключится обратно

в пользовательский режим. Выбранный облегченный процесс просто продолжит

свою работу с того места, где он ранее был прерван.