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

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

1.2. Задачи 31

крытая распределенная система должна быть расширяемой. Например, к гибкой

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

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

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

рить о гибкости куда проще, чем ее осуществить.

Отделение правил

от

механизмов

в построении гибких открытых распределенных систем решающим фактором

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

и легко заменяемых или адаптируемых компонентов. Это предполагает необхо-

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

тают пользователи и приложения, но также

интерфейсов внутренних модулей

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

молод. Множество старых и современных систем создавались цельными так, что

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

чае использования этого подхода независимая замена или адаптация компонен-

тов,

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

системы вообще стремятся скорее к закрытости, чем к открытости.

Необходимость измененрш в распределенных системах часто связана с тем,

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

зователя или приложения. Так, например, рассмотрим кэширование в World

Wide Web. Браузеры обычно позволяют пользователям адаптировать правила

кэширования под их нужды путем определения размера кэша, а также того, дол-

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

один раз за сеанс. Однако пользователь не может воздействовать на другие пара-

метры кэширования, такие как длительность сохранения документа в кэше или

очередность удаления документов из кэша при его переполнении. Также невоз-

можно создавать правила кэширования на основе

содержимого

документа. Так, на-

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

которые редко изменяются, но никогда

—

информацию о пробках на улицах города.

Нам необходимо отделить правила от механизма. В случае кэширования в Web,

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

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

ность решать, какие документы и насколько долго там хранить. На практике это

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

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

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

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

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

процедуры, содержащиеся в компонентах.

1.2.4.

Масштабируемость

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

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

32 Глава 1. Введение

рим, что масштабируемость

—

это одна из наиболее важных задач при проектиро-

вании распределенных систем.

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

лям

[314].

Во-первых, система может быть масштабируемой по отношению к ее

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

лей и ресурсов. Во-вторых, система может масштабироваться географически, то

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

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

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

организаций. К сожалению, система, обладающая масштабируемостью по одно-

му или нескольким из этих параметров, при масштабировании часто дает потерю

производительности.

Проблемы масштабируемости

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

нообразных проблем. Сначала рассмотрим масштабирование по размеру. Если

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

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

ных и алгоритмов (табл. 1.2). Так, например, многие службы централизуются по-

тому, что при их реализации предполагалось наличие в распределенной системе

только одного сервера, запущенного на конкретной машине. Проблемы такой

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

узким местом системы. Даже если мы обладаем фактически неограниченным за-

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

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

Таблица 1.2. Примеры ограничений масштабируемости

Концепция Пример

Централизованные службы Один сервер на всех пользователей

Централизованные данные Единый телефонный справочник, доступный

в режиме подключения

Централизованные алгоритмы Организация маршрутизации на основе полной

информации

К сожалению, Р1Спользование единственного сервера время от времени неиз-

бежно. Представьте себе службу управления особо конфиденциальной информа-

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

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

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

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

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

даже не обсуждается, поскольку это сделает службу менее стойкой к атакам зло-

умышленников.

Централизация данных так же вредна, как и централизация служб. Как вы

будете отслеживать телефонные номера и адреса 50 миллионов человек? Пред-

1.2. Задачи 33

положим, что каждая запись укладывается в 50 символов. Необходимой емко-

стью обладает один 2,5-гигабайтный диск. Но и в этом случае наличие единой

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

зи.

Так, представим себе, как работал бы Интернет, если бы служба доменных

имен (DNS) была бы реализована в виде одной таблицы. DNS обрабатывает ин-

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

обходимую для определения местоположения web-серверов. Если бы каждый за-

прос на интерпретацию URL передавался бы на этот единственный DNS-сервер,

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

мы придется решать снова).

И наконец, централизация алгоритмов

—

это тоже плохо. В больших распре-

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

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

получить полную информацию о загруженности всех машин и линий и по алго-

ритмам из теории графов вычислить все оптимальные маршруты. Эта информа-

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

Проблема состоит в том, что сбор и транспортргровка всей информации туда-

сюда

—

не слишком хорошая идея, поскольку сообщения, несущие эту информа-

цию,

могут перегрузить часть сети. Фактически следует избегать любого алго-

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

из ее машин для обработки с последующей раздачей результатов. Использовать

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

ют

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

ни одна из машин не обладает полной информацией о состоянии системы;

машины принимают решения на основе локальной информации;

-¥ сбой на одной машине не вызывает нарушения алгоритма;

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

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

вероятно, менее очевидно, но не менее важно. Любой алгоритм, начинающийся

со слов: «Ровно в 12:00:00 все машины должны определить размер своих вход-

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

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

синхронизации таймеров. Чем больше система, тем большим будет и рассогласо-

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

бы

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

лать это в масштабе страны или множества стран? Вы, должно быть, шутите.

У географической масштабируемости имеются свои сложности. Одна из ос-

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

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

жит принцип синхронной связи

(synchronous

communication).

В этом виде связи

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

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

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

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

34 Глава 1. Введение

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

то есть на три порядка дольше. Построение интерактивных приложений с ис-

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

рожности (и немалого терпения).

Другая проблема, препятствующая географическому масштабированию, со-

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

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

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

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

проще. Для примера рассмотрим проблему локализации службы. В локальной

сети система просто рассылает сообщение всем машинам, опрашивая их на пред-

мет предоставления нужной службы. Машины, предоставляющие службу, отве-

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

Невозможно представить себе подобную схему определения местоположения

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

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

и обеспечить их мощностью для обслуживания миллионов пользователей. Мы

вернемся к подобным службам в главе 4.

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

зованных решений, которые мешают масштабированию по размеру. Если у нас

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

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

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

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

грузку сети. Представьте себе, что в каждой стране существует всего одно

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

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

женный, возможно, в сотнях миль от вашего дома. Ясно, что это не тот путь, ко-

торым следует идти.

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

масштабирование распределенной системы на множество административно не-

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

стоит в конфликтах правил, относящихся к использованию ресурсов (и плате за

них),

управлению и безопасности.

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

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

сти.

В этом случае системный администратор может тестировать и сертифициро-

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

та, что эти компоненты не могут ничего натворить. Проще говоря, пользователи

доверяют своему системному администратору. Однако это доверие не распро-

страняется естественным образом за границы области.

Если распределенные системы распространяются на другую область, могут

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

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

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

1.2. Задачи 35

па к файловой службе системы в исходной области, скажем, только на чте1Н1е.

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

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

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

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

ется загрузка по сети программ, таких как апплеты в web-браузерах. Изнача/гьно

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

вает ему права доступа. Проблема, как мы увидим в главе 8, состоит в том, как

обеспечить соблюдение этих ограничений.

Технологии масштабирования

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

а как же обычно решаются эти проблемы. Поскольку проблемы масштабируемо-

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

ваются ограниченной мощностью серверов и сетей, существуют три основные

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

ние и репликация

[314].

Сокрытие времени ожидания связи применяется в случае географического

масштабирования. Основная идея проста: постараться по возможности избежать

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

шена служба удаленной машины, альтернативой ожиданию ответа от сервера бу-

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

В сущности, это означает разработку запрашивающего приложения в расчете на

использование исключительно асинхронной связи (asinch?vnous communication).

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

альный обработчик для завершения отправленного ранее запроса. Асинхронная

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

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

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

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

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

продолжат свое выполнение.

Однако многие приложения не в состоянии эффективно использовать асин-

хронную связь. Например, когда в интерактивном приложении пользователь по-

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

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

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

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

Стандартный случай применения этого подхода

—

доступ к базам данных с ис-

пользованием форм. Обычно заполнение формы сопровождается посылкой

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

сервера, как показано на рис. 1.2, а. Сервер, например, может перед приемом вве-

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

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

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

Глава 1. Введение

заполненную форму (рис. 1.2, б). Такой подход

—

перенос кода на клиента -

в настоящее время широко поддерживается в Web посредством Java-апплетов.

Клиент

Сервер

Имя

Фамилия

E-mail

MAARTEN 1

VAN STEEN ~]

STEEN@CS.VU.NL |

[Щ]

ш-

Ш-

Проверка формы Обработка формы

Клиент

Имя

Фамилия

E-mail

L MAARTEN 1

L VAN STEEN 1

|STEEN@CS.VU.NL |

—•

MAARTEN

VAN STEEN

STEEN@CS.VU.NL

Проверка формы

Сервер

Обработка формы

Рис. 1.2. Разница между проверкой формы по мере заполнения на сервере (а)

и на клиенте (б)

Следующая важная технология масштабирования

—

распределение (distribu-

tion).

РаспределенР1е предполагает разбиение компонентов на мелкие части и по-

следующее разнесение этих частей по системе. Хорошим примером распределе-

ния является система доменных имен Интернета (DNS). Пространство DNS-имен

органр1зовано иерархически, в виде дерева

доменов

{domains), которые разбиты

на неперекрывающиеся зоны

{zones),

как показано на рис. 1.3. Имена каждой зо-

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

можно считать, что каждое доменное имя является именем хоста в Интернете и

ассоциируется с сетевым адресом этого хоста. В основном интерпретация имени

означает получение сетевого адреса соответствующего хоста. Рассмотрим, к npii-

меру, имя nl.vu.cs.flits. Для интерпретации этого имени оно сначала передается на

сервер зоны Z1 (рис. 1.3), который возвращает адрес сервера зоны 12, который,

вероятно, сможет обработать остаток именрг, vu.cs.flits. Сервер зоны Z2 вернет адрес

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

нуть адрес соответствующего хоста.

Эти примеры демонстрируют, как

служба

именования,

предоставляемая DNS,

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

всех запросов на интерпретацию ршен одним сервером.

В качестве другого примера рассмотрим World Wide Web. Для большинства

пользователей Web представляется гигантской информационной системой доку-

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

—

URL.

1.2. Задачи 37

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

одном сервере. Однако среда Web физически разнесена по множеству серверов,

каждыр! из которых содержит некоторое количество документов. Имя сервера,

содержащего конкретный документ, определяется по URL-адресу документа.

Только благодаря подобному распределению документов Всемирная паутина

смогла вырасти до ее современных размеров.

Области деятельности

Страны

Рис. 1.3. Пример разделения пространства DNS-имен на зоны

При рассмотрении проблем масштабирования, часто проявляющихся в виде па-

дения производительности, нередко хорошей идеей является репликация {repli-

cation) компонентов распределенной системы. Репликация не только повышает

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

шению производительности. Кроме того, в сильно географически рассредоточен-

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

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

Кэширование {caching) представляет собой особую форму репликации, при-

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

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

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

сурс.

Однако в противоположность репликации кэширование

—

это действие,

предпринимаемое потребителем ресурса, а не его владельцем.

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

кэширования и репликации. Поскольку мы получаем множество копий ресурса,

модификация одной копии делает ее отличной от остальных. Соответственно,

кэширование и репликация вызывают проблемы

непротиворечивости

{consis-

tency).

Допустимая степень противоречивости зависит от степени загрузки ресурсов.

Так, множество пользователей Web считают допустимым работу с кэширован-

ным документом через несколько минут после его помещения в кэш без допол-

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

38 Глава 1. Введение

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

бирже. Проблема строгой непротиворечивости состоит в том, что изменение

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

того,

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

чтобы эти изменения вносились в одном и том же порядке во все копии. Для об-

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

низации. К сожалению, реализовать масштабирование подобных механизмов

крайне трудно, а может быть и невозможно. Это означает, что масштабирование

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

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

1.3. Концепции аппаратных решений

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

соров, существуют различные способы их организации в систему. В особенности

это относится к вариантам их соединения и организации взаимного обмена.

В этом разделе мы кратко рассмотрим аппаратное обеспечение распределенных

систем, в частности варианты соединения машин между собой. Предметом наше-

го обсуждения в следуюш.ем разделе будет программное обеспечение распреде-

ленных систем.

За прошедшие годы было предложено множество различных схем классифи-

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

стала действительно популярной и широко распространенной. Нас интересуют

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

рис.

1.4 мы подразделяем все компьютеры на две группы. Системы, в которых

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

сорами

{multiprocessors),

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

—

мультиком-

пьютерами (muldcomputers). Основная разница между ними состоит в том, что

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

мое всеми процессорами. Если один из процессоров записывает, например, зна-

чение 44 по адресу 1000, любой другой процессор, который после этого прочтет

значение, лежащее по адресу 1000, получит 44. Все машины задействуют одну

и ту же память.

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

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

по адресу 1000, другой процессор, прочитав значение, лежащее по адресу 1000,

получит то значение, которое хранилось там раньше. Запись по этому адресу

значения 44 другим процессором никак не скажется на содержимом его памяти.

Типичный пример мультикомпьютера

—

несколько персональных компьютеров,

объединенных в сеть.

Каждая из этих категорий может быть подразделена на дополнительные кате-

гории на основе архитектуры соединяющей их сети. На рис. 1.4 эти две архитек-

туры обозначены как шинная (bus) и

коммутируемая

(switched). Под шиной по-

нимается одиночная сеть, плата, шина, кабель или другая среда, соединяющая

1.3. Концепции аппаратных решений

все машины между собой. Подобную схему использует кабельное телевидение:

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

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

Разделяемая

память

"м!

^•^ п"^ П"^

JL X X JL

^ЙС

\Р IP [р [р

1ёг

Локальная память

м и

\ м

1 ^ ^

р р р

т т т

\ м

^^^

Процессор Память

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

распределенных компьютерных систем

Коммутируемые системы, в отличие от шинных, не имеют единой магистрали,

такой как у кабельного телевидения. Вместо нее от машины к машине тянутся

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

Сообщения передаются по каналам с принятием явного решения о коммутации

с конкретным выходным каналом для каждого из них. Так организована гло-

бальная телефонная сеть.

Мы проведем также разделение распределенных компьютерных систем на

гомогенные (homogeneous)

гетерогенные

(heterogeneous).

Это разделение приме-

няется исключительно к мультикомпьютерным системам. Для гомогенных муль-

тикомпьютерных систем характерна одна соединяющая компьютеры сеть, ис-

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

в основном имеют доступ к одинаковым объемам собственной памяти. Гомоген-

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

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

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

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

ми.

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

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

магистралью FDDI или ATM.

Глава 1. Введение

В следующих трех пунктах мы кратко рассмотрргм мультипроцессорные, а так-

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

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

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

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

1.3.1.

Мультипроцессоры

Мультипроцессорные системы обладают одной характерной особенностью: все

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

мы шинной архР1тектуры состоят из некоторого количества процессоров, подсо-

единенных к общей шине, а через нее

—

к модулям памяти. Простейшая конфигу-

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

процессоры и модули памяти.

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

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

цессор В получает информацию, записанную в память процессором А. Память,

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

согласованной

(coherent). Проблема

такой схемы состоит в том, что в случае уже 4 или 5 процессоров шина оказыва-

ется стабильно перегруженной и производительность резко падает. Решение со-

стоит в размещении между процессором и шиной высокоскоростной

кэш-памяти

(cache

memory),

как показано на рис. 1.5. В кэше сохраняются данные, обращение

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

кэш. Если запрошенные данные находятся в кэш-памяти, то на запрос процессо-

ра реагирует она и обращения к шине не выполняются. Если размер кэш-памяти

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

коэффициентом

кэш-

попаданий

(hit

rate),

велика и шинный трафик в расчете на один процессор резко

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

Общепринятыми являются размеры кэша от 512 Кбайт до 1 Мбайт, коэффици-

ент кэш-попаданий при этом обычно составляет 90 % и более.

Процессор

Кш 1

Процессор

Кош'

Память

Шина

Рис. 1.5. Мультипроцессорная система

с шинной архитектурой

Однако введение кэша создает серьезные проблемы само по себе. Предполо-

жим, что два процессора, Л и В, читают одно и то же слово в свой внутренний

кэш. Затем Л перезаписывает это слово. Когда процессор В в следующий раз за-

хочет воспользоваться этим словом, он считает старое значение из своего кэша,

а не новое значение, записанное процессором А. Память стала несогласованной,

и программирование системы осложнилось. Кэширование тем не менее активно