Файл: Tannenbaum.pdf

Ч/О Глава Ь. Уровень операционной системы

Операции над семафорами неделимы. Если операция над семафором уже нача-

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

Более того, при наличии семафоров сигналы пробуждения не пропадают. А вот

операторы if в листинге 6.1 делимы. Между проверкой условия и выполнением
нужного действия другой процесс может послать сигнал пробуждения.

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

мых системных прерываний

 up

 и

 down.

 Чтобы эти операции были неделимыми,

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

 up

 или

 down,

 ни один

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

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

ства процессов. Несколько процессов могут «спать», не завершив системный вы-
зов

 down

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

нит процедуру

 up

 на том же семафоре, один из ждущих процессов может завершить

вызов

 down

 и продолжить работу. Семафор сохраняет значение 0, и другие процес-

сы продолжают ждать.

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

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

только 7 мячей. В каждый момент в корзине находится от 0 до 7 мячей (семафор
принимает значение от 0 до 7). Помещение мяча в корзину — это операция

 up,

 по-

скольку она увеличивает значение семафора. Извлечение мяча из корзины — это
операция

 down,

 поскольку она уменьшает значение семафора.

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

Семерым из них удается получить мяч (завершить операцию

 down);

 оставшиеся

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

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

 up).

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

мяч (закончить незавершенную операцию

 down)

 и продолжить игру. Оставшиеся

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

 up),

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

Листинг 6.2.

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

public class m {

final public static int BUF_SIZE = 100. //буфер от 0 до 99

final public static long MAX_PRIME=100000000000L. //остановиться здесь

public static int in = 0. out = 0. //указатели на данные

public static long buffer[ ] = new long[BUF_SIZE]. //здесь хранятся простые числа

public static producer p //имя произво/щеля

public static consumer с //имя потребитшя

public static int filled = 0, available = 100. //семафоры

Примеры операционных систем

479

public static vend mainCStnng args[ ]) {

p = new producerO;

с = new consumerO;

p.startO:

с startO:

//основной клласс

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

//создание потребителя

//запуск производителя

//запуск потребителя

// Это утилита для циклического увеличения in и out
public static int nextdnt k) {if (k < BUF_SIZE - 1) return(k+l): else return(O).

class producer extends Thread {

native void updnt s); native void downdnt s);

public void run() {

long prime - 2;

while (prime < m.MAX_PRIME) {

prime = next_pnme(pnme):

downtm.available);

m buffer[m in] = prime;

m.in = m next(m.in);

up(m.filled);

//класс производителя

//процедуры над семафорами

//код производителя

//временная переменная

//шаг Р1

//шаг Р2

//шаг РЗ

//шаг Р4

//шаг Р5

private long next_pnme(long pnme){ ...}

//функция, которая выдает

следующее число

class consumer extends Thread {

native void updnt s); native void downdnt s);

public void runC) {

long emirp = 2,

while (emirp < m MAX_PRIME) {

down(m. filled),

emirp = m.buffer[m.out];

m.out = m next(m out);

up(m. available):

System.out.print!n(emirp);

//класс потребителя

//процедуры над семафорами

//код потребителя

//временная переменная

//шаг С1

//шаг С2

//шаг СЗ

//шаг С4

//шаг С5

Примеры операционных систем

В этом разделе мы продолжим обсуждать Pentium II и Ultra SPARC П. Мы рас-
смотрим операционные системы, которые используются на этих процессорах.

Для Pentium II мы возьмем Windows NT (для краткости мы будем называть

эту операционную систему NT); для UltraSPARC II — UNIX. Мы начнем наш раз-
говор с UNIX, поскольку эта система гораздо проще NT. Кроме того, операцион-

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

4 8 0 Глава 6. Уровень операционной системы

Введение

В этом разделе мы дадим краткий обзор двух операционных систем (UNIX и NT).
При этом мы обратим особое внимание на историю, структуру и системные вызовы.

UNIX

Операционная система UNIX была разработана в компании Bell Labs в начале

70-х годов. Первая версия была написана Кеном Томпсоном (Ken Thompson) на
ассемблере для мини-компьютера PDP-7. Затем была написана вторая версия
для компьютера PDP-11, уже на языке С. Ее автором был Деннис Ритчи (Dennis
Ritchie). В 1974 году Ритчи и Томпсон опубликовали очень важную работу о сис-

теме UNIX [120]. За эту работу они были награждены престижной премией
Тьюринга Ассоциации вычислительной техники (Ritchie, 1984; Thompson, 1984).

После публикации этой работы многие университеты попросили у Bell Labs ко-

пию UNIX. Поскольку материнская компания Bell Labs, AT&T была в тот момент
регулируемой монополией и ей не разрешалось принимать участие в компью-
терном бизнесе, университеты смогли приобрести операционную систему UNIX
за небольшую плату.

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

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

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

лифорнийский университет в Беркли. Поскольку имелась в наличии полная ис-
ходная программа, в Беркли сумели существенно преобразовать эту систему. Сре-
ди изменений было портирование этой системы на мини-компьютер VAX, создание
виртуальной памяти со страничной организацией, расширение имен файлов с 14
символов до 255, а также включение сетевого протокола TCP/IP, который сейчас
используется в Интернете (во многом благодря тому факту, что он был в системе

Berkeley UNIX).

Пока в Беркли производились все эти изменения, компания AT&T самостоя-

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

System III, а в 1984 — System V. В конце 80-х годов широко использовались две

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

(как было сделано с MS DOS). После долгих споров комиссия стандартов в Ин-
ституте инженеров по электротехнике и электронике выпустила стандарт

 POSIX

(Portable Operating System-IX — интерфейс переносной операционной системы

1

).

POSIX также известен как стандарт Р1003. Позднее он стал международным
стандартом.

1

 POSIX — Portable Operating System Interface for Computer Environments — платформенно-независи-

мый системный интерфейс. —

 Примеч. научн. ред.

Примеры операционных систем 481

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

отдельную область системы UNIX. Первая часть Р 1003.1 определяет системные
вызовы; вторая часть Р 1003.2 определяет основные обслуживающие программы
и т. д. Стандарт Р1003.1 определяет около 60 системных вызовов, которые должны
поддерживаться всеми соответствующими системами. Это вызовы для чтения и
записи файлов, создания новых процессов и т. д. Сейчас практически все системы
UNIX поддерживают системные вызовы Р 1003.1. Однако многие системы UNIX
поддерживают и дополнительные системные вызовы, в частности те, которые
определены в System V или в Berkeley UNIX. Обычно к набору POSIX добавляет-
ся до 100 системных вызовов. Операционная система для машины UltraSPARC II
основана на System V. Она называется

 Solaris.

 Она поддерживает и многие вызо-

вы из системы Berkeley.

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

ления файлами и директориями — это самые большие и самые важные категории.

Большинство из них относятся к стандарту Р 1003.1. Остальные происходят из сис-

темы System V.

Таблица 6.6. Системные вызовы UNIX

Категория Примеры

Управление файлами Открытие, чтение, запись, закрытие и блокировка файлов
Управление директориями Создание и удаление директорий; перемещение файлов

по директориям

Управление процессами Порождение, завершение, отслеживание процессов

и передача сигналов

Управление памятью Разделение общей памяти между процессами; защита страниц
Вызов/установка параметров Идентификация пользователя, группы, процесса; установка

приоритетов

Даты и периоды времени Указание на время доступа к файлам; использование датчика

временных интервалов; рабочий профиль программы

Работа в сети Установка/принятие соединения; отправка/получение

сообщения

Прочее Учет использования ресурсов; ограничение на доступный

объем памяти; перезагрузка системы

Сфера использования сетей в большей степени относится к Berkeley UNIX, а не

к System V. В Беркли было введено понятие сокет (конечный пункт сетевой свя-
зи). Четырехпроводные стенные розетки, к которым можно подсоединять телефо-
ны, послужили в качестве модели этого понятия. Процесс в системе UNIX может
создать сокет, присоединиться к нему и установить связь с сокетом на удаленном
компьютере. По этой связи можно пересылать данные в обоих направлениях, обыч-
но с использованием протокола TCP/IP. Поскольку технология сетевой связи деся-
тилетиями применялась в системе UNIX, значительное число серверов в Интер-
нете используют именно UNIX.

Существует много разных вариантов системы UNIX, и каждая из них чем-то

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

4 8 2 Глава 6. Уровень операционной системы

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

названием

 поток

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

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

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

исходит обратный процесс.

Пользовательский

режим

Привилегированный

режим

Оболочка

Пользовательская

программа

Интерфейс системных вызовов

Система файлов

Кэш блоков

Драйверы устройств

Управление процессами

Межпроцессорная

связь

Планирование

Сигналы

Управление

памятью

Аппаратное обеспечение

Рис. 6.24. Структура типичной системы UNIX

Над драйверами устройств находится система управления файлами. Она управ-

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

кэш блоков

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

понадобятся еще раз. Некоторые системы файлов использовались на протяжении
многих лет. Среди них можно назвать быструю файловую систему Berkeley [95] и
журналирующие файловые системы [121].

Еще одна часть ядра системы UNIX — структура управления процессами. Она

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