THE DESIGN OF THE UNIX §12-13

THE DESIGN OF THE UNIX § 1-3

THE DESIGN OF THE UNIX § 4-5

THE DESIGN OF THE UNIX § 6-7

THE DESIGN OF THE UNIX § 8-9

THE DESIGN OF THE UNIX §10-11

ГЛАВА 12. МНОГОПРОЦЕССОРНЫЕ СИСТЕМЫ

В классической постановке для системы UNIX предполагается использование однопроцессорной архитектуры, состоящей из одного ЦП, памяти и периферийных устройств. Многопроцессорная архитектура, напротив, включает в себя два и более ЦП, совместно использующих общую память и периферийные устройства (Рисунок 12.1), располагая большими возможностями в увеличении производительности системы, связанными с одновременным исполнением процессов на разных ЦП. Каждый ЦП функционирует независимо от других, но все они работают с одним и тем же ядром операционной системы. Поведение процессов в такой системе ничем не отличается от поведения в однопроцессорной системе — с сохранением семантики обращения к каждой системной функции — но при этом они могут открыто перемещаться с одного процессора на другой. Хотя, к сожалению, это не приводит к снижению затрат процессорного времени, связанного с выполнением процесса. Отдельные многопроцессорные системы называются системами с присоединенными процессорами, поскольку в них периферийные устройства доступны не для всех процессоров. За исключением особо оговоренных случаев, в настоящей главе не проводится никаких различий между системами с присоединенными процессорами и остальными классами многопроцессорных систем.

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

Блокировки такого рода охватывают некоторые критические участки, но не работают в многопроцессорных системах, что видно из Рисунка 12.5. Предположим, что блокировка снята и что два процесса на разных процессорах одновременно пытаются проверить ее наличие и установить ее. В момент t они обнаруживают снятие блокировки, устанавливают ее вновь, вступают в критический участок и создают опасность нарушения целостности структур данных ядра. В условии одновременности имеется отклонение: механизм не сработает, если перед тем, как процесс выполняет операцию проверки, ни один другой процесс не выполнил операцию установления блокировки. Если, например, после обнаружения снятия блокировки процессор А обрабатывает прерывание и в этот момент процессор В выполняет проверку и устанавливает блокировку, по выходе из прерывания процессор А так же установит блокировку. Чтобы предотвратить возникновение подобной ситуации, нужно сделать так, чтобы процедура блокирования была неделимой: проверку наличия блокировки и ее установку следует объединить в одну операцию, чтобы в каждый момент времени с блокировкой имел дело только один процесс.

12.3.1 Определение семафоров

Семафор представляет собой обрабатываемый ядром целочисленный объект, для которого определены следующие элементарные (неделимые) операции:

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

  • Операция типа Р, уменьшающая значение семафора. Если значение семафора опускается ниже нулевой отметки, выполняющий операцию процесс приостанавливает свою работу;

  • Операция типа V, увеличивающая значение семафора. Если значение семафора в результате операции становится больше или равно 0, один из процессов, приостановленных во время выполнения операции Р, выходит из состояния приостанова;

  • Условная операция типа Р, сокращенно CP (conditional Р), уменьшающая значение семафора и возвращающая логическое значение "истина" в том случае, когда значение семафора остается положительным. Если в результате операции значение семафора должно стать отрицательным или нулевым, никаких действий над ним не производится и операция возвращает логическое значение "ложь".

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

12.3.2 Реализация семафоров

Дийкстра [Dijkstra 65] показал, что семафоры можно реализовать без использования специальных машинных инструкций. На Рисунке 12.6 представлены реализующие семафоры функции, написанные на языке Си. Функция Pprim блокирует семафор по результатам проверки значений, содержащихся в массиве val; каждый процессор в системе управляет значением одного элемента массива. Прежде чем заблокировать семафор, процессор проверяет, не заблокирован ли уже семафор другими процессорами (соответствующие им элементы в массиве val тогда имеют значения, равные 2), а также не предпринимаются ли попытки в данный момент заблокировать семафор со стороны процессоров с более низким кодом идентификации (соответствующие им элементы имеют значения, равные 1). Если любое из условий выполняется, процессор переустанавливает значение своего элемента в 1 и повторяет попытку. Когда функция Pprim открывает внешний цикл, переменная цикла имеет значение, на единицу превышающее код идентификации того процессора, который использовал ресурс последним, тем самым гарантируется, что ни один из процессоров не может монопольно завладеть ресурсом (в качестве доказательства сошлемся на [Dijkstra 65] и [Coffman 73]). Функция Vprim освобождает семафор и открывает для других процессоров возможность получения исключительного доступа к ресурсу путем очистки соответствующего текущему процессору элемента в массиве val и перенастройки значения lastid. Чтобы защитить ресурс, следует выполнить следующий набор команд:

Pprim(семафор);

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

Vprim(семафор);

В большинстве машин имеется набор элементарных (неделимых) инструкций, реализующих операцию блокирования более дешевыми средствами, ибо циклы, входящие в функцию Pprim, работают медленно и снижают производительность системы. Так, например, в машинах серии IBM 370 поддерживается инструкция compare and swap (сравнить и переставить), в машине AT&T ЗВ20 — инструкция read and clear (прочитать и очистить). При выполнении инструкции read and clear процессор считывает содержимое ячейки памяти, очищает ее (сбрасывает в Ø) и по результатам сравнения первоначального содержимого с Ø устанавливает код завершения инструкции. Если ту же инструкцию над той же ячейкой параллельно выполняет еще один процессор, один из двух процессоров прочитает первоначальное содержимое, а другой — Ø: неделимость операции гарантируется аппаратным путем. Таким образом, за счет использования данной инструкции функцию Pprim можно было бы реализовать менее сложными средствами (Рисунок 12.7). Процесс повторяет инструкцию read and clear в цикле до тех пор, пока не будет считано значение, отличное от нуля. Начальное значение компоненты семафора, связанной с блокировкой, должно быть равно 1.

Как таковую, данную семафорную конструкцию нельзя реализовать в составе ядра операционной системы, поскольку работающий с ней процесс не выходит из цикла, пока не достигнет своей цели. Если семафор используется для блокирования структуры данных, процесс, обнаружив семафор заблокированным, приостанавливает свое выполнение, чтобы ядро имело возможность переключиться на контекст другого процесса и выполнить другую полезную работу. С помощью функций Pprim и Vprimможно реализовать более сложный набор семафорных операций, соответствующий тому составу, который определен в разделе 12.3.1.

struct semaphore {

int val[NUMPROCS]; /* замок 1 элемент на каждый процессор */

int lastid; /* идентификатор процессора, получившего семафор последним */

} ;

int procid; /* уникальный идентификатор процессора */

int lastid; /* идентификатор процессора, получившего семафор последним */

INIT(semaphore)

struct semaphore semaphore;

{

int i;

for (i = 0; i < NUMPROCS; i++) semaphore.val[i] = 0;

}

Pprim(semaphore)

struct semaphore semaphore;

{

int i, first; loop :

first = lastid;

semaphore.val[procid] = 1; forloop:

for (i = first; i < NUMPROCS; i++) {

if (i == procid) { semaphore.val[i] = 2;

for (i = 1; i < NUMPROCS; i + +) if (i != procid && semaphore. val [ i ] == 2) goto loop;

lastid = procid;

return; /* успешное завершение, ресурс можно использовать */

}

else if (semaphore.val[i]) goto loop;

}

first = 1; goto forloop;

}

Vprim(semaphore)

struct semaphore semaphore;

{

lastid = (procid + 1) % NUMPROCS;

/* на следующий процессор */ semaphore.val[procid] = 0;

}

Рисунок 12.6. Реализация семафорной блокировки на Си

Для начала дадим определение семафора как структуры, состоящей из поля блокировки (управляющего доступом к семафору), значения семафора и очереди процессов, приостановленных по семафору. Поле блокировки содержит информацию, открывающую во время выполнения операций типа Р и V доступ к другим полям структуры только одному процессу По завершении операции значение поля сбрасывается. Это значение определяет, разрешен ли процессу доступ к критическому участку, защищаемому семафором. В начале выполнения алгоритма операции Р (Рисунок 12.8) ядро с помощью функции Pprimпредоставляет процессу право исключительного доступа к семафору и уменьшает значение семафора. Если семафор имеет неотрицательное значение, текущий процесс получает доступ к критическому участку. По завершении работы процесс сбрасывает блокировку семафора (с помощью функции Vprim), открывая доступ к семафору для других процессов, и возвращает признак успешного завершения. Если же в результате уменьшения значение семафора становится отрицательным, ядро приостанавливает выполнение процесса, используя алгоритм, подобный алгоритму sleep (глава 6): основываясь на значении приоритета, ядро проверяет поступившие сигналы, включает текущий процесс в список приостановленных процессов, в котором последние представлены в порядке поступления, и выполняет переключение контекста. Операция V (Рисунок 12.9) получает исключительный доступ к семафору через функцию Pprim и увеличивает значение семафора. Если очередь приостановленных по семафору процессов не пуста, ядро выбирает из нее первый процесс и переводит его в состояние "готовности к запуску".

Операции Р и V по своему действию похожи на функции sleep и wakeup. Главное различие между ними состоит в том, что семафор является структурой данных, тогда как используемый функциями sleep и wakeup адрес представляет собой всего лишь число. Если начальное значение семафора — нулевое, при выполнении операции Р над семафором процесс всегда приостанавливается, поэтому операция Р может заменять функцию sleep. Операция V, тем не менее, выводит из состояния приостанова только один процесс, тогда как однопроцессорная функция wakeup возобновляет все процессы, приостановленные по адресу, связанному с событием.

С точки зрения семантики использование функции wakeup означает: данное системное условие более не удовлетворяется, следовательно, все приостановленные по условию процессы должны выйти из состояния приостанова. Так, например, процессы, приостановленные в связи с занятостью буфера, не должны дальше пребывать в этом состоянии, если буфер больше не используется, поэтому они возобновляются ядром. Еще один пример: если несколько процессов выводят данные на терминал с помощью функции write, терминальный драйвер может перевести их в состояние приостанова в связи с невозможностью обработки больших объемов информации. Позже, когда драйвер будет готов к приему следующей порции данных, он возобновит все приостановленные им процессы. Использование операций Р и V в тех случаях, когда устанавливающие блокировку процессы получают доступ к ресурсу поочередно, а все остальные процессы — в порядке поступления запросов, является более предпочтительным. В сравнении с однопроцессорной процедурой блокирования (sleep-lock) данная схема обычно выигрывает, так как если при наступлении события все процессы возобновляются, большинство из них может вновь наткнуться на блокировку и снова перейти в состояние приостанова. С другой стороны, в тех случаях, когда требуется вывести из состояния приостанова все процессы одновременно, использование операций Р и V представляет известную сложность.

struct semaphore {

int lock;

} ;

Init(semaphore)

struct semaphore semaphore;

{

semaphore.lock = 1;

}

Pprim(semaphore)

struct semaphore semaphore;

{

while (read_and_clear(semaphore.lock));

}

Vprim(semaphore)

struct semaphore semaphore;

{

semaphore.lock = 1;

}

Рисунок 12.7. Операции над семафором, использующие инструкцию read_and_clear

Если операция возвращает значение семафора, является ли она эквивалентной функции wakeup?

while (value(semaphore) < 0) V(semaphore);

Если вмешательства со стороны других процессов нет, ядро повторяет цикл до тех пор, пока значение семафора не станет больше или равно Ø, ибо это означает, что в состоянии приостанова по семафору нет больше ни одного процесса. Тем не менее, нельзя исключить и такую возможность, что сразу после того, как процесс А при тестировании семафора на одноименном процессоре обнаружил нулевое значение семафора, процесс В на своем процессоре выполняет операцию Р, уменьшая значение семафора до -1 (Рисунок 12.10). Процесс А продолжит свое выполнение, думая, что им возобновлены все приостановленные по семафору процессы. Таким образом, цикл выполнения операции не дает гарантии возобновления всех приостановленных процессов, поскольку он не является элементарным.

алгоритм Р /* операция над семафором типа Р */ входная информация:

• 1. семафор

  2. приоритет выходная информация:

0—в случае нормального завершения

-1 — в случае аварийного выхода из состояния приостанова по сигналу, принятому в режиме ядра {

Pprim(semaphore.lock); уменьшить (semaphore.value); if (semaphore.value >= 0) {

Vprim(semaphore.lock); return ( 0) ;

}

/* следует перейти в состояние приостанова */ if (проверяются сигналы) {

if (имеется сигнал, прерывающий нахождение в состоянии приостанова) { увеличить (semaphore.value); if (сигнал принят в режиме ядра) {

Vprim(semaphore.lock); return (-1) ;

}

else {

Vprim(semaphore.lock); longj mp;

поставить процесс в конец списка приостановленных по семафору;

Vprim(semaphore.lock); выполнить переключение контекста; проверить сигналы (см. выше); return(0);

}

Рисунок 12.8. Алгоритм выполнения операции Р

Рассмотрим еще один феномен, связанный с использованием семафоров в однопроцессорной системе. Предположим, что два процесса, А и В, конкурируют за семафор. Процесс А обнаруживает, что семафор свободен и что процесс В приостановлен; значение семафора равно -1. Когда с помощью операции V процесс А освобождает семафор, он выводит тем самым процесс В из состояния приостанова и вновь делает значение семафора нулевым. Теперь предположим, что процесс А, по-прежнему выполняясь в режиме ядра, пытается снова заблокировать семафор. Производя операцию Р, процесс приостановится, поскольку семафор имеет нулевое значение, несмотря на то, что ресурс пока свободен. Системе придется "раскошелиться" на дополнительное переключение контекста. С другой стороны, если бы блокировка была реализована на основе однопроцессорной схемы (sleep-lock), процесс А получил бы право на повторное использование ресурса, поскольку за это время ни один из процессов не смог бы заблокировать его. Для этого случая схема sleep-lock более подходит, чем схема с использованием семафоров.

алгоритм V /* операция над семафором типа V */ входная информация: адрес семафора выходная информация: отсутствует

{

Pprim(semaphore.lock); увеличить (semaphore.value); if (semaphore.value <= 0) {

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

перевести его в состояние готовности к запуску;

}

Vprim(semaphore.lock);

Рисунок 12.9. Алгоритм выполнения операции V

Когда блокируются сразу несколько семафоров, очередность блокирования должна исключать возникновение тупиковых ситуаций. В качестве примера рассмотрим два семафора, А и В, и два алгоритма, требующих одновременной блокировки семафоров. Если бы алгоритмы устанавливали блокировку на семафоры в обратном порядке, как следует из Рисунка 12.11, последовало бы возникновение тупиковой ситуации; процесс А на одноименном процессоре захватывает семафор SA, в то время как процесс В на своем процессоре захватывает семафор SB. Процесс А пытается захватить и семафор SB, но в результате операции Р переходит в состояние приостанова, поскольку значение семафора SB не превышает Ø. То же самое происходит с процессом В, когда последний пытается захватить семафор SA. Ни тот, ни другой процессы продолжаться уже не могут.

Для предотвращения возникновения подобных ситуаций используются соответствующие алгоритмы обнаружения опасности взаимной блокировки, устанавливающие наличие опасной ситуации и ликвидирующие ее. Тем не менее, использование таких алгоритмов "утяжеляет" ядро. Поскольку число ситуаций, в которых процесс должен одновременно захватывать несколько семафоров, довольно ограничено, легче было бы реализовать алгоритмы, предупреждающие возникновение тупиковых ситуаций еще до того, как они будут иметь место. Если, к примеру, какой-то набор семафоров всегда блокируется в одном и том же порядке, тупиковая ситуация никогда не возникнет. Но в том случае, когда захвата семафоров в обратном порядке избежать не удается, операция СР предотвратит возникновение тупиковой ситуации (см. Рисунок 12.12): если операция завершится неудачно, процесс В освободит свои ресурсы, дабы избежать взаимной блокировки, и позже запустит алгоритм на выполнение повторно, скорее всего тогда, когда процесс А завершит работу с ресурсом.

Чтобы предупредить одновременное обращение процессов к ресурсу, программа обработки прерываний, казалось бы, могла воспользоваться семафором, но из-за того, что она не может приостанавливать свою работу (см. главу 6), использовать операцию Р в этой программе нельзя. Вместо этого можно использовать "циклическую блокировку" (spin lock) и не переходить в состояние приостанова, как в следующем примере:

Рисунок 12.10. Неудачное имитация функции wakeup при использовании операции V

Рисунок 12.11. Возникновение тупиковой ситуации из-за смены очередности блокирования

Рисунок 12.12. Использование операции Р условного типа для предотвращения взаимной блокировки

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

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

Рисунок 12.13. Взаимная блокировка при выполнении программы обработки прерывания

12.3.3 Примеры алгоритмов

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

12.3.3.1 Выделение буфера

Обратимся еще раз к алгоритму getblk, рассмотренному нами в главе 3. Алгоритм работает с тремя структурами данных: заголовком буфера, хеш-очередью буферов и списком свободных буферов. Ядро связывает семафор со всеми экземплярами каждой структуры. Другими словами, если у ядра имеются в распоряжении 200 буферов, заголовок каждого из них включает в себя семафор, используемый для захвата буфера; когда процесс выполняет над семафором операцию Р, другие процессы, тоже пожелавшие захватить буфер, приостанавливаются до тех пор, пока первый процесс не исполнит операцию V У каждой хеш-очереди буферов также имеется семафор, блокирующий доступ к очереди. В однопроцессорной системе блокировка хеш- очереди не нужна, ибо процесс никогда не переходит в состояние приостанова, оставляя очередь в несогласованном (неупорядоченном) виде. В многопроцессорной системе, тем не менее, возможны ситуации, когда с одной и той же хеш-очередью работают два процесса; в каждый момент времени семафор открывает доступ к очереди только для одного процесса. По тем же причинам и список свободных буферов нуждается в семафоре для защиты содержащейся в нем информации от искажения.

алгоритм getblk /* многопроцессорная версия */ входная информация: номер файловой системы номер блока

выходная информация: захваченный буфер, предназначенный для обработки

содержимого блока

{

do while(буфер не будет обнаружен) {

Р(семафор хеш-очереди);

if (блок находится в хеш-очереди) {

if (операция СР(семафор буфера) завершается неудачно) { /* буфер занят */

V(семафор хеш-очереди);

Р(семафор буфера); /* приостанов до момента освобождения */

if (операция СР(семафор хеш-очереди) завершается неудачно) {

V(семафор буфера);

continue; /* выход в цикл "выполнять" */

}

else if (номер устройства или номер блока изменились) {

V(семафор буфера);

V(семафор хеш-очереди);

}

}

do while(операция СР (семафор списка свободных буферов) не завершится

успешно);

/* "кольцевой цикл" */ пометить буфер занятым;

убрать буфер из списка свободных буферов;

V(семафор списка свободных буферов);

V(семафор хеш-очереди); return буфер;

}

else

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

Рисунок 12.14. Выделение буфера с использованием семафоров

На Рисунке 12.14 показана первая часть алгоритма getblk, реализованная в многопроцессорной системе с использованием семафоров. Просматривая буферный кеш в поисках указанного блока, ядро с помощью операции Р захватывает семафор, принадлежащий хеш-очереди. Если над семафором уже кем-то произведена операция данного типа, текущий процесс приостанавливается до тех пор, пока процесс, захвативший семафор, не освободит его, выполнив операцию V Когда текущий процесс получает право исключительного контроля над хеш-очередью, он приступает к поиску подходящего буфера. Предположим, что буфер находится в хеш-очереди. Ядро (процесс А) пытается захватить буфер, но если оно использует операцию Р и если буфер уже захвачен, ядру придется приостановить свою работу, оставив хеш-очередь заблокированной и не допуская таким образом обращений к ней со стороны других процессов, даже если последние ведут поиск незахваченных буферов. Пусть вместо этого процесс А захватывает буфер, используя операцию СР; если операция завершается успешно, буфер становится открытым для процесса. Процесс А захватывает семафор, принадлежащий списку свободных буферов, выполняя операцию СР, поскольку семафор захватывается на непродолжительное время и, следовательно, приостанавливать свою работу, выполняя операцию Р, процесс просто не имеет возможности. Ядро убирает буфер из списка свободных буферов, снимает блокировку со списка и с хеш-очереди и возвращает захваченный буфер. Предположим, что операция СР над буфером завершилась неудачно из-за того, что семафор, принадлежащий буферу, оказался захваченным. Процесс А освобождает семафор, связанный с хеш-очередью, и приостанавливается, пытаясь выполнить операцию Р над семафором буфера. Операция Р над семафором будет выполняться, несмотря на то, что операция СР уже потерпела неудачу. По завершении выполнения операции процесс А получает власть над буфером. Так как в оставшейся части алгоритма предполагается, что буфер и хеш-очередь захвачены, процесс А теперь пытается захватить хеш-очередь. Поскольку очередность захвата здесь (сначала семафор буфера, потом семафор очереди) обратна вышеуказанной очередности, над семафором выполняется операция СР. Если попытка захвата заканчивается неудачей, имеет место обычная обработка, требующаяся по ходу задачи. Но если захват удается, ядро не может быть уверено в том, что захвачен корректный буфер, поскольку содержимое буфера могло быть ранее изменено другим процессом, обнаружившим буфер в списке свободных буферов и захватившим на время его семафор. Процесс А, ожидая освобождения семафора, не имеет ни малейшего представления о том, является ли интересующий его буфер тем буфером, который ему нужен, и поэтому прежде всего он должен убедиться в правильности содержимого буфера; если проверка дает отрицательный результат, алгоритм запускается сначала. Если содержимое буфера корректно, процесс А завершает выполнение алгоритма. Оставшуюся часть алгоритма можно рассмотреть в качестве упражнения.

12.3.3.2 Wait

многопроцессорная версия алгоритма wait {

для (;;) { / * цикл */

перебор всех процессов-потомков:

if (потомок находится в состоянии "прекращения существования") return; Р(zombie_semaphore); /* начальное значение — 0 */

Рисунок 12.15. Многопроцессорная версия алгоритма wait

Из главы 7 мы уже знаем о том, что во время выполнения системной функции wait процесс приостанавливает свою работу до момента завершения выполнения своего потомка. В многопроцессорной системе перед процессом встает задача не упустить при выполнении алгоритма wait потомка, прекратившего существование с помощью функции exit; если, например, в то время, пока на одном процессоре процесс-родитель запускает функцию wait, на другом процессоре его потомок завершил свою работу, родителю нет необходимости приостанавливать свое выполнение в ожидании завершения второго потомка. В каждой записи таблицы процессов имеется семафор, именуемый zombie_semaphore и имеющий в начале нулевое значение. Этот семафор используется при организации взаимодействия wait/exit (Рисунок 12.15). Когда потомок завершает работу, он выполняет над семафором своего родителя операцию V выводя родителя из состояния приостанова, если тот перешел в него во время исполнения функции wait. Если потомок завершился раньше, чем родитель запустил функцию wait, этот факт будет обнаружен родителем, который тут же выйдет из состояния ожидания. Если оба процесса исполняют функции exit и wait параллельно, но потомок исполняет функцию exit уже после того, как родитель проверил его статус, операция V выполненная потомком, воспрепятствует переходу родителя в состояние приостанова. В худшем случае процесс-родитель просто повторяет цикл лишний раз.

12.3.3.3 Драйверы

В многопроцессорной реализации вычислительной системы на базе компьютеров AT&T ЗВ20 семафоры в структуру загрузочного кода драйверов не включаются, а операции типа Р и V выполняются в точках входа в каждый драйвер (см. [Bach 84]). В главе 10 мы говорили о том, что интерфейс, реализуемый драйверами устройств, характеризуется очень небольшим числом точек входа (на практике их около 20). Защита драйверов осуществляется на уровне точек входа в них:

Р(семафор драйвера);

открыть (драйвер);

V(семафор драйвера);

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

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

12.3.3.4 Фиктивные процессы

Когда ядро выполняет переключение контекста в однопроцессорной системе, оно функционирует в контексте процесса, уступающего управление (см. главу 6). Если в системе нет процессов, готовых к запуску, ядро переходит в состояние простоя в контексте процесса, выполнявшегося последним. Получив прерывание от таймера или других периферийных устройств, оно обрабатывает его в контексте того же процесса.

В многопроцессорной системе ядро не может простаивать в контексте процесса, выполнявшегося последним. Посмотрим, что произойдет после того, как процесс, приостановивший свою работу на процессоре А, выйдет из состояния приостанова. Процесс в целом готов к запуску, но он запускается не сразу же по выходе из состояния приостанова, даже несмотря на то, что его контекст уже находится в распоряжении процессора А. Если этот процесс выбирается для запуска процессором В, последний переключается на его контекст и возобновляет его выполнение. Когда в результате прерывания процессор А выйдет из простоя, он будет продолжать свою работу в контексте процесса А до тех пор, пока не произведет переключение контекста. Таким образом, в течение короткого промежутка времени с одним и тем же адресным пространством (в частности, со стеком ядра) будут вести работу (и, что весьма вероятно, производить запись) сразу два процессора.

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

12.4 СИСТЕМА TUNIS

Пользовательский интерфейс системы Tunis совместим с аналогичным интерфейсом системы UNIX, но ядро этой системы, разработанное на языке Concurrent Euclid, состоит из процессов, управляющих каждой частью системы. Проблема взаимного исключения решается в системе Tunis довольно просто, так как в каждый момент времени исполняется не более одной копии управляемого ядром процесса, кроме того, процессы работают только с теми структурами данных, которые им принадлежат. Системные процессы активизируются запросами на ввод, защиту очереди запросов осуществляет процедура программного монитора. Эта процедура усиливает взаимное исключение, разрешая доступ к своей исполняемой части в каждый момент времени не более, чем одному процессу. Механизм монитора отличается от механизма семафоров тем, что, во-первых, благодаря последним усиливается модульность программ (операции Р и V присутствуют на входе в процедуру монитора и на выходе из нее), а во-вторых, сгенерированный компилятором код уже содержит элементы синхронизации. Холт отмечает, что разработка таких систем облегчается, если используется язык, поддерживающий мониторы и включающий понятие параллелизма (см. [Holt 83], стр.190). При всем при этом внутренняя структура системы Tunis отличается от традиционной реализации системы UNIX радикальным образом.

12.5 УЗКИЕ МЕСТА В ФУНКЦИОНИРОВАНИИ МНОГОПРОЦЕССОРНЫХ СИСТЕМ

В данной главе нами были рассмотрены два метода реализации многопроцессорных версий системы UNIX: конфигурация, состоящая из главного и подчиненного процессоров, в которой только один процессор (главный) функционирует в режиме ядра, и метод, основанный на использовании семафоров и допускающий одновременное исполнение в режиме ядра всех имеющихся в системе процессов. Оба метода инвариантны к количеству процессоров, однако говорить о том, что с ростом числа процессоров общая производительность системы увеличивается с линейной скоростью, нельзя. Потери производительности возникают, во- первых, как следствие конкуренции за ресурсы памяти, которая выражается в увеличении продолжительности обращения к памяти. Во-вторых, в схеме, основанной на использовании семафоров, к этой конкуренции добавляется соперничество за семафоры; процессы зачастую обнаруживают семафоры захваченными, больше процессов находится в очереди, долгое время ожидая получения доступа к семафорам. Первая схема, основанная на использовании главного и подчиненного процессоров, тоже не лишена недостатков: по мере увеличения числа процессоров главный процессор становится узким местом в системе, поскольку только он один может функционировать в режиме ядра. Несмотря на то, что более внимательное техническое проектирование позволяет сократить конкуренцию до разумного минимума и в некоторых случаях приблизить скорость повышения производительности системы при увеличении числа процессоров к линейной (см., например, [Beck 85]), все построенные с использованием современной технологии многопроцессорные системы имеют предел, за которым расширение состава процессоров не сопровождается увеличением производительности системы.

12.5 УПРАЖНЕНИЯ

• 1. Решите проблему функционирования многопроцессорных систем таким образом, чтобы все процессоры в системе могли функционировать в режиме ядра, но не более одного одновременно. Такое решение будет отличаться от первой из предложенных в тексте схем, где только один процессор (главный) предназначен для реализации функций ядра. Как добиться того, чтобы в режиме ядра в каждый момент времени находился только один процессор? Какую стратегию обработки прерываний при этом можно считать приемлемой?

  2. Используя системные функции работы с разделяемой областью памяти, протестируйте программу, реализующую семафорную блокировку (Рисунок 12.6). Последовательности операций P-V над семафором могут независимо один от другого выполнять несколько процессов. Каким образом в программе следует реализовать индикацию и обработку ошибок?

  3. Разработайте алгоритм выполнения операции СР (условный тип операции Р), используя текст алгоритма операции Р.

  4. Объясните, зачем в алгоритмах операций Р и V (Рисунки 12.8 и 12.9) нужна блокировка прерываний. В какие моменты ее следует осуществлять?

  5. Почему при выполнении "циклической блокировки" вместо строки:

while (! СР(семафор));

ядро не может использовать операцию Р безусловного типа? (В качестве наводящего вопроса: что произойдет в том случае, если процесс запустит операцию Р и приостановится?)

• 1. Обратимся к алгоритму getblk, приведенному в главе 3. Опишите реализацию алгоритма в многопроцессорной системе для случая, когда блок отсутствует в буферном кеше.

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

*8. Предположим, что у терминального драйвера имеется семафор, значение которого при инициализации сбрасывается в 0 и по которому процессы приостанавливают свою работу в случае переполнения буфера вывода на терминал. Когда терминал готов к приему следующей порции данных, он выводит из состояния ожидания все процессы, приостановленные по семафору. Разработайте схему возобновления процессов, использующую операции типа Р и V В случае необходимости введите дополнительные флаги и семафоры. Как должна вести себя схема в том случае, если процессы выводятся из состояния ожидания по прерыванию, но при этом текущий процессор не имеет возможности блокировать прерывания на других процессорах?

*9. Если точки входа в драйвер защищаются семафорами, должно соблюдаться условие освобождения семафора в случае перехода процесса в состояние приостанова. Как это реализуется на практике? Каким образом должна производиться обработка прерываний, поступающих в то время, пока семафор драйвера заблокирован?

10. Обратимся к системным функциям установки и контроля системного времени (глава 8). Разные процессоры могут иметь различную тактовую частоту. Как в этом случае указанные функции должны работать?

ГЛАВА 13. РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ

В предыдущей главе нами были рассмотрены сильносвязанные многопроцессорные системы с общей памятью, общими структурами данных ядра и общим пулом, из которого процессы вызываются на выполнение. Часто, однако, бывает желательно в целях обеспечения совместного использования ресурсов распределять процессоры таким образом, чтобы они были автономны от операционной среды и условий эксплуатации. Пусть, например, пользователю персональной ЭВМ нужно обратиться к файлам, находящимся на более крупной машине, но сохранить при этом контроль над персональной ЭВМ. Несмотря на то, что отдельные программы, такие как шср, поддерживают передачу файлов по сети и другие сетевые функции, их использование не будет скрыто от пользователя, поскольку пользователь знает о том, что он работает в сети. Кроме того, надо заметить, что программы, подобные текстовым редакторам, с удаленными файлами, как с обычными, не работают. Пользователи должны располагать стандартным набором функций системы UNIX и, за исключением возможной потери в быстродействии, не должны ощущать пересечения машинных границ. Так, например, работа системных функций open и read с файлами на удаленных машинах не должна отличаться от их работы с файлами, принадлежащими локальным системам.

Архитектура распределенной системы представлена на Рисунке 13.1. Каждый компьютер, показанный на рисунке, является автономным модулем, состоящим из ЦП, памяти и периферийных устройств. Соответствие модели не нарушается даже несмотря на то, что компьютер не располагает локальной файловой системой: он должен иметь периферийные устройства для связи с другими машинами, а все принадлежащие ему файлы могут располагаться и на ином компьютере. Физическая память, доступная каждой машине, не зависит от процессов, выполняемых на других машинах. Этой особенностью распределенные системы отличаются от сильносвязанных многопроцессорных систем, рассмотренных в предыдущей главе. Соответственно, и ядро системы на каждой машине функционирует независимо от внешних условий эксплуатации распределенной среды.

Рисунок 13.1. Модель системы с распределенной архитектурой

Распределенные системы, хорошо описанные в литературе, традиционно делятся на следующие категории:

• периферийные системы, представляющие собой группы машин, отличающихся ярковыраженной общностью и связанных с одной (обычно более крупной) машиной. Периферийные процессоры делят свою нагрузку с центральным процессором и переадресовывают ему все обращения к операционной системе. Цель периферийной системы состоит в увеличении общей производительности сети и в предоставлении возможности выделения процессора одному процессу в операционной среде UNIX. Система запускается как отдельный модуль; в отличие от других моделей распределенных систем, периферийные системы не обладают реальной автономией, за исключением случаев, связанных с диспетчеризацией процессов и распределением локальной памяти.

  • распределенные системы типа "Newcastle", позволяющие осуществлять дистанционную связь по именам удаленных файлов в библиотеке (название взято из статьи "The Newcastle Connection" — см. [Brownbridge 82]). Удаленные файлы имеют спецификацию (составное имя), которая в указании пути поиска содержит специальные символы или дополнительную компоненту имени, предшествующую корню файловой системы. Реализация этого метода не предполагает внесения изменений в ядро системы, вследствие этого он более прост, чем другие методы, рассматриваемые в этой главе, но менее гибок.

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

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

13.1 ПЕРИФЕРИЙНЫЕ ПРОЦЕССОРЫ

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

При инициализации системы на центральном процессоре ядро по линиям связи загружает на каждом из периферийных процессоров локальную операционную систему. Любой выполняемый на периферии процесс связан с процессом-спутником, принадлежащим центральному процессору (см. [Birrell 84]); когда процесс, протекающий на периферийном процессоре, вызывает системную функцию, которая нуждается в услугах исключительно центрального процессора, периферийный процесс связывается со своим спутником и запрос поступает на обработку на центральный процессор. Процесс-спутник исполняет системную функцию и посылает результаты обратно на периферийный процессор. Взаимоотношения периферийного процесса со своим спутником похожи на отношения клиента и сервера, подробно рассмотренные нами в главе 11: периферийный процесс выступает клиентом своего спутника, поддерживающего функции работы с файловой системой. При этом удаленный процесс-сервер имеет только одного клиента. В разделе 13.4 мы рассмотрим процессы-серверы, имеющие несколько клиентов.

Рисунок 13.2. Конфигурация периферийной системы

Рисунок 13.3. Форматы сообщений

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

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

Для того, чтобы объяснить, каким образом работает периферийная система, рассмотрим ряд функций: getppid, open, write, fork, exit и signal. Функция getppid довольно проста, поскольку она связана с простыми формами запроса и ответа, которыми обмениваются периферийный и центральный процессоры. Ядро на периферийном процессоре формирует сообщение, имеющее признак, из которого следует, что запрашиваемой функцией является функция getppid, и посылает запрос центральному процессору. Процесс-спутник на центральном процессоре читает сообщение с периферийного процессора, расшифровывает тип системной функции, исполняет ее и получает идентификатор своего родителя. Затем он формирует ответ и передает его периферийному процессу, находящемуся в состоянии ожидания на другом конце линии связи. Когда периферийный процессор получает ответ, он передает его процессу, вызвавшему системную функцию getppid. Если же периферийный процесс хранит данные (такие, как идентификатор процесса-родителя) в локальной памяти, ему вообще не придется связываться со своим спутником.

Если производится обращение к системной функции open, периферийный процесс посылает своему спутнику соответствующее сообщение, которое включает имя файла и другие параметры. В случае успеха процесс-спутник выделяет индекс и точку входа в таблицу файлов, отводит запись в таблице пользовательских дескрипторов файла в своем пространстве и возвращает дескриптор файла периферийному процессу. Все это время на другом конце линии связи периферийный процесс ждет ответа. У него в распоряжении нет никаких структур, которые хранили бы информацию об открываемом файле; возвращаемый функцией open дескриптор представляет собой указатель на запись в таблице пользовательских дескрипторов файла, принадлежащей процессу-спутнику. Результаты выполнения функции показаны на Рисунке 13.4.

Рисунок 13.4. Вызов функции open из периферийного процесса

Если производится обращение к системной функции write, периферийный процессор формирует сообщение, состоящее из признака функции write, дескриптора файла и объема записываемых данных. Затем из пространства периферийного процесса он по линии связи копирует данные процессу-спутнику. Процесс-спутник расшифровывает полученное сообщение, читает данные из линии связи и записывает их в соответствующий файл (в качестве указателя на индекс которого и запись о котором в таблице файлов используется содержащийся в сообщении дескриптор); все указанные действия выполняются на центральном процессоре. По окончании работы процесс-спутник передает периферийному процессу посылку, подтверждающую прием сообщения и содержащую количество байт данных, успешно переписанных в файл. Операция read выполняется аналогично; спутник информирует периферийный процесс о количестве реально прочитанных байт (в случае чтения данных с терминала или из канала это количество не всегда совпадает с количеством, указанным в запросе). Для выполнения как той, так и другой функции может потребоваться многократная пересылка информационных сообщений по сети, что определяется объемом пересылаемых данных и размерами сетевых пакетов.

Единственной функцией, требующей внесения изменений при работе на центральном процессоре, является системная функция fork. Когда процесс исполняет эту функцию на ЦП, ядро выбирает для него периферийный процессор и посылает сообщение специальному процессу — серверу, информируя последний о том, что собирается приступить к выгрузке текущего процесса. Предполагая, что сервер принял запрос, ядро с помощью функции fork создает новый периферийный процесс, выделяя запись в таблице процессов и адресное пространство. Центральный процессор выгружает копию процесса, вызвавшего функцию fork, на периферийный процессор, затирая только что выделенное адресное пространство, порождает локальный спутник для связи с новым периферийным процессом и посылает на периферию сообщение о необходимости инициализации счетчика команд для нового процесса. Процесс- спутник (на ЦП) является потомком процесса, вызвавшего функцию fork; периферийный процесс с технической точки зрения выступает потомком процесса-сервера, но по логике он является потомком процесса, вызвавшего функцию fork. Процесс-сервер не имеет логической связи с потомком по завершении функции fork; единственная задача сервера состоит в оказании помощи при выгрузке потомка. Из-за сильной связи между компонентами системы (периферийные процессоры не располагают автономией) периферийный процесс и процесс- спутник имеют один и тот же код идентификации. Взаимосвязь между процессами показана на Рисунке 13.5: непрерывной линией показана связь типа "родитель-потомок", пунктиром — связь между равноправными партнерами.

Рисунок 13.5. Выполнение функции fork на центральном процессоре

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

Рисунок 13.6. Выполнение функции fork на периферийном процессоре

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

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

алгоритм sighandle /* алгоритм обработки сигналов */ входная информация: отсутствует

выходная информация: отсутствует

{

if (текущий процесс является чьим-то спутником или имеет прототипа) { if (сигнал игнорируется) return;

if (сигнал поступил во время выполнения системной функции) поставить сигнал перед процессом-спутником; else послать сообщение о сигнале периферийному процессу;

}

else { /* периферийный процесс */

/* поступил ли сигнал во время выполнения системной функции или нет */ послать сигнал процессу-спутнику;

алгоритм satellite end of syscall /* завершение системной функции, вызванной периферийным процессом */

входная информация: отсутствует

выходная информация: отсутствует

{

if (во время выполнения системной функции поступило прерывание) послать периферийному процессу сообщение о прерывании, сигнал; else /* выполнение системной функции не прерывалось */ послать ответ: включить флаг, показывающий поступление сигнала;

}

Рисунок 13.7. Обработка сигналов в периферийной системе

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

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

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

  3. Если по получении сигнала процесс-спутник прерывает выполнение системной функции (по longjmp), он информирует об этом периферийный процесс и сообщает ему номер сигнала.

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

Рисунок 13.8. Прерывание во время выполнения системной функции

Предположим, например, что периферийный процесс вызывает функцию чтения с терминала, связанного с центральным процессором, и приостанавливает свою работу на время выполнения функции процессом-спутником (Рисунок 13.8). Если пользователь нажимает клавишу прерывания (break), ядро ЦП посылает процессу-спутнику соответствующий сигнал. Если спутник находился в состоянии приостанова в ожидании ввода с терминала порции данных, он немедленно выходит из этого состояния и прекращает выполнение функции read. В своем ответе на запрос периферийного процесса спутник сообщает код ошибки и номер сигнала, соответствующий прерыванию. Периферийный процесс анализирует ответ и, поскольку в сообщении говорится о поступлении сигнала прерывания, отправляет сигнал самому себе. Перед выходом из функции read периферийное ядро осуществляет проверку поступления сигналов, обнаруживает сигнал прерывания, поступивший от процесса-спутника, и обрабатывает его обычным порядком. Если в результате получения сигнала прерывания периферийный процесс завершает свою работу с помощью функции exit, данная функция берет на себя заботу об уничтожении процесса-спутника. Если периферийный процесс перехватывает сигналы о прерывании, он вызывает пользовательскую функцию обработки сигналов и по выходе из функции read возвращает пользователю код ошибки. С другой стороны, если спутник исполняет от имени периферийного процесса системную функцию stat, он не будет прерывать ее выполнение при получении сигнала (функции stat гарантирован выход из любого приостанова, поскольку для нее время ожидания ресурса ограничено). Спутник доводит выполнение функции до конца и возвращает периферийному процессу номер сигнала. Периферийный процесс посылает сигнал самому себе и получает его на выходе из системной функции.

Если сигнал возник на периферийном процессоре во время выполнения системной функции, периферийный процесс будет находиться в неведении относительно того, вернется ли к нему вскоре управление от процесса-спутника или же последний перейдет в состояние приостанова на неопределенное время. Периферийный процесс посылает спутнику специальное сообщение, информируя его о возникновении сигнала. Ядро на ЦП расшифровывает сообщение и посылает сигнал спутнику, реакция которого на получение сигнала описана в предыдущих параграфах (аварийное завершение выполнения функции или доведение его до конца). Периферийный процесс не может послать сообщение спутнику непосредственно, поскольку спутник занят исполнением системной функции и не считывает данные из линии связи.

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

Рассмотрим, наконец, случай поступления сигнала во время, не связанное с выполнением системной функции. Если сигнал возник на другом процессоре, спутник получает его первым и посылает сообщение о сигнале периферийному процессу, независимо от того, касается ли этот сигнал периферийного процесса или нет. Периферийное ядро расшифровывает сообщение и посылает сигнал процессу, который реагирует на него обычным порядком. Если сигнал возник на периферийном процессоре, процесс выполняет стандартные действия, не прибегая к услугам своего спутника.

Когда периферийный процесс посылает сигнал другим периферийным процессам, он кодирует сообщение о вызове функции kill и посылает его процессу-спутнику, который исполняет вызываемую функцию локально. Если часть процессов, для которых предназначен сигнал, имеет местонахождение на других периферийных процессорах, сигнал получат (и прореагируют на его получение вышеописанным образом) их спутники.

13.2 СВЯЗЬ ТИПА NEWCASTLE

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

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

"sftig!/fsl/mjb/rje"

идентифицирует файл "/fsl/mjb/rje", находящийся на машине "sftig". Такая схема идентифицирования файла соответствует соглашению, установленному программой шср относительно передачи файлов между системами типа UNIX. В другой схеме удаленные файлы идентифицируются добавлением к имени специального префикса, например:

/. ./sftig/fs 1/mjb/rjе

где "/../" — префикс, свидетельствующий о том, что файл удаленный; вторая компонента имени файла является именем удаленной машины. В данной схеме используется привычный синтаксис имен файлов в системе UNIX, поэтому в отличие от первой схемы здесь пользовательским программам нет необходимости приноравливаться к использованию имен, имеющих необычную конструкцию (см. [Pike 85]).

Рисунок 13.9. Формулирование запросов к файловому серверу (процессору)

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

open("../sftig/fsl/mjb/rje/file", O_RDONLY);

Подпрограмма open из Си-библиотеки анализирует первые две компоненты составного имени файла и узнает, что файл следует искать на удаленной машине "sftig". Чтобы иметь информацию о том, была ли ранее у процесса связь с данной машиной, подпрограмма заводит специальную структуру, в которой запоминает этот факт, и в случае отрицательного ответа устанавливает связь с файловым сервером, работающим на удаленной машине. Когда процесс формулирует свой первый запрос на дистанционную обработку, удаленный сервер подтверждает запрос, в случае необходимости ведет запись в поля пользовательского и группового кодов идентификации и создает процесc-спутник, который будет выступать от имени процесса-клиента.

Чтобы выполнять запросы клиента, спутник должен иметь на удаленной машине те же права доступа к файлам, что и клиент. Другими словами, пользователь "mjb" должен иметь и к удаленным, и к локальным файлам одинаковые права доступа. К сожалению, не исключена возможность того, что код идентификации клиента "mjb" может совпасть с кодом идентификации другого клиента удаленной машины. Таким образом, администраторам систем на работающих в сети машинах следует либо следить за назначением каждому пользователю кода идентификации, уникального для всей сети, либо в момент формулирования запроса на сетевое обслуживание выполнять преобразование кодов. Если это не будет сделано, процесс-спутник будет иметь на удаленной машине права другого клиента.

Более деликатным вопросом является получение в отношении работы с удаленными файлами прав суперпользователя. С одной стороны, клиент-суперпользователь не должен иметь те же права в отношении удаленной системы, чтобы не вводить в заблуждение средства защиты удаленной системы. С другой стороны, некоторые из программ, если им не предоставить права суперпользователя, просто не смогут работать. Примером такой программы является программа mkdir (см. главу 7), создающая новый каталог. Удаленная система не разрешила бы клиенту создавать новый каталог, поскольку на удалении права суперпользователя не действуют. Проблема создания удаленных каталогов служит серьезным основанием для пересмотра системной функции mkdir в сторону расширения ее возможностей в автоматическом установлении всех необходимых пользователю связей. Тем не менее, получение setuid - программами (к которым относится и программа mkdir) прав суперпользователя по отношению к удаленным файлам все еще остается общей проблемой, требующей своего решения. Возможно, что наилучшим решением этой проблемы было бы установление для файлов дополнительных характеристик, описывающих доступ к ним со стороны удаленных суперпользователей; к сожалению, это потребовало бы внесения изменений в структуру дискового индекса (в части добавления новых полей) и породило бы слишком большой беспорядок в существующих системах.

Если подпрограмма open завершается успешно, локальная библиотека оставляет об этом соответствующую отметку в доступной для пользователя структуре, содержащей адрес сетевого узла, идентификатор процесса-спутника, дескриптор файла и другую аналогичную информацию. Библиотечные подпрограммы read и write устанавливают, исходя из дескриптора, является ли файл удаленным, и в случае положительного ответа посылают спутнику сообщение. Процесс-клиент взаимодействует со своим спутником во всех случаях обращения к системным функциям, нуждающимся в услугах удаленной машины. Если процесс обращается к двум файлам, расположенным на одной и той же удаленной машине, он пользуется одним спутником, но если файлы расположены на разных машинах, используются уже два спутника: по одному на каждой машине. Два спутника используются и в том случае, когда к файлу на удаленной машине обращаются два процесса. Вызывая системную функцию через спутника, процесс формирует сообщение, включающее в себя номер функции, имя пути поиска и другую необходимую информацию, аналогичную той, которая входит в структуру сообщения в системе с периферийными процессорами.

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

Когда процесс вызывает функцию fork, соответствующая библиотечная подпрограмма посылает сообщения каждому спутнику. Процессы — спутники выполняют операцию ветвления и посылают идентификаторы своих потомков клиенту-родителю. Процесс-клиент запускает системную функцию fork, которая передает управление порождаемому потомку; локальный потомок ведет диалог с удаленным потомком-спутником, адреса которого сохранила библиотечная подпрограмма. Такая трактовка функции fork облегчает процессам-спутникам контроль над открытыми файлами и текущими каталогами. Когда процесс, работающий с удаленными файлами, завершается (вызывая функцию exit), подпрограмма посылает сообщения всем его удаленным спутникам, чтобы они по получении сообщения проделали то же самое. Отдельные моменты реализации системных функций ехес и exit затрагиваются в упражнениях.

Преимущество связи типа Newcastle состоит в том, что обращение процесса к удаленным файлам становится "прозрачным" (незаметным для пользователя), при этом в ядро системы никаких изменений вносить не нужно. Однако, данной разработке присущ и ряд недостатков. Прежде всего, при ее реализации возможно снижение производительности системы. В связи с использованием расширенной Си-библиотеки размер используемой каждым процессом памяти увеличивается, даже если процесс не обращается к удаленным файлам; библиотека дублирует функции ядра и требует для себя больше места в памяти. Увеличение размера процессов приводит к удлинению продолжительности периода запуска и может вызвать большую конкуренцию за ресурсы памяти, создавая условия для более частой выгрузки и подкачки задач. Локальные запросы будут исполняться медленнее из-за увеличения продолжительности каждого обращения к ядру, замедление может грозить и обработке удаленных запросов, затраты по пересылке которых по сети увеличиваются. Дополнительная обработка удаленных запросов на пользовательском уровне увеличивает количество переключений контекста, операций по выгрузке и подкачке процессов. Наконец, для того, чтобы обращаться к удаленным файлам, программы должны быть перекомпилированы с использованием новых библиотек; старые программы и поставленные объектные модули без этого работать с удаленными файлами не смогут. Все эти недостатки отсутствуют в системе, описываемой в следующем разделе.

13.3 "ПРОЗРАЧНЫЕ" РАСПРЕДЕЛЕННЫЕ ФАЙЛОВЫЕ СИСТЕМЫ

Термин "прозрачное распределение" означает, что пользователи, работающие на одной машине, могут обращаться к файлам, находящимся на другой машине, не осознавая того, что тем самым они пересекают машинные границы, подобно тому, как на своей машине они при переходе от одной файловой системе к другой пересекают точки монтирования. Имена, по которым процессы обращаются к файлам, находящимся на удаленных машинах, похожи на имена локальных файлов: отличительные символы в них отсутствуют. В конфигурации, показанной на Рисунке 13.10, каталог "/usr/src", принадлежащий машине В, "вмонтирован" в каталог "/usr/src", принадлежащий машине А. Такая конфигурация представляется удобной в том случае, если в разных системах предполагается использовать один и тот же исходный код системы, традиционно находящийся в каталоге "/usr/src". Пользователи, работающие на машине А, могут обращаться к файлам, расположенным на машине В, используя привычный синтаксис написания имен файлов (например: "/usr/src/cmd/login.c"), и ядро уже само решает вопрос, является файл удаленным или же локальным. Пользователи, работающие на машине В, имеют доступ к своим локальным файлам (не подозревая о том, что к этим же файлам могут обращаться и пользователи машины А), но, в свою очередь, не имеют доступа к файлам, находящимся на машине А. Конечно, возможны и другие варианты, в частности, такие, в которых все удаленные системы монтируются в корне локальной системы, благодаря чему пользователи получают доступ ко всем файлам во всех системах.

Рисунок 13.10. Файловые системы после удаленного монтирования

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

Интересная проблема связана с именами путей, включающих Если процесс делает текущим каталог из удаленной файловой системы, последующее использование в имени символов ".." скорее вернет процесс в локальную файловую систему, чем позволит обращаться к файлам, расположенным выше текущего каталога. Возвращаясь вновь к Рисунку 13.10, отметим, что когда процесс, принадлежащий машине А, выбрав предварительно в качестве текущего каталог "/usr/src/cmd", расположенный в удаленной файловой системе, исполнит команду

cd ../ ../ ..

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

Связь с удаленной машиной принимает одну из двух форм: вызов удаленной процедуры или вызов удаленной системной функции. В первой форме каждая процедура ядра, имеющая дело с индексами, проверяет, указывает ли индекс на удаленный файл, и если это так, посылает на удаленную машину запрос на выполнение указанной операции. Данная схема естественным образом вписывается в абстрактную структуру поддержки файловых систем различных типов, описанную в заключительной части главы 5. Таким образом, обращение к удаленному файлу может инициировать пересылку по сети нескольких сообщений, количество которых определяется количеством подразумеваемых операций над файлом, с соответствующим увеличением времени ответа на запрос с учетом принятого в сети времени ожидания. Каждый набор удаленных операций включает в себя, по крайней мере, действия по блокированию индекса, подсчету ссылок и т. и. В целях усовершенствования модели предлагались различные оптимизационные решения, связанные с объединением нескольких операций в один запрос (сообщение) и с буферизацией наиболее важных данных (см. [Sandberg 85]).

Рисунок 13.11. Открытие удаленного файла

Рассмотрим процесс, который открывает удаленный файл "/usr/src/cmd/login.c", где "src" — точка монтирования. Выполняя синтаксический разбор имени файла (по схеме namei-iget), ядро обнаруживает, что файл удаленный, и посылает на машину, где он находится, запрос на получение заблокированного индекса. Получив желаемый ответ, локальное ядро создает в памяти копию индекса, корреспондирующую с удаленным файлом. Затем ядро производит проверку наличия необходимых прав доступа к файлу (на чтение, например), послав на удаленную машину еще одно сообщение. Выполнение алгоритма open продолжается в полном соответствии с планом, приведенным в главе 5, с посылкой сообщений на удаленную машину по мере необходимости, до полного окончания алгоритма и освобождения индекса. Взаимосвязь между структурами данных ядра по завершении алгоритма open показана на Рисунке 13.11.

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

При второй форме связи с удаленной машиной (вызов удаленной системной функции) локальное ядро обнаруживает, что системная функция имеет отношение к удаленному файлу, и посылает указанные в ее вызове параметры на удаленную систему, которая исполняет функцию и возвращает результаты клиенту. Машина клиента получает результаты выполнения функции и выходит из состояния вызова. Большинство системных функций может быть выполнено с использованием только одного сетевого запроса с получением ответа через достаточно приемлемое время, но в такую модель вписываются не все функции. Так, например, по получении некоторых сигналов ядро создает для процесса файл с именем "core" (глава 7). Создание этого файла не связано с конкретной системной функцией, а завершает выполнение нескольких операций, таких как создание файла, проверка прав доступа и выполнение ряда операций записи.

В случае с системной функцией open запрос на исполнение функции, посылаемый на удаленную машину, включает в себя часть имени файла, оставшуюся после исключения компонент имени пути поиска, отличающих удаленный файл, а также различные флаги. В рассмотренном ранее примере с открытием файла "usr/src/cmd/login.c" ядро посылает на удаленную машину имя "cmd/login.c". Сообщение также включает в себя опознавательные данные, такие как пользовательский и групповой коды идентификации, необходимые для проверки прав доступа к файлам на удаленной машине. Если с удаленной машины поступает ответ, свидетельствующий об успешном выполнении функции open, локальное ядро выбирает свободный индекс в памяти локальной машины и помечает его как индекс удаленного файла, сохраняет информацию об удаленной машине и удаленном индексе и по заведенному порядку выделяет новую запись в таблице файлов. В сравнении с реальным индексом на удаленной машине индекс, принадлежащий локальной машине, является формальным, не нарушающим конфигурацию модели, которая в целом совпадает с конфигурацией, используемой при вызове удаленной процедуры (Рисунок 13.11). Если вызываемая процессом функция обращается к удаленному файлу по его дескриптору, локальное ядро узнает из индекса (локального) о том, что файл удаленный, формулирует запрос, включающий в себя вызываемую функцию, и посылает его на удаленную машину. В запросе содержится указатель на удаленный индекс, по которому процесс-спутник сможет идентифицировать сам удаленный файл.

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

13.4 РАСПРЕДЕЛЕННАЯ МОДЕЛЬ БЕЗ ПЕРЕДАТОЧНЫХ ПРОЦЕССОВ

Использование передаточных процессов (процессов-спутников) в "прозрачной" распределенной системе облегчает слежение за удаленными файлами, однако при этом таблица процессов удаленной системы перегружается процессами-спутниками, бездействующими большую часть времени. В других схемах для обработки удаленных запросов используются специальные процессы-серверы (см. [Sandberg 85] и [Cole 85]). Удаленная система располагает набором (пулом) процессов-серверов, время от времени назначаемых ею для обработки поступающих удаленных запросов. После обработки запроса процесс-сервер возвращается в пул и переходит в состояние готовности к выполнению обработки других запросов. Сервер не сохраняет пользовательский контекст между двумя обращениями, ибо он может обрабатывать запросы сразу нескольких процессов. Следовательно, каждое поступающее от процесса-клиента сообщение должно включать в себя информацию о среде его выполнения, а именно: коды идентификации пользователя, текущий каталог, сигналы и т. д. Процессы-спутники получают эти данные в момент своего появления или во время выполнения системной функции.

Когда процесс открывает удаленный файл, ядро удаленной системы назначает индекс для последующих ссылок на файл. Локальная машина располагает таблицей пользовательских дескрипторов файла, таблицей файлов и таблицей индексов с обычным набором записей, причем запись в таблице индексов идентифицирует удаленную машину и удаленный индекс. В тех случаях, когда системная функция (например, read) использует дескриптор файла, ядро посылает сообщение, указывающее на ранее назначенный удаленный индекс, и передает связанную с процессом информацию: код идентификации пользователя, максимальнодопустимый размер файла и т. п. Если удаленная машина имеет в своем распоряжении процесс-сервер, взаимодействие с клиентом принимает вид, описанный ранее, однако связь между клиентом и сервером устанавливается только на время выполнения системной функции.

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

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

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

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

Рисунок 13.12. Концептуальная схема взаимодействия с удаленными файлами на уровне ядра

13.5 ВЫВОДЫ

В данной главе нами были рассмотрены три схемы работы с расположенными на удаленных машинах файлами, трактующие удаленные файловые системы как расширение локальной. Архитектурные различия между этими схемами показаны на Рисунке 13.12. Все они в свою очередь отличаются от многопроцессорных систем, описанных в предыдущей главе, тем, что здесь процессоры не используют физическую память совместно. Система с периферийными процессорами состоит из сильносвязанного набора процессоров, совместно использующих файловые ресурсы центрального процессора. Связь типа Newcastle обеспечивает скрытый ("прозрачный") доступ к удаленным файлам, но не средствами ядра операционной системы, а благодаря использованию специальной Си-библиотеки. По этой причине все программы, предполагающие использовать связь данного типа, должны быть перекомпилированы, что в общем-то является серьезным недостатком этой схемы. Удаленность файла обозначается с помощью специальной последовательности символов, описывающих машину, на которой расположен файл, и это является еще одним фактором, ограничивающим мобильность программ.

В "прозрачных" распределенных системах для доступа к удаленным файлам используется модификация системной функции mount. Индексы в локальной системе содержат отметку о том, что они относятся к удаленным файлам, и локальное ядро посылает на удаленную систему сообщение, описывающее запрашиваемую системную функцию, ее параметры и удаленный индекс. Связь в "прозрачной" распределенной системе поддерживается в двух формах: в форме вызова удаленной процедуры (на удаленную машину посылается сообщение, содержащее перечень операций, связанных с индексом) и в форме вызова удаленной системной функции (сообщение описывает запрашиваемую функцию). В заключительной части главы рассмотрены вопросы, имеющие отношение к обработке дистанционных запросов с помощью процессов- спутников и серверов.

*1. Опишите реализацию системной функции exit в системе с периферийными процессорами. В чем разница между этим случаем и тем, когда процесс завершает свою работу по получении неперехваченного сигнала? Каким образом ядру следует сохранить дамп содержимого памяти?

2. Процессы не могут игнорировать сигналы типа SIGKILL; объясните, что происходит в периферийной системе, когда процесс получает такой сигнал.

*3. Опишите реализацию системной функции ехес в системе с периферийными процессорами.

*4. Каким образом центральному процессору следует производить распределение процессов между периферийными процессорами с тем, чтобы сбалансировать общую нагрузку?

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

• 1. Рассмотрим систему, в которой запросы к удаленному файловому серверу посылаются в случае обнаружения в имени файла специального префикса. Пусть процесс вызывает функцию execl("/../sftig/bin/sh", "sh", 0); Исполняемый модуль находится на удаленной машине, но должен выполняться в локальной системе. Объясните, каким образом удаленный модуль переносится в локальную систему.

  2. Если администратору нужно добавить в существующую систему со связью типа Newcastle новые машины, то как об этом лучше всего проинформировать модули Си-библиотеки?

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

*9. Как показано в разделе 13.2, вызов системной функции exit в системах со связью типа Newcastle приводит к посылке сообщения процессу-спутнику, заставляющего последний завершить свою работу. Это делается на уровне библиотечных подпрограмм. Что происходит, когда локальный процесс получает сигнал, побуждающий его завершить свою работу в режиме ядра?

*10. Каким образом в системе со связью типа Newcastle, где удаленные файлы идентифицируются добавлением к имени специального префикса, пользователь может, указав в качестве компоненты имени файла (родительский каталог), пересечь удаленную точку монтирования?

11. Из главы 7 нам известно о том, что различные сигналы побуждают процесс сбрасывать дамп содержимого памяти в текущий каталог. Что должно произойти в том случае, если текущим является каталог из удаленной файловой системы? Какой ответ вы дадите в том случае, если в системе используется связь типа Newcastle?

*12. Какие последствия для локальных процессов имело бы удаление из системы всех процессов-спутников или серверов?

*13. Подумайте над тем, как в "прозрачной" распределенной системе следует реализовать алгоритм link, параметрами которого могут быть два имени удаленных файлов, а также алгоритм ехес, связанный с выполнением нескольких внутренних операций чтения. Рассмотрите две формы связи: вызов удаленной процедуры и вызов удаленной системной функции.

*14. При обращении к устройству процесс-сервер может перейти в состояние приостанова, из которого он будет выведен драйвером устройства. Естественно, если число серверов ограничено, система не сможет больше удовлетворять запросы локальной машины. Придумайте надежную схему, по которой в ожидании завершения ввода-вывода, связанного с устройством, приостанавливались бы не все процессы-серверы. Системная функция не прекратит свое выполнение, пока все серверы будут заняты.

Рисунок 13.13. Конфигурация с терминальным сервером

*15. Когда пользователь регистрируется в системе, дисциплина терминальной линии сохраняет информацию о том, что терминал является операторским, ведущим группу процессов. По этой причине, когда пользователь на клавиатуре терминала нажимает клавишу "break", сигнал прерывания получают все процессы группы. Рассмотрим конфигурацию системы, в которой все терминалы физически подключаются к одной машине, но регистрация пользователей логически реализуется на других машинах (Рисунок 13.13). В каждом отдельном случае система создает для удаленного терминала getty-процесс. Если запросы к удаленной системе обрабатываются с помощью набора процессов-серверов, следует отметить, что при выполнении процедуры открытия сервер останавливается в ожидании подключения. Когда выполнение функции open завершается, сервер возвращается обратно в серверный пул, разрывая свою связь с терминалом. Каким образом осуществляется рассылка сигнала о прерывании, вызываемого нажатием клавиши "break", по адресам процессов, входящих в одну группу?

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

*17. Рассмотренные в главе 9 алгоритмы выгрузки процессов и подкачки страниц по обращению предполагают использование локального устройства выгрузки. Какие изменения следует внести в эти алгоритмы для того, чтобы создать возможность поддержки удаленных устройств выгрузки?

*18. Предположим, что на удаленной машине (или в сети) случился фатальный сбой и локальный протокол сетевого уровня зафиксировал этот факт. Разработайте схему восстановления локальной системы, обращающейся к удаленному серверу с запросами. Кроме того, разработайте схему восстановления серверной системы, утратившей связь с клиентами.

*19. Когда процесс обращается к удаленному файлу, не исключена возможность того, что в поисках файла процесс обойдет несколько машин. В качестве примера возьмем имя "/usr/src/uts/3b2/os", где "/шг" — каталог, принадлежащий машине A, "/usr/src" — точка монтирования корня машины В, "/usr/src/uts/3b2" — точка монтирования корня машины С. Проход через несколько машин к месту конечного назначения называется "мультискачком" (multihop). Однако, если между машинами А и С существует непосредственная сетевая связь, пересылка данных через машину В была бы неэффективной. Опишите особенности реализации "мультискачка" в системе со связью Newcastle и в "прозрачной" распределенной системе.