ОПЕРАЦИОННЬIЕ СИСТЕМЬI
Внутренняя структура и принципы
проектирования
ОПЕРАЦИОННЫЕ
СИСТЕМЫ
Внутренняя
структура и принципы
проектирования
9-е издание
OPERATING
SYSTEMS
lnternals and Design
Princip1es
Ninth Edition
William Stallings
0Pearson
ОПЕРАЦИОННЫЕ
СИСТЕМЬI
Внутренняя
структура и принципы
проектирования
9-е издание
Вильям Столлингс
Москва • Санкт-Петербург
2020
ББК
32.973.26-018.2.75
УДК
004.451
С81
ООО "Диалектика"
Зав. редакцией С. Н. Тригуб
!lеревод с английского И.В. Берштейна, канд. техн. наук И.В. Красикова
Под редакцией канд. техн. наук И.В. Красикова
По общим вопросам обращайтесь в издательство "Диалектика" по адресу:
iп fo@dialektika.com,
http://www.dialektika.com
Столлингс, Вильям.
С81
Операционные системы: внутренняя структура и принципы проектирования, 9-е
изд.
: Пер.
с англ.
-
СПб.
: ООО
ISBN 978-5-907203-08-2
"Диалектика",
2020. -
1264 с. : ил. -
Парал. тит. англ.
(рус.)
ББК
32.973.26-018.2.75
Все на1вания 11рограммных продуюuв являются заре1·истрированными rорговыми марками соответс
твующих фирм.
Никакая час'IЬ наС1uящего и1дания ни в каких целях не может быть вос11роизведена в какой бы
1. Обзор компьютерной системы
Глава 2. Обзор операционных систем
Часть 11. Процессы
Глава 3. Описание процессов и управление ими
Глава 4. Потоки
Глава 5. Параллельные вычисления: взаимоисключения и многозадачность
Глава 6. Параллельные вычисления: взаимоблокировка и голодание
Часть 111. Память
Глава 7. Управление памятью
Глава 8. Виртуальная память
Глава
11. Управление вводом-выводом
12. Управление файлами
и планирование дисковых операций
Часть У\. Дополнительные темы
13. Встроенные операционные системы
14. Виртуальные машины
Глава 15. Безопасность операционных систем
Глава 16. Обпачные операционные системы и операционные системы Интернета вещей
Глава 17. Сетевые протоколы
Глава 18. Распределенная обработка, вычисления "клиент/сервер" и кластеры
Глава 19. Управление распределенными процессами
Глава 20. Обзор вероятности и стохастических процессов
Глава 21. Анализ очередей
Глава
Глава
Приложение А. Вопросы параллельности
Приложение&. Проекты в области программирования и операционных систем
Приложение В. Дополнительные вопросы параллельности
Приложение Г. Объектно-ориентированное проектирование
Приложение Д. Закон Амдала
Приложение Е. Хеш-таблицы
Приложение Ж. Время отклика
Приложение З. Концепции теории массового обслуживания
Приложение И. Сложность алгоритмов
Приложение К. Дисковые устройства хранения
Приложение Л. Криптографические алгоритмы
Приложение М. Введение в программирование сокетов
Приложение Н. Международный справочный алфавит
Приложение О. Параллельная система программирования
Приложение П. Управление процедурами
Приложение Р.
eCos
Глоссарий
Сокращения
Список литературь1
Предметный указатель
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
~~и
Приложение 1.А. Характеристики производительности двухуровневой памяти
Локальность
Функционирование двухуровневой памяти
Производительность
n
75
75
78
78
СодЕРждниЕ
Глава
2.1.
2. Обзор операционных систем
Цели и функции операционных систем
Операционная система как интерфейс между пользователем и компьютером
Операционная система как диспетчер ресурсов
Простота развития операционной системы
2.2.
Эволюция операционных систем
Последовательная обработка
Простые пакетные системы
Многозадачные пакетные системы
Системы, работающие в режиме разделения времени
2.3.
Основные достижения
Процессы
Управление памятью
Защита информации и безопасность
Планирование и управление ресурсами
2.4.
2.5.
Разработки, ведущие к современным операционным системам
Отказоустойчивость
Фундаментальные концепции
Отказы
Механизмы операционных систем
2.6.
многоядерных систем
SMP
Вопросы проектирования операционных систем для многоядерных систем
Обзор операционной системы
Microsoft Windows
Основы
Архитектура
Модель "клиент/сервер"
Потоки и симметричная мноrопроцессорность
Функции ожидания
Объекты диспетчера
Критические участки
Гибкие блокировки читателя/писателя и условные переменные
Синхронизация без участия блокировок
6.11.
6.12.
6.13.
Межпроцессное взаимодействие в Android
Резюме
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Часть
Глава
7.1.
111. Память
7. Управление памятью
399
Требования к управлению памятью
Защита
Совместное использование
Логическая организация
Физическая организация
Распределение памяти
Фиксированное распределение
Динамическое распределение
Система двойников
Перемещение
7.3. Страничная организация памяти
7.4. Сегментация
7.5. Резюме
7.6. Ключевые термины, контрольные
вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Приложение 7.А. Загрузка и связывание
Загрузка
Компоновка
Глава
8.1.
8.
Виртуальная память
Аппаратное обеспечение и управляющие структуры
Локальность и виртуальная память
СОДЕРЖАНИЕ
Сегментация
Комбинация сегментации и страничной организации
Защита и совместное использование
8.2.
Программное обеспечение операционной системы
Стратегия выборки
Стратегия размещения
Стратегия замещения
Управление резидентным множеством
Стратегия очистки
Управление загрузкой
8.3.
Управление памятью в
UNIX
и
Solaris
Страничная система
Распределение памяти ядра
8.4.
Управление памятью в
Виртуальная память
Linux
Linux
Распределение памяти ядра
8.5.
Управление памятью в
Windows
Windows
Страничная организация Windows
Свопинг в Windows
8.6. Управление памятью в Android
8.7. Резюме
8.8. Ключевые термины, контрольные вопросы
Карта виртуальных адресов
Многопроцессорное планирование и планирование реального времени
Многопроцессорное и многоядерное планирование
Зернистость
Вопросы проектирования
Планирование процессов
Планирование потоков
Планирование потоков в многоядерных системах
10.2. Планирование
реального времени
Введение
Характеристики операционных систем реального времени
Планирование реального времени
Планирование с предельными сроками
Частотно-монотонное планирование
Инверсия приоритета
10.3. Планирование
в
Linux
Планирование реального времени
Обычное планирование
10.4. Планирование в UNIX SVR4
10.5. Планирование в UNIX FreeBSD
Классы приоритетов
SMP и многоядерности
10.6. Планирование в Windows
Поддержка
Приоритеты процессов и потоков
Многопроцессорное планирование
10.7. Резюме
10.8. Ключевые
термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Часть
Глава
V.
Ввод-вывод и файлы
11. Управление вводом-выводом и планирование дисковых операций
11.1. Устройства ввода-вывода
11.2. Организация функций ввода-вывода
Эволюция функций ввода-вывода
Прямой доступ к памяти
11.3.
Вопросы проектирования операционных систем
Цели проектирования
Логическая структура функций ввода-вывода
11.4.
Буферизация операций ввода-вывода
Двойной буфер
Циклический буфер
Использование буферизации
Linux
Файловые системы встроенного Linux
Преимущества встроенных систем Linux
µClinux
Android
13.4. TinyOS
Характеристики встроенной системы
Беспроводные сети датчиков
Цели
TinyOS
Компоненты
TinyOS
TinyOS
Планировщик в
Пример конфигурации
Интерфейс ресурсов
13.5.
TinyOS
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Глава
14.1.
14.2.
14.
Виртуальные машины
Концепции виртуальных машин
Гипервизоры
Назначение rипервизоров
Паравиртуализация
Аппаратно поддерживаемая виртуализация
Виртуальное устройство
14.3. Контейнерная
виртуализация
Группы управления ядром
Концепции контейнеров
Файловая система контейнера
Микрослужбы
Docker
14.4. Вопросы виртуализации на уровне процессоров
14.5. Управление памятью
14.6. Управление вводом-выводом
14.7. VMware ESXi
14.8. Варианты Hyper-V и Xen от корпорации Microsoft
14.9. Java VM
14.10. Архитектура виртуальной машины Linux VServer
Архитектура
Планирование процессов
Злоумышленники и зловредные программы
Угрозы системного доступа
Контрмеры
15.2.
Переполнение буфера
Атаки типа переполнения буфера
Защита времени компиляции
Защита времени выполнения
15.3. Управление доступом
Управление доступом к файловой системе
Стратегии управления доступом
15.4.
Управление доступом в
UNIX
Традиционное управление доступом к файлам в
Списки управления доступом в
15.5.
UNIX
UNIX
Усиление защиты операционных систем
Установка операционной системы и применение обновлений
Удаление ненужных служб, приложений и протоколов
Конфигурирование пользователей, групп и аутентификации
Конфигурирование средств управления ресурсами
Установка дополнительных средств управления защитой
Тестирование защиты системы
15 .6.
Поддержание безопасности
Протоколирование
Резервное копирование и архивирование данных
15.7.
Безопасность
Windows
Схема управления доступом
Токен доступа
Дескрипторы безопасности
15.8.
15.9.
Резюме
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Глава
Облачные вычисления
Элементы облачных вычислений
Модели предоставления услуг облачных вычислений
Модели развертывания облака
Эталонная архитектура облачных вычислений
16. Облачные операционные системы и операционные
системы Интернета вещей
16.1.
17
Облачные операционные системы
Инфраструктура как служба
Требования к облачной операционной системе
Общая архитектура облачной операционной системы
OpenStack
819
821
821
823
824
828
831
832
834
835
842
18
16.3.
СОДЕРЖАНИЕ
Интернет вещей
Вещи в Интернете вещей
Эволюция
Компоненты lоТ-устройств
Интернет вещей в контексте облака
Границы
Туманные вычисления
Базовая сеть
Облачная сеть
16.4. Операционные системы
для Интернета вещей
Устройства с ограниченными ресурсами
Требования к операционным системам для Интернета вещей
Архитектура операционной системы дrIЯ Интернета вещей
Операционная система
16.5.
RIOT
Ключевые термины и контрольные вопросы
Ключевые термины
Контрольные вопросы
Глава
17. Сетевые протоколы
17.1. Потребность
17.2. Архитектура
в архитектуре протоколов
TCP/IP
Уровни протоколов TCP/IP
Протоколы ТСР и UDP
Протоколы IP и 1Pv6
Принцип действия протоколов TCP/IP
Приложения протокола TCP/IP
17.3.
протоколов
Сокеты
Сокет
Вызовы интерфейса
17.4. Организация
Socket
сетей в Liпux
Передача данных
Прием данных
17.5.
17.6.
Резюме
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Приложение 17.А. Простой протокол передачи файлов
Введение в протокол
Пакеты
TFTP
TFTP
Краткий обзор передачи данных
Ошибки и задержки
Синтаксис, семантика и синхронизация
Вычисления "клиент/сервер"
Что такое вычисления "клиент/сервер"
Приложения "клиент/сервер"
Промежуточное программное обеспечение
18.2.
Распределенный обмен сообщениями
Надежность и ненадежность
Блокировка и неблокирующее выполнение
18.3. Вызов удаленных
процедур
Передача параметров
Представление параметров
Привязка к архитектуре "клиент/сервер"
Синхронность и асинхронность
Объектно-ориентированные механизмы
18.4. Кластеры
Конфиrурации кластеров
Вопросы проектирования операционных систем
Архитектура кластерных вычислительных систем
Кластеры в сравнении с симметричной многопроцессорной обработкой
18.5. Кластерный сервер Windows
18.6. Кластеры Beowulf и Linux
Функциональные средства Beowulf
Программное обеспечение Beowulf
18.7. Резюме
18.8. Ключевые термины, контрольные вопросы
и задачи
Ключевые термины
Контрольные вопросы
Задачи
Глава
19. Управление распределенными процессами
19.1. Перенос
процессов
933
Метод передачи эстафеты
957
Распределенная взаимоблокировка
Взаимоблокировка при распределении ресурсов
958
960
Взаимоблокировка при обмене сообщениями
9б8
Выселение
Вытесняющие переносы в сравнении с невытесняющими
Распределенные глобальные состояния
Глобальные состояния и распределенные моментальные снимки
Алгоритм распределенных моментальных снимков
Распределенное взаимное исключение
Принципы распределенного взаимного исключения
Упорядочение событий в распределенной системе
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Глава
20.1.
20.
Обзор вероятности и стохастических процессов
Основы теории вероятности
Определения вероятности
Условная вероятность и независимость
Теорема Байеса
20.2.
Случайные переменные
Функции распределения и плотности
Важные виды распределений
Множество случайных переменных
20.3.
Элементарные понятия стохастических процессов
Статистика первого и второго порядка
Стационарные стохастические процессы
Спектральная плотность
Независимые приращения
Эргодичность
20.4.
Задачи
Глава
21.1.
21.2.
21.3.
21. Анализ очередей
Простой пример поведения очередей
Цель анализа очередей
Модели очередей
Одноканальная система массового обслуживания
Многоканальная система массового обслуживания
Основные соотношения из теории массового обслуживания
Предположения
21.4.
21.5.
21.6.
Одноканальные системы массового обслуживания
Многоканальные системы массового обслуживания
Примеры
Сервер базы данных
Вычисление процентилей
Сильно связанный мультипроцессор
Задача построения многоканальной системы массового обслуживания
21.7.
21.8.
Очереди с приоритетами
Сети очередей
Разделение и объединение потоков трафика
Последовательные очереди
Теорема Джексона
Применение теоремы Джексона в сети с коммутацией пакетов
Регистры, доступные пользователю
Управляющие регистры и регистры состояния
В.2. Выполнение команд функций ввода-вывода
В.3. Технологии ввода-вывода
Программируемый ввод-вывод
Ввод-вывод, управляемый прерываниями
Прямой доступ к памяти
В.4. Вопросы аппаратной производительности в многоядерных системах
Увеличение степени параллелизма
Энергопотребление
22
СОДЕРЖАНИЕ
Приложение Г. Объектно-ориентированное проектирование
1083
Г.1. Мотивация
Г.5. Дополнительные материалы
1084
1085
1086
1087
1090
1090
1091
1095
Приложение Д. Закон Амдала
1097
Приложение Е. Хеш-таблицы
1099
Приложение Ж. Время отклика
1103
Приложение 3. Концепции теории массового обслуживания
3.1. Зачем нужна теория массового обслуживания
3.2. Очередь в случае одного сервера
3.3. Многоканальная очередь
3.4. Пуассонова скорость поступления
1107
1107
1109
1111
1113
Приложение И. Сложность алгоритмов
1115
Приложение К. Дисковые устройства хранения
1119
К.1. Магнитные диски
1119
1119
1122
1126
1126
1128
1128
1129
1129
Г.2. Объектно-ориентированные концепции
СтруК1)'ра объектов
Классы объектов
Включение
Г.3. Преимущества объектно-ориентированного подхода
Г.4.
CORBA
Организация данных и форматирование
Физические характеристики
К.2. Оптическая память
CD-ROM
CD с возможностью записи
CD-R с возможностью перезаписи
DVD
Оптические диски высокой четкости
DES
AES
Л.2. Шифрование с открытым ключом
Алгоритм Ривеста-Шамира-Адлемана
(RSA)
Л.3. Аутентификация сообщений и хеш-функции
Аутентификация с использованием симметричного шифрования
Аутентификация без шифрования
Код аутентификации сообщения
Функция одностороннего хеширования
Л.4. Безопасные хеш-функции
СодЕРждн иЕ
23
Приложение М. Введение в программирование сокетов
1143
М.1. Сокеты, дескрипторы, порты и соединения
1145
1146
М.2. Модель "клиент/сервер"
Заnуск программы с использованием сокетов на компьютере под управлением
Windows,
не подключенном к сети
1146
Запуск программы с использованием сокетов на компьютере под управлением
Windows,
подключенном к сети, когда и сервер, и клиент находятся
на одной машине
М.3. Работа с сокетами
Создание сокета
Адрес сокета
Привязка к локальному порту
Представление данных и порядок байтов
Подключение сокета
Функция
gethostbyname ()
Прослушивание входящих соединений
Прием соединения от клиента
Отправка и получение сообщения через сокет
Закрытие сокета
Сообщение об ошибках
Пример клиентской программы
Пример серверной программы
Планировщик битовой карты
Планировщик многоуровневой очереди
Р.4. Синхронизация потоков
eCos
Мьютексы
Семафоры
Условные переменные
Флаги событий
Почтовые ящики
Циклические блокировки
Глоссарий
1217
Сокращения
1235
Список литературы
1236
Предметный указатель
1251
-
Посвящается Трише
ОБ АВТОРЕ
Доктор Вильям Столлинrс является автором
лее
40
18
книг, а включая переиздания,
-
бо
книг по компьютерной безопасности, компьютерным сетям и архитектуре ком
пьютеров. Его перу принадлежат многочисленные публикации в журналах, включая та
кие издания, как
Proceedings of'the
!ЕЕЕ, АСМ
Computing Reviews
От Ассоциации академических авторов Вильям Столлингс
13
и
Cryptologia.
раз получал награду за
лучший учебник года в области компьютерных наук.
За более чем
30
лет работы в этой области он был техническим сотрудником, тех
ническим руководителем и исполняющим директором ряда высокотехнологичных фирм.
Он спроектировал и реализовал системы протоколов на базе
TCP/IP
и
OSI
для различ
ных компьютеров и операционных систем от микрокомпьютеров до мейнфреймов. Он
консультировал правительственные учреждения, поставщиков компьютеров и програм
много обеспечения и крупных пользователей в области дизайна, выбора и использования
сетевого программного обеспечения и продуктов.
Столлингс создал и поддерживает сайт для студентов
Resource Site
по адресу
ComputerScienceStudent. com.
Computer Science Student
Этот сайт предоставляет
документацию и ссылки на различные темы, представляющие общий интерес как для
студентов в области компьютерных наук, так и для профессионалов. Он является чле
ном редакционной коллегии
Cryptologia -
научного журнала, посвященного различным
аспектам криптографии.
Столлингс имеет ученую степень доктора философии в области компьютерных наук
в МТИ и степень бакалавра электротехники в Нотр-Дам.
ПРЕДИСЛОВИЕ
Новое в девятом издднии
С момента публикации восьмого издания этой книги в области операционных систем
наблюдаются непрерывные нововведения и улучшения. В этой, новой, редакции я попы
тался уделить внимание этим изменениям при сохранении всеобъемлющего характера ох
вата всей рассматриваемой области. Процесс пересмотра начался с того, что восьмое из
дание книги было всесторонне проанализировано рядом профессоров, преподающих этот
предмет, и работающими в данной области профессионалами. В результате было уточне
но множество мест книги, улучшены иллюстрации, а описания стали более строгими.
Помимо этих уточнений, для повышения дидактического уровня и удобочитаемости
техническое содержание книги было кардинально обновлено, чтобы отразить все проис
шедшие в данной захватывающей области изменения. Самые заметные изменения книги
включают следующее.
•
Обновление материала о
Linux.
Материал о
отражения изменений, происшедших с ядром
•
Обновление материала об
Android.
Linux был
Linux после
Материал об
обновлен и расширен для
выхода восьмого издания.
Android был обновлен и расши
Android после выхода вось
рен для отражения изменений, происшедших с ядром
мого издания.
•
Новый материал о виртуализации. Глава о виртуальных машинах полностью
переписана, чтобы обеспечить лучшую организацию материала, а также большее
его соответствие последним разработкам в этой области. Кроме того, добавлен но
вый раздел по использованию контейнеров.
•
Новые облачные операционные системы. Новинкой в этом издании является
описание облачных операционных систем, включающее обзор облачных вычисле
ний, обсуждение принципов и требований к облачным операционным системам,
а также рассмотрение
OpenStack,
популярной облачной операционной системы с
открытым исходным кодом.
•
Новые операционные системы для Интернета вещей. Еще одной новинкой
этого издания являются операционные системы для Интернета вещей
Things -
loT).
Книга включает обзор
операционной системе
мы
•
loT
loT
IoT,
и обсуждение
(lntemet of
обсуждение принципов и требований к
RIOT,
популярной операционной систе
с открытым ИСХОДНЫМ КОДОМ.
Обновленные и расширенные встраиваемые операционные системы. Эта гла
ва существенно переработана и дополнена.
•
Раздел о встраиваемых системах расширен и теперь включает в себя обсужде
ние микроконтроллеров и глубоко встраиваемых систем.
•
•
Обзорный раздел о встраиваемых операционных системах расширен и обновлен.
Расширено рассмотрение встраиваемых систем
популярной встраиваемой системы
•
Linux -
Linux;
µClinux.
добавлено обсуждение
Параллельные вычисления. В руководство по проектам добавлены новые проек
ты, призванные помочь студентам лучше понять принципы параллелизма.
28
ПРЕДИСЛОВИЕ
Цели
Эта книга
цель
-
-
о концепциях, структурах и механизмах операционных систем. Ее
максимально ясно и полно представить природу и характеристики современных
операционных систем.
Это очень сложная задача по целому ряду причин. Во-первых, имеется огромный ас
сортимент и разнообразие компьютеров, для которых предназначены эти операционные
системы. К ним относятся встраиваемые системы, смартфоны, однопользовательские
рабочие станции и персональные компьютеры, разделяемые системы среднего размера,
большие ЭВМ, суперкомпьютеры и специализированные машины, такие как системы ре
ального времени. Разнообразие ограничивается не только емкостью и скоростью машин,
но и областями их применения и требованиями системы сопровождения. Во-вторых,
стремительные перемены, которые всегда были характерны для компьютерных систем,
nродолжаются и в настоящее время. Ряд ключевых областей в проектировании опера
ционных систем имеют совсем недавнее происхождение, и исследования этих и других
новых областей продолжается и сегодня.
Несмотря на это разнообразие и темпы изменений, некоторые фундаментальные кон
цепции последовательно применяются во всех операционных системах. Конечно, при
менение этих концепций зависит от текущего состояния технологий и требований кон
кретного приложения. Цель этой книги
-
представить тщательное рассмотрение основ
проектирования операционных систем и связать их с вопросами современного проекти
рования операционных систем и текущими направлениями в их разработке.
ПРИМЕРЫ СИСТЕМ
Книга предназначена для знакомства читателя с принципамипроектирования и ас
пектами реализации современных операционных систем. Соответственно, чисто кон
цептуальное или теоретическое рассмотрение будет неадекватным. Для иллюстрации
концеnций и связи их с реальным проектированием и выбором методов и технологий,
которые должны быть при этом сделаны, в качестве работающих практических приме
ров операционных систем выбраны следующие.
• Windows.
Многозадачная оnерационная система для персональных компьютеров,
рабочих станций, серверов и мобильных устройств. Эта операционная система
включает в себя многие из последних достижений в области технологий опера
ционных систем. Кроме того,
Windows
является одной из первых важных коммер
ческих операционных систем, которые основаны на принципах объектно-ориен
тированного проектирования. Эта книга охватывает технологии, используемые в
версии
Windows,
• Android.
известной как
Windows 1О.
Операционная система
Android
предназначена для встраиваемых ус
тройств, в частности для мобильных телефонов. В книге приводится подробная
информация о внутреннем устройстве
Android
и особое внимание уделяется уни
кальным требованиям встраиваемой среды.
• UNIX.
Это многопользовательская операционная система, изначально предназна
чавшаяся
шин
-
для
мини-компьютеров,
но
реализованная
для
широкого
спектра
ма
от мощных микрокомпьютеров до суперкомпьютеров. В качестве приме-
ПРЕДИСЛОВИЕ
ров включены несколько видов
ляется
FreeBSD,
UNIX.
Одной из широко используемых систем яв
которая включает в себя многие современные возможности. Еще
одной широко используемой коммерческой версией
• Linux.
29
Широко используемая версия
UNIX
UNIX
является
Solaris.
с открытым исходным кодом.
Эти системы были выбраны с учетом их актуальности и представительности.
Обсуждение перечисленных операционных систем разбросано по всему тексту, а не
сконцентрировано в виде отдельной главы или приложения. Таким образом, в ходе об
суждения параллелизма описаны механизмы параллелизма каждого из образцов систем и
рассматривается мотивация выбора того или иного индивидуального дизайна. При таком
подходе концепции проектирования, рассматриваемые в каждой конкретной главе, ока
зываются подкрепленными примерами из реальной жизни. Для удобства все материалы
по каждой из систем доступны также в виде онлайн-документации.
Данная книга предназначена как для академической, так и для профессиональной ау
дитории. В качестве учебника она предназначена для одно- или двухсеместрового курса
по операционным системам для специальностей информатики, вычислительной техни
ки и электротехники. Это издание предназначено для использования в качестве одного
включают операционные системы как одну из тем данного курса.
делит весь курс на три уровня: первый уровень
ны быть включены в учебную программу, второй уровень
-
все темы, которые долж
темы, которые желательно
включить в программу, и избранные темы, для которых желательно обеспечить повы
шенные широту и глубину изложения. В области операционных систем
ет в себя две темы первого уровня, четыре
-
CS2013
включа
второго и шесть избранных тем, каждая из
которых имеет ряд подтем. Книга охватывает все разделы и подразделы, перечисленные
во всех трех категориях
В табл.
1
CS2013.
показан охват книгой тем по операционным системам курса
Полный список подтем в каждой теме можно найти в файле
Ьох.
CS2013-0S.pdf
CS2013.
на сайте
com/OS9e.
ПЛАН книги
Книга состоит из шести частей.
1.
Основы
11.
Процессы
111. Память
IV.Планирование
V.
Ввод-вывод и файлы
VI. Дополнительные
темы (встроенные ОС, виртуальные машины, безопасность ОС,
операционные системы Интернета вещей и облачные операционные системы)
30
ПРЕДИСЛОВИЕ
ТА&лицА
1.
Темы по ОПЕРАционным СИСТЕМАМ КУРСА
Тема (уровень)
CS2013
Материал книги по данной теме
Обзор операционных
Глава
2,
"Обзор операционных систем"
Глава
1,
"Обзор компьютерной системы"
Глава
2,
"Обзор операционных систем"
Параллельность
Глава
5,
"Параллельные вычисления: взаимоисключения
(уровень
и многозадачность"
систем (уровень
1)
Принципы операционных
систем (уровень
1)
2)
Глава
6,
"Параллельные вычисления: взаимоблокировка
и голодание"
Приложение А, "Вопросы параллельности"
Глава
18,
"Распределенная обработка, вычисления
«клиент/сервер» и кластеры"
Планирование и диспетче
ризация (уровень
2)
Глава
9,
Глава
10,
"Однопроцессорное планирование"
"Многопроцессорное планирование и планирование
реального времени"
Глава
7,
"Управление памятью"
Глава
8,
"Виртуальная память"
Глава
15,
"Безопасность операционных систем"
Глава
14,
"Виртуальные машины"
Управление устройствами
Глава
11,
"Управление вводом-выводом и планирование
(избранные темы)
дисковых операций"
Файловые системы
Глава
12,
"Управление файлами"
Системы реального време
Глава
10,
"Многопроцессорное планирование и планирование
ни и встроенные системы
реального времени"
Управление памятью
(уровень
2)
Безопасность и защита
(уровень
2)
Виртуальные машины
(избранные темы)
(избранные темы)
(избранные темы)
Глава
13,
"Встроенные операционные системы"
Материалы по операционной системе Aпdroid по всей книге
Отказоустойчивость
Раздел
2.5
(избранные темы)
Производительность сис
Вопросы производительности, связанные с управлением па
темы (избранные темы)
мятью, планированием и другими областями, рассматривае
мые по всей книге
ПРЕДИСЛОВИЕ
31
Книга включает многочисленные рисунки и таблицы, облегчающие восприятие ма
териала. Каждая mава содержит список ключевых слов, обзор вопросов и домашние за
дания. Книга также включает обширный словарь терминов, список часто используемых
сокращений и библиографию. Кроме того, для преподавателей доступен банк тестов.
МАТЕРИАЛЫ ДЛЯ ПРЕПОДАВАТЕЛЕЙ
Основная цель книги
-
быть эффективным средством обучения по этой фундамен
тальной, но все еще находящейся в непрерывном развитии теме. Эта цель находит свое
отражение в структуре книги и вспомогательных материалах. Книга сопровождается
следующими дополнительными материалами в помощь преподавателю.
•
Ответы и решения. Ответы на вопросы и решения задач, предлагаемых в конце
каждой главы.
•
Руководство по проектам. Предлагаемые проекты для всех категорий проектов,
перечисленных в этом предисловии.
•
Слайды
PowerPoint.
Набор слайдов, охватывающих материал всех глав и пригод-
ных для демонстрации на лекциях.
•
РDF-файлы. Репродукции всех рисунков и таблиц в книге.
•
Банк тестов. Множество вопросов ко всем главам с отдельными файлами ответов.
•
Видеопримечания по параллельным вычислениям. Профессора вечно утверж
дают, что параллелизм
-
самая сложная для понимания студентами концепция в
области операционных систем. Издание сопровождается рядом видеолекций, об
суждающих различные алгоритмы параллельных вычислений, рассматриваемых в
книге.
•
Примерные программы обучения. Текст содержит больше материала, чем может
быть охвачено в пределах одного семестра. Соответственно, преподаватели обес
печиваются несколькими вариантами учебных программ, которые определяют, как
использовать книгу в течение ограниченного времени. Эти примеры основаны на
реальном опыте ряда профессоров, работавших с седьмым изданием книги.
Все эти материалы доступны в Центре ресурсов для преподавателей
(lnstructor
IRC) этого учебника, доступ к которому можно получить через
веб-сайт издателя www.pearsonhighered.com/stallings или по ссылке Pearson
Resources for lnstructors на сайте автора книги по адресу WilliamStallings. com/
OperatingSystems. Чтобы получить доступ к IRC, обратитесь к местному предста
вителю Pearson через страницу pearsonhighered. com/educator /replocator /
requestSalesRep. page или позвоните в Pearson Faculty Services по номеру 1-800526-0485.
Сайт автора WilliamStallings. com/OperatingSystems предлагает следующее:
Resource Center -
•
•
ссылки на сайты других курсов;
подписка на список рассылки для преподавателей для обмена информацией, пред
ложениями и вопросами друг с другом и с автором.
32
ПРЕДИСЛОВИЕ
ПРОЕКТЫ и УПРАЖНЕНИЯ для СТУДЕНТОВ
Для многих преподавателей важным компонентом курса по операционным системам
является проект или ряд проектов, при работе над которыми студент получает практи
ческий опыт, закрепляющий знания концепций из текста книги. В онлайн-части текста
предложены два основных программных проекта. Кроме того, во вспомогательных ма
териалах для преподавателей, доступных через
Pearson,
имеется не только руководство
о том, как распределять и структурировать различные проекты, но и набор руководств
пользователя для различных типов проектов, а также конкретные задания, написанные
специально для этой книги. Преподаватели могут давать студентам задания в следую
щих областях:
•
Проект
•
Имитационные проекты: описаны ниже.
•
OS/161:
описан ниже.
Проекты с семафорами: призваны помочь учащимся понять концепции паралле
лизма, включая состояния гонки, голодание и взаимоблокировку.
•
Проекты ядра:
IRC
включает полную поддержку преподавателя для двух различ
ных наборов проектов программирования ядра
граммирования ядра
•
•
Linux,
а также набор проектов про
Android.
Программные проекты: описаны ниже.
Исследовательские проекты: серия исследовательских проектов, которые требу
ют от студентов провести поиск информации по конкретной теме в Интернете и
написать отчет.
•
Задания по работе со статьями: список статей, которые можно дать студентам
для чтения и написания отчетов или докладов.
•
Письменные задания: список письменных заданий для облегчения изучения ма
териала.
•
Темы для дискуссий: темы, которые можно использовать в классе, чате или на
форуме для углубленного изучения некоторых тем и повышения уровня сотрудни
чества студентов.
Кроме того, представлена информация о пакете программного обеспечения ВАС!, ко
торый служит в качестве каркаса для изучения механизмов параллелизма.
Этот разнообразный набор проектов и другие упражнения для студентов позволяют
преподавателю использовать книгу как один из компонентов обучения, адаптировав курс
к конкретным потребностям преподавателя и студентов. Подробности
-
в приложении Б,
"Проекты в области программирования и операционных систем".
OS/161
Это издание обеспечивает поддержку компонента активного обучения на основе
OS/161. OS/161 -
учебная операционная система, которая все шире и шире применя
ется в качестве платформы для обучения внутреннему устройству операционных сие-
ПРЕДИСЛОВИЕ
33
тем. Она обеспечивает накопление студентами опыта работы с реальной операционной
системой, не подавляя их сложностями полноценной операционной системы, такой как
По сравнению с реальными операционными системами
Linux.
OS/161
невелика (около
20тысяч строк кода и комментариев) и, следовательно, гораздо проще для понимания
студентами.
IRC
1.
включает следующее.
Упакованный набор html-файлов, которые преподаватель может загрузить на сер
вер учебного курса для доступа студентов.
2.
Начальное руководство для студентов, призванное помочь им начать работать с
OS/161.
3.
Комплект упражнений с использованием
4.
Типовые решения для каждого упражнения, предназначенные для преподавателя.
5.
OS/ 161
для студентов.
Все эти материалы связаны перекрестными ссылками с соответствующими разде
лами книги, так что студент может читать материал учебника, а затем выполнять
соответствующий проект
OS/161.
МОДЕЛИРОВАНИЕ
IRC
обеспечивает поддержку набора семи проектов, связанных с моделированием,
которые охватывают ключевые области проектирования операционных систем. Студент
может использовать набор пакетов моделирования для анализа особенностей дизайна
операционной системы. Имитаторы написаны на
Java
и могут выполняться как локаль
ное Jаvа-приложение или как онлайн-приложение через браузер.
IRC
включает конкрет
ные задания, которые можно давать студентам, точно указывая им, что они должны сде
лать и какие результаты ожидаются.
ПРОГРАММНЫЕ ПРОЕКТЫ
Это издание обеспечивает также поддержку проектов по программированию. В книге
описаны два крупных программных проекта
-
создание оболочки, или интерпретатора
командной строки, а также построение диспетчера процессов.
IRC
предоставляет допол
нительные сведения и пошаговые упражнения для разработки этих программ.
В качестве альтернативы преподаватель может предложить студентам более об
ширный ряд проектов, которые охватывают различный изложенный в книге материал.
Студенты обеспечиваются подробными инструкциями по выполнению каждого из про
ектов. Кроме того, для студентов имеется ряд домашних заданий, которые затрагивают
вопросы, относящиеся к каждому проекту.
Наконец, представленная на
IRC
документация по проектам включает ряд програм
мных проектов, которые охватывают широкий спектр тем и которые могут быть реали
зованы на любом подходящем языке на любой платформе.
34
ПРЕДИСЛОВИЕ
ОнлАйн-докvмЕнтАция
И ВИДЕОПРИМЕЧАНИЯ ДЛЯ СТУДЕНТОВ
В этом издании значительное количество оригинальных вспомогательных ма
териалов для студентов сделано доступным онлайн в двух местах. Веб-сайт авто
ра
WilliamStallings. com/OperatingSystems
Resources)
(ищите на нем ссылку
Student
включает список ссылок по тематике книги, организованных по главам, а так
же список известных опечаток.
Купив этот учебник*, читатель получит и двенадцатимесячный доступ к сайту со
провождения книги, который включает следующие материалы.
•
Онлайн-приложения. Есть многочисленные интересные темы, которые расширя
ют материал в тексте книги, но включение которых в печатный текст не является
оправданным. В общей сложности имеется
15
онлайн-приложений с дополнитель
ными материалами для любознательных студентов.
•
Домашние задания и решения. Чтобы помочь студентам в понимании материала,
предоставляется отдельный набор домашних заданий с решениями.
•
Анимации. Анимации обеспечивают мощный инструмент, облегчающий понима
ние сложных механизмов современных операционных систем. Для иллюстрации
ключевых функций и алгоритмов в проектировании операционных систем исполь
зуются в общей сложности
•
53
анимации
-
в главах
3, 5-9
и
11.
Видеопримечания. Видеопримечания представляют собой видеоуроки, специаль
но предназначенные для пошагового разъяснения программных концепций, пред
ставленных в этом учебнике. Книга сопровождается рядом видеолекций с обсуж
дением различных алгоритмов параллелизма, описанных в книге.
Чтобы получить доступ к этому содержимому сайта, щелкните на ссылке
Content
Premium
на сайте сопровождения.
БЛАГОДАРНОСТИ
Я хотел бы поблагодарить следующих людей за вклад в данную книгу. Большую
часть нового материала о
Linux предоставил Рами Розен (Rami Rosen). Винет Чадха
(Vineet Chadha) внес большой вклад в новую главу о виртуальных машинах. Дургадосс
Раманатан (Durgadoss Ramanathan) предоставил новый материал об Android ART.
Уже многие годы (и издания) в книге используются материалы от сотен преподавате
лей и специалистов, которые не пожалели своего драгоценного времени и щедро подели
лись своим опытом. Здесь я перечисляю тех, чья помощь в особенности способствовала
написанию настоящего издания книги.
Всю или большую часть рукописи этого издания читали и обсуждали следующие
преподаватели: Джианг Гуо
(Jiang Guo) (Califomia State University, Los Angeles), Эврипид
(Euripides Montagne) (University of Central Florida), Кихонг Парк (Kihong
Park) (Purdue University), Мухаммед Абдус Салам (Mohammad Abdus Salam) (Southem
University and А&М College), Роберт Марморштейн (Robert Marmorstein) (Longwood
Монтань
Благодарю всех, кто представил подробные технические обзоры для одной или не
скольких глав: Нишей Аникар
(Nischay Anikar), Эдри Джовин (Adri Jovin), Рои Мюниц
(Ron Munitz), Фатих Эйуп Нар (Fatih Eyup Nar), Этт Пелтомаки (Atte Peltomaki), Дурrадосс
Раманатан (Durgadoss Ramanathan), Карлос Виллавейджа (Car\os Villavieja), Вей Ванг (Wei
Wang), Сербан Константинеску (Serban Constantinescu) и Чен Янг (Chen Yang).
Спасибо также всем тем, кто представил подробные обзоры различных систем.
Материалы по
Android предоставили Кристофер Мицински (Kristopher Micinski), Рои
(Ron Munitz), Этт Пелтомаки (Atte Peltomaki), Дургадосс Раманатан (Durgadoss
Ramanathan), Маниш Шакья (Manish Shakya), Сэмюэль Симон (Samuel Simon), Вей Ванг
(Wei Wang) и Чен Янг (Chen Yang). Материалы по Linux предоставили Тигран Айвазян
(Tigran Aivaziai1), Кайван Биллимориа (Kaiwan Billimoria), Питер Хьюви (Peter Huewe),
Манмохан Манохаран (Manmohan Manoharan), Рами Розен (Rami Rosen), Неха Найк
(Neha Naik) и Хуалинг Ю (Hualing Yu). Материалы по Windows предоставили Франсиско
Котрина (Francisco Cotrina), Сэм Хайдар (Sam Haidar), Кристофер Кулеци (Christopher
Kuleci), Бенни Олссон (Benny Olsson) и Дэйв Проберт (Dave Probert). Материалы по
R\OT предоставили Эмманюэль Баччелли (Emmanuel Baccelli) и Каспар Шляйзер (Kaspar
Schleiser), а по OpenStack - Боб Каллавей (ВоЬ Callaway). Материал по eCos предостав
лен Ником Гарнеттом (Nick Gamett) из eCosCentric; а Филип Левис (Philip Levis), один
из разработчиков TinyOS, предоставил материалы по TinyOS. Сид Юнг (Sid Young) по
мог материалами по визуализации контейнеров. Эндрю Петерсон (Andrew Peterson) из
Университета в Торонто подготовил материалы по OS/161 для IRC. Джеймс Крейг Барли
(James Craig Burley) разработал и записал видеопримечания.
Упражнения по моделированию подготовил Адам Кричли (Adam Critchley) (University
of Texas), а Марк С парке (Matt Sparks) (University of Illinois) адаптировал набор задач по
Мюниц
программированию для данной книги.
Лоури Браун
(Lawrie Brown)
из
Australian Defence Force Academy
подготовил мате
риал по атакам с использованием переполнения буфера. Чинг-Куанг Шень
(Ching-Kuang
Shene) (Michigan Tech University) предоставил примеры, использованные в разделе о со
стоянии гонки. Трейси Камп (Tracy Camp) и Кейт Хеллман (Keith Hellman) (Colorado
School of Mines) разработали новый набор домашних заданий. Кроме того, Фернандо
Ариэль Гонт (Femando Ariel Gont) разработал ряд новых домашних заданий.
Я хотел бы также поблагодарить Билла Байнума (Bill Bynum) (College of William
and Mary) и Трейси Камп (Tracy Camp) (Colorado School of Mines) за вклад в прило
жение О, "Параллельная система программирования BACI"; Стива Тейлора (Steve
Taylor) (Worcester Polytechnic lnstitute) и профессора Таи Нrуена (Тап N. Nguyen) (George
Mason University) - за вклад в программные проекты и руководство для преподавателя.
Ян Грэхем (lan G. Graham) (Griffith University) внес свой вклад в два программных про
екта данной книги. Оскаре Рикстс (Oskars Rieksts) (Kutztown University) щедро позволил
мне воспользоваться его лекциями, викторинами и проектами.
Наконец, я благодарю множество людей, ответственных за публикацию этой книги,
которые, как всегда, сделали отличную работу. К ним относятся сотрудники
Pearson, в
(Tracy Johnson), ее помощник Кристи Алаура
Кэрол Снайдер (Caro\e Snyder) и менеджер про
частности мой редактор Трейси Джонсон
(Kristy Alaura),
руководитель программы
екта Боб Энгельгардт (ВоЬ
продаж
Pearson,
Engelhardt).
Спасибо также персоналу отдела маркетинга и
без усилий которых эта книга не была бы у вас в руках.
36
ПРЕДИСЛОВИЕ
ЖдЕМ ВАШИХ отзывов!
Вы, читатель этой книги, и есть главный ее критик. Мы ценим ваше мнение и хотим
знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы
хотели бы увидеть изданным нами. Нам интересны любые ваши замечания в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам элект
ронное письмо либо просто посетить наш веб-сайт и оставить свои замечания там.
Одним словом, любым удобным для вас способом дайте нам знать, нравится ли вам эта
книга, а также выскажите свое мнение о том, как сделать наши книги более интересны
ми для вас.
Отправляя письмо или сообщение, не забудьте указать название книги и ее авторов,
а также свой обратный адрес. Мы внимательно ознакомимся с вашим мнением и обяза
тельно учтем его при отборе и подготовке к изданию новых книг.
Наши электронные адреса:
E-mail:
info@williamspuЫishing.com
WWW:
http://www.williamspuЫishing.com
ЧАСТЬ
1
Основы
ГЛАВА 4J
ОБЗОР
КОМПЬЮТЕРНОЙ
СИСТЕМЫ
В ЭТОЙ ГЛАВЕ ...
1.1. Основные эnементы
1.2. Эвоnюцмя микропроцессоров
1.3. Выпоnненме команд
1.4. Прерывания
Прерывания и цикл команды
Обработка прерывания
Множественные прерывания
1.5. Иерархия памяти
1.6. Kew
Обоснование
Принципы работы кеша
Внутреннее устройство кеша
1. 7. Прямой доступ к памяти
1.8. Орrанмзацмя мноrопроцессорных м мноrоядерных сметем
Симметричная многопроцессорность
Многоядерные компьютеры
1.9. Кnючевые термины, контроnьные вопросы м задачи
Ключевые термины
Контрольные вопросы
Задачи
Приложение 1.А. Характеристики промзводмтеnьностм двухуровневой памяти
Локальность
Функционирование двухуровневой памяти
Производительность
40
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
УЧЕБНЫЕ ЦЕЛИ
•
Перечислить основные элементы компьютерной системы и их взаимодействия.
•
Пояснить, какие действия предпринимает процессор для выполнения команды.
•
Понимать концепцию прерываний и то, как и почему процессор использует преры
вания.
•
Перечислить и описать уровни типичной иерархии компьютерной памяти.
•
Пояснить основные характеристики многопроцессорных систем и многоядерных
•
Обсудить концепцию локальности и проанализировать производительность мно
компьютеров.
гоуровневой иерархии памяти.
Понимать работу стека и его применение для поддержки вызовов процедур и воз
•
врата из них.
Операционная система обслуживает пользователей, предоставляя им набор служб и
обращаясь дпя этого к ресурсам аппаратного обеспечения, в состав которых входит один
или несколько процессоров. Кроме того, она управляет вторичной памятью и устройс
твами ввода-вывода. Поэтому, прежде чем приступить к исследованию операционных
систем, важно получить некоторое представление о компьютерных системах, на которых
они работают.
В данной главе представлен обзор аппаратного обеспечения компьютерных систем.
Большинство вопросов освещено кратко, так как предполагается, что читатель знаком
с предметом. Однако некоторые из них раскрыты более подробно, исходя из важности
этих тем для дальнейшего усвоения материала. Дополнительные вопросы рассматрива
ются в приложении В, "Дополнительные вопросы параллельности", а более подробное
изложение можно найти в
1.1.
[242].
ОСНОВНЫЕ ЭЛЕМЕНТЫ
На верхнем уровне компьютер состоит из процессора, памяти и устройств ввода
вывода; при этом каждый компонент представлен одним или несколькими модулями.
Чтобы компьютер мог выполнять свое основное предназначение, состоящее в выполне
нии программ, различные компоненты должны иметь возможность взаимодействовать
между собой. Можно выделить четыре структурных компонента компьютера.
•
Процессор. Осуществляет управление всеми действиями компьютера, а также вы
полняет функцию обработки данных. Если в системе есть только один процессор,
он часто называется центральным процессором
•
(central processing unit - CPU).
Основная память. В ней хранятся данные и программы. Как правило, эта память
является временной, т.е. при выключении компьютера ее содержимое теряется.
Содержимое же дисковой памяти, напротив, сохраняется даже при выключении
компьютерной системы. Часто ее называют реальной, оперативной или первичной
памятью.
41
1.1. Основ ныЕ ЭЛЕМЕНТЫ
•
Устройства ввода-вывода. Служат для передачи данных между компьютером и
внешним окружением, состоящим из различных периферийных устройств, в число
которых входят вторичная память (например, диски), коммуникационное оборудо
вание и терминалы.
•
Системная шина. Обеспечивает взаимодействие между процессорами, основной
памятью и устройствами ввода-вывода.
На рис.
1.1
показаны компоненты верхнего уровня . Одной из функций процессора яв
ляется обмен данными с памятью. Для этого он обычно использует два внутренних (по
отношению к процессору) регистра: регистр адреса памяти
(memory address register -
куда заносится адрес ячейки памяти, в которой будет производиться операция
MAR),
чтения-записи, и регистр буфера памяти
(memory buffer register - MBR),
куда заносятся
данные, предназначенные для записи в память, или те, которые были прочитаны из нее .
Аналогично устройство ввода-вывода задается в регистре адреса ввода-вывода (\/О
dress register -
\!О
AR).
Регистр буфера ввода-вывода (\/О
buffer register -
\!О
служит для обмена данными между устройством ввода-вывода и процессором.
Основная память
Процессор
•
Системная
•
•
шина
1
РС
1
1
MAR
~
1
....
Команда
Команда
1
IR
1
1
~
1
MBR
1/0 AR
1
1/0BR
1
2
•
•
•
Команда
1
.....
~
1
•
•
•
Данные
\юлняющии
мод~
о
Данные
Данные
1
Данные
•
•
•
Модуль ввода-вывода
~
ш
Буферы
Рис.
1.1.
......
РС
-
счетчик команд
IR - регис1р команд
MAR - регистр адреса памяти
MBR - регистр буфера памяти
1/0 AR - per истр адреса ввода-вывода
1/0 BR - ре1 ·истр буфера ввода-вывода
Компоненты компьютера: общая структура
п-2
п-\
adBR)
42
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
Модуль памяти состоит из множества последовательно пронумерованных ячеек. В каж
дую ячейку может быть записана последовательность битов, которая интерпретируется
либо как команда, либо как данные. Модуль ввода-вывода служит для передачи данных от
внешних устройств как в процессор и память, так и в обратном направлении. Для времен
ного хранения данных до окончания их пересылки в нем есть свои внутренние буферы.
Эволюция микРоnРоцЕссоРов
1.2.
Революция, которая принесла нам настольные и переносные компьютеры, состояла в
изобретении микропроцессора, который содержал процессор в одной микросхеме. Хотя
первоначально такой процессор был гораздо более медленным, чем процессор на несколь
ких микросхемах,
микропроцессоры постоянно развивались и в
настоящее время для
большинства вычислений оказываются гораздо более быстрыми благодаря физике, кото
рая обеспечивает перемещение информации за субнаносекундные интервалы времени.
Но микропроцессоры стали не только быстрыми и доступными процессорами общего
назначения; они теперь являются мультипроцессорами
-
в каждой микросхеме содер
жится несколько процессоров (называемых ядрами). Каждое такое ядро имеет несколько
уровней кешей памяти большого объема, а несколько логических процессоров совместно
используют исполнительные модули каждого ядра. По состоянию на
201 О
год даже для
ноутбука не является необычным наличие двух или четырех ядер, каждое с двумя аппарат
ными потоками, т.е. в общей сложности
-
четыре или восемь логических процессоров.
Хотя процессоры обеспечивают очень хорошую производительность для большин
ства видов вычислений, существует растущий спрос на численные вычисления. Графи
ческие процессоры
(Graphical Processing Units - GPU)
обеспечивают эффективные вы
числения над массивами данных, используя возможность обработки множества данных
одной командой
(Single-lnstruction Multiple Data - SIMD) - технологии, впервые по
GPU больше не используются только лишь для вывода
явившейся в суперкомпьютерах.
графики: они применяются и для числовой обработки общего назначения, например для
моделирования физики для игр или вычислений в больших электронных таблицах. Од
новременно процессоры получают все больше возможностей для работы с массивами
данных
-
в архитектуру процессоров семейств х86 и
AMD64
интегрируются все более
и более мощные векторные модули.
Процессоры и графические процессоры
-
не конец вычислительной истории со
временных персональных компьютеров. Имеются, например, процессоры для обработки
цифровых сигналов
(Digital Signal Processors -
DSP),
которые предназначены для ра
боты с потоковыми сигналами, такими как аудио или видео. Они использовались для
встраивания в устройства ввода-вывода, такие как модемы, но в настоящее время стали
полноценными вычислительными устройствами, особенно в наладонниках. Другие спе
циализированные вычислительные устройства (модули с фиксированными функциями)
сосуществуют с процессорами для поддержки других стандартных вычислений, напри
мер для кодирования/декодирования речи и видео (кодеки), или обеспечения поддержки
шифрования и безопасности.
Чтобы удовлетворить требованиям к портативным устройствам, классический микро
процессор уступает место системам на кристалле
(System on
а
Chip - SoC),
в которых
в одной микросхеме находятся не только процессор и кеш-память, но и многие другие
компоненты системы, такие как
DSP, GPU,
кодеки), а также основная память.
устройства ввода-вывода (например, радио и
1.3. ВыполнЕниЕ комднд
1.3.
43
Выполнение комднд
Программа, которую выполняет процессор, состоит из набора хранящихся в памя
ти команд. В простейшем виде обработка команд проходит в две стадии: процессор
считывает (выбирает) из памяти, а затем выполняет очередную команду. Выполнение
программы сводится к повторению процесса выборки команды и ее выполнения. Для
выполнения одной команды может потребоваться несколько операций; их число опреде
ляется природой самой команды.
Набор действий, требующихся для реализации одной команды, называется ее цик
лш1. На рис.
1.2
показан процесс обработки команд процессором в такой упрощенной
схеме, включающей два этапа. Эти этапы называются этапам выборки и этапом выпол
нения. Прекращение работы программы происходит при выключении машины, в случае
возникновения какой-либо фатальной (неисправимой) ошибки или если в программе
имеется команда останова.
Этап выборки
Этап выполнения
1
Выборка
'
Запуск
следующей
команды
Рис.
1.2.
Выполнение
-
команды
(
Останов
Базовый цикл выполнения программы
В начале каждого цикла процессор выбирает из памяти команду. Обычно адрес ячей
ки, из которой нужно извлечь очередную команду, хранится в счетчике команд (РС).
Если не указано иное, после извлечения каждой команды процессор увеличивает зна
чение счетчика команд на единицу. Таким образом, команды выполняются в порядке
возрастания номеров ячеек памяти, в которых они хранятся. Рассмотрим, например, уп
рощенный компьютер, в котором каждая команда занимает одно 16-битовое слово памя
ти. Предположим, что значение счетчика команд установлено равным
300.
Это значит,
что следующая команда, которую должен извлечь процессор, находится в 300-й ячейке.
При успешном завершении цикла команды процессор перейдет к извлечению команд из
ячеек
301, 302, 303
и т.д. Однако, как мы вскоре узнаем, эта последовательность может
быть изменена.
Выбранные команды загружаются в регистр команд
(IR).
Команда состоит из по
следовательности битов, указывающих процессору, какие именно действия он должен
выполнить. Процессор интерпретирует команду и выполняет требуемые действия. В об
щем случае все действия можно разбить на четыре категории.
•
Процессор
-
•
Процессор
-
память. Данные передаются из процессора в память или обратно.
устройства ввода-вывода. Данные из процессора поступают на
периферийное устройство путем передачи их между процессором и устройством
ввода-вывода. Возможен процесс и в обратном направлении.
•
Обработка данных. Процессор может выполнять с данными различные арифме
тические или логические операции.
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
44
•
Управление. Команда может задавать изменение последовательности выполне
ния команд. Например, если процессор извлекает из ячейки
149
команду, которая
указывает, что следующей по очереди должна быть выполнена команда из ячейки
182,
то процессор устанавливает значение счетчика команд равным
182.
Таким об
разом, на следующем этапе выборки команда извлекается не из ячейки
ячейки
150,
а из
182.
Для выполнения команды может потребоваться последовательность, состоящая из
комбинации вышеперечисленных действий.
Рассмотрим простой пример гипотетической машины, характеристики которой при
ведены на рис.
1.3.
В процессоре имеется единственный регистр данных, который на
зывается аккумулятором
(accumulator
-АС). Команды и данные имеют длину
16
бит.
В такой ситуации память удобно организовать в виде 16-битовых ячеек, в каждой из
которых помещается одно слово. Формат команды предусматривает выделение
4
бит
для кода операции. Таким образом, всего может быть 2 4 = 16 различных кодов опера
ций (их можно представить одной шестнадцатеричной 1 цифрой), а адресовать можно до
2 12 =4096 (4Кбайт) слов памяти (которые можно представить трехзначным шестнадца
теричным числом).
о
3 4
Код операции
1
15
Адрес
1
а) Формат команды
о
1
s
1
15
Значение
1
б) Формат целого числа
Счетчик команд (РС)
= Адрес команды
(IR) =Выполняемая команда
Аккумулятор (АС) = Временная память
Регистр команды
в) Внутренние регистры процессора
0001-заrрузить значение АС из памяти
001 О -
сохранить значение АС в память
0101-добавить к АС значение из памяти
г) Фрагмент списка операций
Рис.
На рис.
1.4,
1.3.
Характеристики гипотетической машины
на котором показаны определенные ячейки памяти и регистры процессо
ра, иллюстрируется выполнение фрагмента программы. В этом фрагменте слово, храня
щееся в памяти по адресу
941,
940,
складывается со словом, хранящимся в памяти по адресу
а результат сложения заносится в ячейку
1 Основные
941.
сведения по системам счисления (десятичной, двоичной, шестнадцатеричной) мож
Computer Science Student Resource Site по адресу
но найти в соответствующем документе на сайте
ComputerScienceStudent.com.
1.3. ВыполнЕн иЕ комднд
45
Для выполнения этого действия потребуются три команды, каждая из которых вклю
чает свой этап выборки и этап выполнения.
1.
манд
1. Следует отметить,
(MAR) и буферы памяти
а показание счетчика команд увеличивается на
(IR),
что в этом процессе участвуют регистры адреса памяти
2.
(MBR),
однако для упрощения они не показаны .
Первые
4
бита (первая шестнадцатеричная цифра) в регистре команд указывают
на то, что нужно загрузить значение в аккумулятор . Остальные
надцатеричные цифры) указывают адрес
3.
12 бит
(три шест
940.
извлекается следующая команда
301
Из ячейки
чика команд увеличивается на
4.
Эта команда
загружается в регистр ко
1940)
(она представлена шестнадцатеричным числом
300.
-
Адрес первой команды, хранящейся в счетчике команд,
(5941 ),
после чего значение счет
1.
К содержимому аккумулятора прибавляется содержимое ячейки
941,
и результат
снова заносится в аккумулятор.
5.
Из ячейки
302
извлекается следующая команда
команд увеличивается на
6.
Содержимое аккумулятора заносится в ячейку
Этап выборки
Память
(2941 ),
941.
Этап выполнения
Регистры процессора
Память
300 1 9 4 о
301 5 9 4 1
302 2 9 4 1
300 1 9 4 О
1---~~ АС 301 5 9 4 1
9 4 О IR 302 2 9 4 1
940['[IП
9400003
94 1 о о о 2
3
О О РС
941 со:::.о::п
Шаг
затем значение счетчика
1.
Регистры процессора
3
О
1
РС
3 АС
1 9 4 О IR
О О О
Шаг2
1
Память
300 1 9 4 О
301 5 9 4 1
302 2 9 4 1
Регистры процессора
Память
300 1 9 4 О
О О О 3 АС 301 5 9 4 1
5 9 4 1 IR 302 2 9 4 1
3
О
1
РС
940[Ш]]
941 со:::.о::п
Шаг4
Шаг3
Память
300 1 9 4 о
301 5 9 4 1
302 2 9 4 1
940['[IП
941 со:::.о::п
Шаг5
Рис.
1.4.
Регистры процессора
Память
300 1 9 4 О
30 1 5 9 4 1
2 9 4 1 IR 302 2 9 4 1
О 2 РС
О О О 5 АС
3
Регистры процессора
3
О
3
РС
5 АС
2 9 4 1 IR
О О О
9400003
94 1 о о о 5
Шагб
Пример выполнения программы (содержимое памяти
и регистров представлено шестнадцатеричными числами)
46
ГЛАВА 1' ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
Этот пример показывает, что дпя сложения содержимого ячеек
940
и
941
необходимы
три цикла команды. При более сложном наборе команд циклов понадобилось бы мень
ше. Большинство современных процессоров содержат команды, в состав которых может
входить несколько адресов. При этом во время цикла выполнения некоторых команд
иногда выполняется несколько обращений к памяти. Вместо обращений к памяти в ко
манде может быть задана операция ввода-вывода.
ПРЕРЫВАНИЯ
1.4.
Почти во всех компьютерах предусмотрен механизм, с помощью которого различные
модули (ввода-вывода, памяти) могут прервать нормальную последовательность работы
процессора. Основные общепринятые классы прерываний перечислены в табл.
Т А6ЛИЦА
1.1.
1.1.
КЛАССЫ ПРЕРЫВАНИЙ
Программные
Генерируются в некоторых ситуациях, возникающих в результате
выполнения команд. Такими ситуациями могут быть арифметичес
кое переполнение, деление на нуль, попытка выполнить некоррек
тную команду или обратиться к области памяти, доступ к которой
пользователю запрещен
Таймера
Генерируется таймером процессора. Это прерывание позволяет
операционной системе выполнять некоторые функции периодичес
ки, через заданные промежутки времени
Ввода-вывода
Генерируется контроллером ввода-вывода. Сигнализирует о нор
мальном завершении операции или о наличии ошибок
Аппаратный сбой
Генерируется при сбоях и аварийных ситуациях, как, например, па
дение напряжения в сети или ошибка контроля четности памяти
Прерывания предназначены в основном дпя повышения эффективности использо
вания процессора. Например, большинство устройств ввода-вывода работают намного
медпеннее, чем процессор. Предположим, что процессор передает данные на принтер
по схеме, показанной на рис.
1.2.
После каждой операции процессор вынужден делать
паузу и ждать, пока принтер примет данные. Дпительность этой паузы может быть в ты
сячи или даже миллионы раз больше дпительности цикла команды. Ясно, что подобное
использование процессора является крайне неэффективным.
Чтобы привести конкретный пример, рассмотрим персональный компьютер, который
работает с частотой 1 ГГц, что позволяет выполнять примерно 109 команд в секунду 2 . А ти
пичный жесткий диск имеет скорость вращения 7200 об/мин, что дает время обращения
половины дорожки около 4 мс в 4 миллиона раз медriеннее, чем работа процессора.
Это положение дел проиллюстрировано на рис. 1.5, а. Программа пользователя со
держит ряд вызовов процедуры записи
WRITE,
в промежутках между которыми распо
ложены другие команды. Сплошные вертикальные линии представляют отрезки кода
программы. В отрезках
1, 2
и
3
находятся последовательности команд кода, в которых
2 Обсуждение различных числовых приставок наподобие "гиrа" или "тера" можно най
ти в соответствующем документе на сайте
ComputerScienceStudent.com.
Computer Science Student Resource Site
по адресу
47
1.4. П РЕР Ы ВАНИЯ
WRITE
не используется ввод-вывод. При вызове процедуры
управление передается сис
темной подпрограмме ввода-вывода, которая выполняет соответствующие операции.
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
Процессор генерирует адрес слова, которое нужно прочесть. Если это слово хранится
в кеше, онопередается процессору. В противном случае блок, содержащий это слово,
загружается в кеш, и слово передается процессору.
Внутреннее устройство кеша
В данной книге внутреннее устройство кеша подробно не рассматривается. В этом
разделе кратко перечислены лишь основные его элементы. В дальнейшем читатель смо
жет убедиться, что при изучении устройства виртуальной памяти и дискового кеша мы
имеем дело с похожими вопросами. Все их можно разбить на следующие категории:
•
размер кеша;
•
размер блока;
•
функция отображения;
•
алгоритм замещения;
•
стратегия записи;
•
количество уровней кеша.
С такой характеристикой, как размер кеша, мы уже знакомы. Оказывается, что даже
сравнительно маленький кеш может оказать значительное влияние на производитель
ность компьютера. Другим важным параметром является размер блока, задающий
величину порции данных, которая передается из основной памяти в кеш. Рассмотрим
события, начиная с относительно небольшого размера блоков, а затем увеличивая его.
При увеличении размера блока в кеш попадает больше полезных данных при каждой
их передаче. В результате результативность поиска растет в соответствии с принципом
локальности обращений: вероятность в ближайшем будущем обращения к данным, на
ходящимся недалеко от слова, к которому было выполнено обращение, достаточно высо
ка. Однако есть некое предельное значение, при превышении которого результативность
поиска начинает уменьшаться. Это происходит тогда, когда вероятность использования
вновь считанных данных становится меньше, чем вероятность повторного использова
ния данных, которые необходимо удалить из кеша, чтобы освободить место для нового
блока.
При считывании в кеш нового блока данных функция отображения определяет,
какое место будет отведено для этого блока. Разрабатывая эту функцию, необходимо
учитывать два фактора, накладывающих на нее определенные ограничения. Во-первых,
при считывании блока, вероятно, он заменит другой блок в кеше. Хотелось бы сделать
это таким образом, чтобы свести к минимуму вероятность того, что заменяемый блок
понадобится в ближайшем будущем. Чем более гибкой является функция отображения,
тем больше возможностей для разработки такого алгоритма замены, который позволил
бы увеличить результативность поиска. Во-вторых, с увеличением гибкости функции
отображения должны усложняться схемы, позволяющие определить наличие в кеше тре
буемой информации и обеспечить ее поиск.
При загрузке блоков в кеш в конце концов наступает момент, когда все слоты за
полняются и новый блок нужно записывать на место, занятое каким-то другим блоком.
Выбор этого блока осуществляется в соответствии с алгоритмом замещения, на который
накладывает ограничения отображающая функция. При этом желательно было бы убрать
именно тот блок, который, скорее всего, не понадобится в ближайшем будущем. Хотя
1. 7. ПРЯМОЙ ДОСТУП К ПАМЯТИ
65
достоверно определить его невозможно, достаточно эффективной стратегией является
замена блока, к которому дольше всего не было обращений. Такая стратегия называется
Если содержимое блока в кеше изменилось, его необходимо записать в основную
память до замены другим блоком. Случаи, когда нужно выполнять операции записи, оп
ределяются стратегией записи. Одним из предельных случаев является стратегия, при
которой запись производится при каждом обновлении блока. В другом случае запись
производится только при замене данного блока новым. Такая стратегия сводит к мини
муму количество операций записи в память, но при этом в блоках основной памяти со
держится устаревшая информация, что может привести к ошибкам при многопроцессор
ной работе, а также при прямом доступе к памяти со стороны модулей ввода-вывода.
Наконец, в настоящее время распространены многоуровневые кеши, имеющие назва
ния
"Ll"
(ближайший к процессору кеш) и
"L2",
а во многих случаях и "LЗ". Обсужде
ние преимуществ производительности многоуровневых кешей выходит за рамки данной
книги (см. обсуждение этого вопроса в
1. 7.
[242]).
ПРЯМОЙ ДОСТУП К ПАМЯТИ
Возможны три метода выполнения операций ввода-вывода: программируемый ввод
вывод, ввод-вывод с использованием прерываний и прямой доступ к памяти
memory access -
(direct
ОМА). Перед тем как приступить к изучению ОМА, бегло рассмотрим
два других метода (подробности
-
в приложении В, "Дополнительные вопросы парал
лельности").
Когда процессору при выполнении программы встречается команда, связанная с вво
дом-выводом, он выполняет ее, передавая соответствующие команды контроллеру вво
да-вывода. При программируемом вводе-выводе это устройство выполняет требуемое
действие, а затем устанавливает соответствующие биты в регистрах состояния ввода-вы
вода. Контроллер ввода-вывода больше не посылает процессору никаких сигналов, в том
числе сигналов прерываний. Таким образом, после выполнения команды ввода-вывода
процессор должен играть активную роль в выяснении, когда завершится команда ввода
вывода. Для этого он должен производить проверку состояния модуля ввода-вывода до
тех пор, пока операция не завершится.
При использовании такого метода процессор должен длительное время ожидать, ког
да модуль ввода-вывода будет готов к приему или передаче данных. Процессор во время
ожидания должен постоянно опрашивать состояние модуля ввода-вывода. В результате
существенно снижается уровень производительности всей системы.
При альтернативном подходе, известном как управляемый прерываниями ввод
вывод, процессор может передать контроллеру команду ввода-вывода, а затем перейти к
выполнению другой полезной работы. Затем, когда контроллер ввода-вывода снова будет
готов обмениваться данными с процессором, он прервет процессор и потребует, чтобы
его обслужили. Процессор передает ему новые данные, а затем возобновляет прерван
ную работу.
Хотя ввод-вывод, управляемый прерываниями, более эффективен, чем простой про
граммируемый ввод-вывод, он все еще занимает много процессорного времени для пе-
66
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
редачи данных между памятью и контроллером ввода-вывода (при этом через процессор
должны пройти все пересылаемые данные). Таким образом, обе описанные формы вво
да-вывода обладают двумя неотъемлемыми недостатками:
1.
скорость передачи данных при вводе-выводе ограничена скоростью, с которой
процессор может проверять и обслуживать устройство;
2.
процессор занят организацией передачи данных; при вводе-выводе для каждой
передачи данных должна быть выполнена определенная последовательность ко
манд.
Для перемещения больших объемов данных требуется более эффективный метод
прямой доступ к памяти
(direct memory access -
-
ОМА). Функции ОМА могут выпол
няться отдельным контроллером системной шины или могут быть встроены в контрол
лер ввода-вывода. В любом случае метод работает следующим образом. Когда процес
сору нужно прочитать или записать блок данных, он генерирует команду для модуля
ОМА, посылая ему следующую информацию:
•
указание, требуется ли выполнить чтение или запись;
•
адрес устройства ввода-вывода;
•
начальный адрес блока памяти, использующегося для чтения или записи;
•
количество слов, которые должны быть прочитаны или записаны.
Делегировав полномочия по выполнению этих операций контроллеру ОМА, процес
сор продолжает работу. Контроллер ОМА слово за словом передает весь блок данных в
память или из нее, минуя при этом процессор. После окончания передачи контроллер
ОМА посылает процессору сигнал прерывания. Таким образом, процессор участвует
только в начале и в конце передачи.
Для передачи данных в память и из нее контроллеру ОМА нужен контроль над ши
ной. Если в это время процессору также нужна шина, может возникнуть конфликтная
ситуация, и процессор должен ждать окончания работы модуля ОМА. Заметим, что в
этом случае нельзя говорить о прерывании, так как процессор не сохраняет информа
цию о состоянии задачи и не переходит к выполнению других операций. Вместо этого
он вынужден сделать паузу на время выполнения одного цикла шины. В результате это
приведет к тому, что во время передачи данных с использованием
прямого доступа к
памяти замедляется выполнение процессором тех команд, для которых ему требуется
шина. Тем не менее при передаче большого количества информации прямой доступ к
памяти намного более эффективен, чем программируемый ввод-вывод или ввод-вывод,
управляемый прерываниями.
1.8.
ОРГАНИЗАЦИЯ МНОГОПРОЦЕССОРНЫХ
И МНОГОЯДЕРНЫХ СИСТЕМ
Традиционно компьютер рассматривается как машина, предназначенная для выпол
нения последовательных действий. В большинстве языков программирования алгоритм
задается в виде последовательных инструкций; при работе программы процессор вы
полняет машинные команды последовательно, одну за другой. Каждая команда пред
ставляется в виде последовательности операций (выборка команды, выборка операндов,
выполнение операции, сохранение результатов).
67
1.8. ОРГАНИЗАЦИЯ МНОГОПРОЦЕССОРНЫХ И МНОГОЯДЕРНЫХ СИСТЕМ
Такая точка зрения на компьютер никогда не соответствовала действительности пол
ностью. На уровне микроопераций одновременно генерируется несколько управляющих
сигналов. Уже давно применяется конвейерная обработка команд, позволяющая выпол
нять одновременно по крайней мере операции выборки и выполнения. Оба приведенных
примера являются образцами параллельного выполнения функций.
По мере развития компьютерных технологий и уменьшения стоимости аппаратного
обеспечения разработчики компьютеров находили все больше и больше возможностей
реализации параллелизма. Обычно это делалось для повышения производительности, а
в некоторых случаях
-
для повышения надежности. В данной книге исследуются три
наиболее популярных подхода к обеспечению параллелизма в многопроцессорных сис
темах: симметричная многопроцессорность
(symmetric multiprocessor -
SMP},
много
ядерные компьютеры и кластеры. Симметричная многопроцессорная обработка и мно
гоядерные компьютеры рассматриваются в этом разделе, а кластеры
-
в главе
16,
"Об
лачные операционные системы и операционные системы Интернета вещей".
можно определить как изолированную компьютерную систему,
обладающую следующими характеристиками.
1.
Имеется не менее двух похожих процессоров со сравнимыми возможностями.
2.
Эти процессоры используют одну и ту же основную память и устройства ввода
вывода и соединены шиной или иной схемой внутреннего соединения, так что вре
мя доступа к памяти оказывается примерно одинаковым для каждого процессора.
3.
Все процессоры имеют общий доступ к устройствам ввода-вывода либо через
одни и те же каналы, либо через различные каналы, которые обеспечивают пути к
одному устройству.
4.
Все процессоры могут выполнять одни и те же функции (отсюда и термин сим
метричная).
5.
Система управляется интегрированной операционной системой, которая обеспе
чивает взаимодействие между процессорами и их программами на уровне задач,
заданий, файлов и элементов данных.
Пункты
1-4
не должны вызывать непонимания. Пункт
5
иллюстрирует отличие от
слабосвязанной многопроцессорной системы, такой как кластер. В последнем физичес
кой единицей взаимодействия обычно является сообщение или полный файл. В
SMP
уровень взаимодействия могут представлять собой отдельные элементы данных, и мо
жет иметься высокая степень взаимодействия между процессами.
Организация
SMP
имеет ряд потенциальных преимуществ по сравнению с однопро
цессорной организацией, включая следующие.
•
Производительность. Если работа, которую должен выполнить компьютер, может
быть организована таким образом, что некоторые ее части могут быть выполнены
параллельно, то система с несколькими процессорами даст большую производи
тельность, чем с одним процессором того же типа.
•
Надежность. В симметричной многопроцессорной системе, в которой все процес
соры могут выполнять одни и те же функции, отказ одного процессора не оста-
68
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
навливает машину. Вместо этого система может продолжать функционировать с
пониженной производительностью.
•
Инкрементный рост. Пользователь может повысить производительность системы
путем добавления дополнительного процессора.
•
Масштабирование. Поставщики могут предложить широкий спектр продуктов
с различной ценой и производительностью, меняя количество процессоров, уста
новленных в системе.
Важно отметить, что это потенциальные, а не гарантируемые преимущества. Опера
ционная система должна предоставлять инструментарии и функции для эффективного
использования параллельности в SМР-системе.
Привлекательной особенностью
SMP
является то, что существование нескольких
процессоров является прозрачным для пользователя. Операционная система берет на
себя планирование заданий отдельных процессоров и синхронизацию между процессо
рами.
OpгalllПflt(UJI. На рис.
1.19
проиллюстрирована общая организация
SMP.
Имеется
несколько процессоров, каждый из которых содержит собственный блок управления,
арифметико-логическое устройство и регистры. Обычно каждый процессор имеет два
выделенных уровня кеша, обозначенные как
Микросхема
Кеш
Микросхема
Микросхема
·
·.Процессор
·. J
L 1 и L2.
Llj. ·.
: · j Кеш L2 j · : ·
Процессор
Процессор
• • •
. . j Кеш Ll r . .
KeшLlj'.
: ·1 Кеш L2j ·
KeшL2j. · ·
Системная шина
Основная
J
Контроллер
1
j ввода-вывода
Подсистема
память
ввода-вывод а
J
Контроллер . 1
j ввода-вывода
J
1
Рис.
1.19.
Организация
SMP
Контроллер . 1
ввода-вывода
·
1.8. ОРГАНИЗАЦИЯ МНОГОПРОЦЕССОРНЫХ И МНОГОЯДЕРНЫХ СИСТЕМ
Как показано на рис.
1.19,
69
каждый процессор и его кеши размещаются в отдельной
микросхеме. Каждый процессор имеет досrуп к общей основной памяти и устройствам
ввода-вывода посредством некоторого механизма взаимосвязи; общая шина является
совместно используемым объектом. Процессоры могут общаться друг с другом через па
мять (сообщения и информация о состоянии остаются в общем адресном пространстве).
Может также быть возможным непосредственный обмен процессоров сигналами. Па
мять часто организована так, что возможны несколько одновременных доступов к раз
ным блокам памяти.
В современных компьютерах процессоры, как правило, имеют по крайней мере один
уровень кеш-памяти, принадлежащий только данному процессору. Такое использование
кеша наводит на некоторые новые соображения относительно дизайна. Поскольку каж
дый локальный кеш содержит отражение части основной памяти, изменение слова в од
ном кеше может сделать недействительным слово в другом кеше. Для предотвращения
этого другие процессоры должны быть предупреждены, что имело место обновление.
Эта проблема известна как проблема согласованности кешей и обычно решается аппа
ратными средствами, а не операционной системой 6 .
Многоядерные компьютеры
Многоядерные компьютеры, известные также как компьютеры с несколькими про
цессорами в одной микросхеме
(chip multiprocessor),
сочетают в себе несколько процес
соров (так называемых ядер) в одном корпусе. Как правило, каждое ядро содержит все
компоненты независимого процессора, такие как регистры, арифметико-логическое уст
ройство (АЛУ), аппаратный конвейер и блок управления, а также кеш
L 1 команд
и дан
ных. Помимо нескольких ядер, современные многоядерные микросхемы содержат кеш
L2,
а в некоторых случаях
-
и кеш LЗ.
Мотивацию развития многоядерных компьютеров можно подытожить следующим
образом. На протяжении десятилетий микропроцессорные системы испытывали устой
чивое, практически экспоненциальное увеличение производительности. Это частично
обусловлено тенденциями развития аппаратных средств, такими как увеличение такто
вой частоты и возможность размещения кеш-памяти ближе к процессору из-за большей
степени миниатюризации компонентов микрокомпьютера. Производительность росла
также за счет повышенной сложности дизайна процессоров для использования парал
лелизма при выполнении команд и досrупа к памяти. Вкратце, проектировщики стол
кнулись с практическими ограничениями возможностей достижения большей произво
дительности с помощью более сложных процессоров и нашли, что наилучший способ
повышения производительности за счет аппаратных возможностей состоит в установке
нескольких процессоров и значительного объема кеш-памяти на одном чипе. Подробное
обсуждение этого вопроса выходит за рамки данной книги, но подытоживается в прило
жении В, "Дополнительные вопросы параллельности".
Примером многоядерной системы является
Intel Core i7-5960X, который включает
L2 и общим кешем LЗ
использованных Jntel, чтобы сделать кеши более эф
в себя восемь процессоров х86, каждый с выделенным кешем
(рис.
1.20, а).
фективными,
Один из механизмов,
-
предвыборка, nри которой оборудование изучает шаблон обращений к
памяти и пытается заполнить кеш данными, которые могут быть вскоре затребованы. На
рис.
1.20, б
показано физическое расположение компонентов процессора в микросхеме.
6 Описание вариантов аппаратного решения со1ласованности кешей имеется в [242).
70
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
Core i7-5960X
поддерживает две разновидности внешних коммуникаций с другими
схемами. Контроллер памяти
DDR4 обеспечивает двойную скорость передачи данных
DDR) между основной памятью и схемой. Интерфейс поддерживает
четыре канала шириной 8 байт мя общей ширины шины 256 бит со скоростью переда
чи данных до 64 Гбайт/с. При наличии контроллера памяти в чипе устраняется необхо
димость в шине Front Side Bus. PCI Express представляет собой периферийную шину
(douЫe
data rate -
и обеспечивает высокоскоростную связь между подключенными к процессору схемами.
PCI Express
работает на скорости
8 GT/s (8
тах на обмен скорость составляет до
Ядро
Ядро О
32
Кбайт
L\ -1
1
миллиардов обменов в секунду). При
Гбайт/с.
1
32
32
Кбайт
Кбайт
Кбайт
Ll -D
Ll-1
Ll-D
32
40
Ядро6
• • •
32
Кбайт
1
Ll-1
32
Ядро7
32
Кбайт
Кбайт
Ll-D
Ll-1
1
32
Кбайт
Ll -D
КешL2
КешL2
КешL2
КешL2
256Кбайт
256Кбайт
256 Кбайт
256 Кбайт
КешLЗ
20 Мбайт
Контроллеры
PCI Express
памяти DDR4
4
х
8 байт@2.133 GT/s
40 каналов @ 8 GT/s
а) Блок-схема
б) Физическое размещение на ш1ате
Рис.
1.20.
Блок-схема
lntel Core i7-5960X
40
би
1.9. КЛЮЧЕВЫЕ ТЕРМИНЫ, КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАЧИ
1.9.
71
КЛЮЧЕВЫЕ ТЕРМИНЫ,
КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАЧИ
Ключевые термины
Алгоритм замещения
Многопроцессорность
Системная шина
Блок
Многоядерность
Слот
Ввод-вывод
Основная память
Слот кеша
Ввод - вывод ,
Прерывание
Стек
Программируемый ввод-вывод
Схема микропроцессора
Пространственная локальность
Счетчик команд
Процессор
Указатель стека
Прямой доступ к памяти (ОМА)
Центральный процессор
Регистр
Цикл команды
управляемый прерываниями
Временная локальность
Вспомогательная память
Вторичная память
Иерархия памяти
Кадр стека
Кеш-память
Команда
Контроллер ввода-вывода
Регистр адреса
Регистр данных
Регистр команд
Результативность поиска
Контрольные вопросы
1.1.
Перечислите и кратко определите четыре основных элемента компьютера.
1.2.
Определите две основные категории регистров процессора.
1.3.
Каковы, в общих чертах, четыре различных действия, которые может указывать
машинная команда?
1.4.
Что такое прерывание?
1.5.
Как обрабатываются множественные прерывания?
1.6.
Какие характеристики отличают различные элементы иерархии памяти?
1.7.
Что такое кеш-память?
1.8.
В чем состоит разница между многопроцессорными и многоядерными системами?
1.9.
В чем состоит разница между пространственной и временной локальностью?
1.10.
Каковы в общем случае стратегии использования пространственной и временной
локальности?
72
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
Задачи
1.1.
Предположим, что в гипотетической машине, изображенной на рис.
1.3,
кроме ука
занных, имеются такие команды:
0011 -
загрузить в аккумулятор данные, поступившие от устройства ввода
вывода;
О 111
-
вывести содержимое аккумулятора на устройство ввода-вывода.
При использовании этих команд устройство идентифицируется с помощью 12-би
тового адреса. Изобразите схему выполнения (по аналогии со схемой, представлен
ной на рис.
1.4)
следующей программы.
1.
Загрузить аккумулятор данными из устройства номер
5.
2.
Добавить к аккумулятору содержимое ячейки памяти
940.
3.
Вывести содержимое аккумулятора на устройство номер
Решите задачу при условии, что из устройства номер
ке
1.2.
940
находится число
На рис.
1.4
поступит число
3,
а в ячей
2.
выполнение программы разбито на шесть этапов. Расширьте это описа
ние, добавив шаги с использованием регистров
1.3.
5
6.
MAR
и
MBR.
Рассмотрим гипотетический 32-битовый микропроцессор, 32-битовые команды
которого состоят из двух полей. В первом байте содержится код команды, а в ос
тальной части команды
-
непосредственно операнд или его адрес.
а. Какова максимально возможная емкость адресуемой памяти (в байтах)?
б.
Рассмотрите факторы, влияющие на скорость системы, если шина микро
процессора имеет
1)
32-битовую локальную адресную шину и 16-битовую
локальную шину данных или
2)
16-битовую локальную адресную шину и
16-битовую локальную шину данных.
в.
1.4.
Сколько битов требуется для счетчика команд и регистра команд?
Рассмотрим гипотетический микропроцессор, генерирующий 16-битовые адреса
(предположим, например, что счетчик команд и адресные регистры имеют размер
16
бит) и обладающий 16-битовой шиной данных.
а.
Какое максимальное адресное пространство памяти может быть непосредствен
но доступно этому процессору, если он соединен с "16-битовой памятью"?
б. Какое максимальное адресное пространство может быть непосредственно
доступно этому процессору, если он соединен с "8-битовой памятью"?
в.
Какие особенности архитектуры позволят этому микропроцессору получить
доступ к отдельному "пространству ввода-вывода"?
г.
Сколько портов ввода-вывода способен поддерживать этот микропроцессор,
если в командах ввода и вывода задаются 8-битовые номера портов? Сколь
ко портов ввода-вывода он может поддерживать с 16-битовыми портами?
Поясните свой ответ.
1.9. КЛЮЧЕВЫЕ ТЕРМИНЫ, КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАЧИ
1.5.
73
Рассмотрим 32-битовый микропроцессор с 16-битовой внешней шиной данных, ко
торая управляется синхронизатором с тактовой частотой
8
МГц. Пусть цикл шины
этого микропроцессора по длительности равен четырем циклам синхронизатора.
Какую максимальную скорость передачи данных может поддерживать этот процес
сор? Что будет лучше для повышения производительности: сменить его внешнюю
шину данных на 32-битовую или удвоить частоту сигнала синхронизатора, посту
пающего на микропроцессор? Внесите свое предложение и обоснуйте его.
Указание: определите количество байтов, которое может быть передано при каж
дом цикле шины.
1.6.
Рассмотрим компьютерную систему, в которой содержится контроллер ввода-выво
да, управляющий простейшим интерфейсом пользователя, представляющим собой
телетайп "клавиатура/принтер". В процессоре находятся следующие регистры, не
посредственно связанные с системной шиной:
INPR OUTR FGI FGO IEN -
регистр входных данных,
8
регистр выходных данных,
бит;
8
бит;
флаг входа,
флаг
1 бит;
выхода, 1 бит;
регистр разрешения прерываний,
1 бит.
Входной поток данных, поступающий от клавиатуры, и выходной, выводимый на
принтер, контролируются модулем ввода-вывода. Телетайп кодирует алфавитно-циф
ровые символы в 8-битовые слова и декодирует 8-битовые слова в алфавитно-цифро
вые символы. Флаг входа устанавливается при вводе 8-битового слова с телетайпа во
входной регистр; флаг выхода устанавливается при выводе слова на принтер.
а.
Опишите, как процессор может осуществлять ввод-вывод с телетайпа, ис
пользуя первые четыре перечисленных регистра.
б.
1.7.
Опишите, как это можно сделать более эффективно, используя регистр
IEN.
Практически во всех системах, в которые входят контроллеры ОМА, доступ ОМА
к основной памяти выполняется с более высоким приоритетом, чем доступ про
цессора. Почему?
1.8.
Контроллер ОМА передает символы из внешнего устройства в основную память со ско
ростью
9600
бит в секунду. Процессор может выбирать команды со скоростью
1 млн
команд в секунду. Насколько процессор замедлит свою работу из-за работы ОМА?
1.9
Компьютер состоит из процессора и устройства ввода-вывода
D,
подсоединенного
к основной памяти М через совместно используемую шину, которая используется
как шина данных и имеет ширину, равную одному слову. Максимальная произ
водительность процессора -
l 06 команд в секунду. Команда включает в себя в
среднем пять машинных циклов, для трех из которых используется шина памяти.
Операции чтения-записи в памяти включают в себя один машинный цикл. Пред
положим, что процессор все время выполняет программы в фоновом режиме, что
требует
95%
его производительности, а в самих программах не содержится ни од
ной команды ввода-вывода. Пусть длительность цикла процессора равна длитель
ности цикла шины.
74
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
Теперь представим, что между Ми
D
следует переслать очень большой блок дан
ных.
а.
Оцените максимальную скорость передачи данных при выполнении опера
ций ввода-вывода, которые могут пройти через
D,
при использовании про
граммируемого ввода-вывода, если для операции передачи одного слова тре
буется выполнение двух команд.
б.
1.10.
Оцените ту же скорость при передаче данных с использованием ОМА.
Рассмотрим следующий код.
for (i = О; i < 20; i++)
for ( j = О ; j < 1 О; j
=
a[i]
1.11.
*
a[i]
++)
j
а.
Приведите пример пространственной локальности этой последовательности.
б.
Приведите пример временной локальности этой последовательности.
Обобщите уравнения
( 1.1)
и
( 1.2)
из приложения к данной главе для п-уровневой
иерархической структуры памяти.
1.12.
Рассмотрим основную память (т) и кеш (с), характеризующиеся следующими па
раметрами:
~ =
Тт=
100 нс
1200 нс
се=
Ст=
а.
Сколько стоит
б.
Сколько стоит
1 Мбайт
1
0.01 цент/бит
0.001 цент/бит
основной памяти?
Мбайт основной памяти, выполненной по технологии
кеша?
в.
Какова результативность поиска Н, если эффективное время доступа на
10%
больше, чем время доступа к кешу?
1.13.
В компьютере есть кеш, основная память и диск, выступающий в роли виртуаль
ной памяти. Если запрашиваемое слово находится не в кеше, а в основной памяти,
для его загрузки в кеш требуется
60
нс (сюда входит время, которое требуется для
первоначальной проверки кеша). После этого происходит новый запрос. Если сло
ва нет в оперативной памяти, чтобы получить его с диска, необходимо затратить
12
мс, а затем еще
60
нс, чтобы скопировать его в кеш; после этого происходит но
вый запрос. Результативность поиска в кеше равна
в основной памяти
- 0.6.
0.9,
а результативность поиска
Найти среднее время, которое требуется для получения
доступа к слову в данной системе.
1.14.
Предположим, что при вызове процедур и возврате из них процессор использует
стек. Можно ли в такой схеме обойтись без счетчика команд, используя вместо
него вершину стека?
75
ПРИЛОЖЕНИЕ 1.д. ХАРАКТЕРИСТИКИ ПРОИЗВОДИТЕЛЬНОСТИ ДВУХУРОВНЕВОЙ ПАМЯТИ
ПРИЛОЖЕНИЕ 1.А. ХАРАКТЕРИСТИКИ
ПРОИЗВОДИТЕЛЬНОСТИ ДВУХУРОВНЕВОЙ ПАМЯТИ
В данной главе упоминался кеш, который выступает в роли промежуточного буфера
между процессором и основной памятью, что обеспечивает двухуровневую структуру
памяти. Производительность работы памяти с такой архитектурой выше, чем у одно
уровневой памяти. Это повышение производительности достигается за счет свойства,
известного как локальность
(locality),
которое и рассматривается в данном приложении.
Механизм кеширования основной памяти является составной частью компьютерной
архитектуры. Он встроен в аппаратное обеспечение и обычно невидим операционной
системе. Поэтому кеширование не рассматривается в данной книге. Однако есть еще
два примера использования двухуровневой памяти, в которых также используется ло
кальность и которые, по крайней мере частично, реализованы в операционной системе:
виртуальная память и дисковый кеш (см. табл.
смотрения глав
8,
"Виртуальная память", и
11,
1.2).
Эти темы являются предметом рас
"Управление вводом-выводом и плани
рование дисковых операций", соответственно. Данное приложение поможет читателю
познакомиться с некоторыми характеристиками производительности двухуровневой па
мяти, которые являются общими для всех трех подходов.
ТАБЛИЦА
1.2.
ХАРАКТЕРИСТИКИ ДВУХУРОВНЕВОЙ ПАМЯТИ
Кеш основной
памяти
Виртуальная
память (странич-
Дисковый кеш
ная организация)
5:1
106 :1
106 :1
Система управления
Специальное ветра-
Сочетание аппа-
Системное про-
памятью
енное аппаратное
ратного и програм-
граммное обеспе-
обеспечение
много обеспечения
чение
Типичный размер блока
От
От
От
Доступ процессора
Прямой доступ
Типичное соотношение
времени доступа
4 до 128 байт
64 до 4096
байт
Косвенный доступ
64
до
4096
байт
Косвенный доступ
ко второму уровню
Локальность
Основой для повышения производительности двухуровневой памяти является прин
цип локальности, о котором шла речь в разделе
1.5.
Этот принцип гласит, что после
довательные обращения к памяти имеют тенденцию собираться в группы (кластеры).
По истечении длительного периода времени один кластер сменяется другим, но на про
тяжении сравнительно небольших промежутков времени процессор преимущественно
работает с адресами, входящими в один и тот же кластер памяти. Интуитивно принцип
локальности имеет смысл. Рассмотрим следующую цепочку рассуждений.
1.
Команды программы выполняются последовательно, за исключением тех случаев,
когда встречаются команды ветвления или вызова (процедуры, функции и т.д.).
Поэтому в большинстве случаев команды из памяти извлекаются последователь
но, одна за другой в порядке их размещения.
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
76
2.
Длинная, не нарушаемая прерываниями последовательность вызовов процедур,
за которой идут соответствующие команды возврата, встречается довольно ред
ко. Другими словами, глубина вложенного вызова процедур остается небольшой.
Поэтому в течение короткого промежутка времени обращения, скорее всего, про
исходят к командам, которые находятся в небольшом числе процедур.
3.
Большинство итерационных конструкций состоят из сравнительно небольшого
числа многократно повторяющихся команд. Во время выполнения этих итераций
вычисления сосредоточены на небольшом локальном участке программы.
4.
Во многих программах значительная часть вычислений приходится на операции с
такими структурами данных, как массивы и последовательности записей. В боль
шинстве случаев данные, к которым происходит обращение, расположены близко
друг к другу.
Приведенные рассуждения подтверждаются многими исследованиями. Для проверки
1
утверждения
проводился разносторонний анализ поведения программ, составленных
на языках высокого уровня. Результаты измерений частоты появления различных ко
манд при выполнении программы, проведенные разными исследователями, представле
ны в табл.
1.3.
Одно из самых ранних исследований поведения языка программирования
(Knuth) [135], рассматривавшим различные программы на языке
FORTRAN, написанные студентами при выполнении практических заданий. Таненбаум
(Tanenbaum) [253] опубликовал результаты измерений, проведенных более чем на 300
проводилось Кнутом
процедурах, которые использовались при разработке операционных систем и были напи
саны на языке, поддерживающем структурное программирование. Паттерсон
Секвин
(Sequin) [185]
(Patterson)
и
провели анализ ряда измерений, выполненных над компиляторами,
ми сортировки данных и сравнения содержимого файлов (языки программирования С и
Pascal).
Хак
(Huck) [112]
проанализировал четыре программы, являющиеся типичными
примерами программ для проведения научных вычислений. Среди них были, в частнос
ти, программы для выполнения быстрого Фурье-преобразования и для решения системы
дифференциальных уравнений. Полученные результаты хорошо согласуются с утверж
дением, что ветвления и команды вызовов представляют собой лишь небольшую часть
всех команд, выполняющихся во время работы программы. Таким образом, проведенные
исследования подтверждают справедливость приведенного выше утверждения
ТАБЛИЦА
1.3.
1.
ОТНОСИТЕЛЬНАЯ ДИНАМИЧЕСКАЯ ЧАСТОТА РАЗЛИЧНЫХ ОПЕРАЦИЙ
ЯЗЫКОВ ВЫСОКОГО УРОВНЯ
Исследование
[112)
[185)
[135)
[253)
Язык
Pascal
FORTRAN
Pascal
с
SAL
Изучаемый
Научное
Студенческие
Системное
Системное
Системное
материал
по
работы
по
по
по
74
4
1
20
2
67
3
3
11
9
45
5
15
29
38
3
12
43
3
42
4
12
36
7
6
Присваивание
Цикл
Вызов
IF
GOTO
Другие
6
ПРИЛОЖЕНИЕ 1.д. ХАРАКТЕРИСТИКИ ПРОИЗВОДИТЕЛЬНОСТИ ДВУХУРОВНЕВОЙ ПАМЯТИ
Что касается утверждения
2,
77
то его справедливость подтверждается исследованиями,
результаты которых изложены в
[184].
Это проиллюстрировано на рис.
1.21,
где пока
зано поведение программы в разрезе используемых в ней вызовов процедур и возврата
из них. Каждый вызов представлен отрезком линии, идущим на одно деление вниз, а
каждый возврат
-
коридор шириной
в результате
6
отрезком, идущим на одно деление вверх. Весь график заключен в
5
делений. Этот коридор является подвижным, но сдвигается лишь
последовательных команд вызова или возврата. Из графика видно, что
программа во время своей работы может оставаться в стационарном коридоре на протя
жении достаточно длительного периода времени. Изучение программ, написанных на С
Пример поведения программы при вызове и возврате из процедур
В литературе различают пространственную и временную локальности. Пространс
твенная локальность означает преимущественное обращение к некоторому количеству
сгруппированных ячеек памяти. Это свойство отражает тенденцию процессора выпол
нять команды последовательно. Пространственная локальность свидетельствует также
о склонности программы обращаться к данным, которые находятся в последовательных
ячейках, как, например, при обработке данных, собранных в таблицу. Временная ло
кальность отражает тенденцию процессора обращаться к ячейкам памяти, к которым
недавно уже производился доступ. Например, при выполнении цикла итераций процес
сор многократно повторяет выполнение одного и того же набора команд.
Традиционно временная локальность используется путем сохранения недавно ис
пользованных команд и данных в кеш-памяти и использования иерархии кеша. Про
странственная локальность обычно используется путем применения больших блоков
кеша и включения механизма упреждающей выборки (выборка данных, использование
которых ожидается) в логику управления кешем. В последнее время наблюдается значи
тельная исследовательская работа по уточнению этих методов для достижения большей
производительности, но базовые стратегии остаются теми же.
ГЛАВА 1. ОБЗОР КОМПЬЮТЕРНОЙ СИСТЕМЫ
78
Функционирование двухуровневой памяти
Свойство локальности может быть использовано при разработке схемы двухуровневой
памяти. Память верхнего уровня (М 1) имеет меньшую емкость, она быстрее, и каждый
ее бит дороже по сравнению с памятью нижнего уровня (М2).
используется для вре
Ml
менного хранения определенной части содержимого более емкого уровня М2. При каж
дом обращении к памяти сначала предпринимается попытка найти нужные данные в М 1.
Если она завершается успехом, происходит быстрый доступ. В противном случае из М2
в
Ml
копируется нужный блок ячеек памяти, а затем снова осуществляется доступ к
MI.
В соответствии со свойством локальности к ячейкам памяти вновь перенесенного блока
произойдет еще ряд обращений, что приведет к общему ускорению работы программы.
Чтобы выразить среднее время доступа, нужно учитывать не только скорость работы
обоих уровней памяти, но и вероятность обнаружения требуемых данных в М 1. В ре
зультате получим
Т.
= HxJ; +(1-Н)х(Т. +I;)=Т. +(1-Н)хт;,
(1.1)
где
~
-
Т1 -
среднее (системное) время доступа,
время доступа к
Ml
(например, кешу, дисковому кешу),
Т2 - время доступа к М2 (например, основной памяти, диску),
Н
-
результативность поиска (доля ссылок на данные в М 1).
На рис.
1.15
показано среднее время доступа как функция результативности поиска.
При высокой результативности среднее время доступа намного ближе ко времени досту
па к М 1, чем ко времени доступа к М2.
Производительность
Рассмотрим некоторые параметры, характеризующие механизм двухуровневой памя
ти. Сначала рассмотрим стоимость, которая выражается следующим образом:
С = C1S1 +C2 S2
"
S1 +S2
,
(1.2)
где
С5
-
средняя стоимость одного бита двухуровневой памяти,
С1 -
средняя стоимость одного бита памяти верхнего уровня
С2 -
средняя стоимость одного бита памяти нижнего уровня М2,
S1
S2
-
емкость
-
емкость М2.
MI,
MI,
Желательно добиться соотношения С5 :;:,,С 2 • При условии С 1 »С 2 для этого требует
ся, чтобы выполнялось условие
рис. 1.22 7.
7 Обр~пите
S 1 «S2•
Получающаяся зависимость представлена на
внимание, что для обеих осей выбрана логарифмическая шкала. Обзор основных сведений
по логарифмическим шкалам приведен в сборнике документов для повторения м~пематики, который
находится на сайте
Computer Science Studeпt Resource Site по адресу CornputerScienceStudent .corn.
ПРИЛОЖЕНИЕ 1.д. ХАРАКТЕРИСТИКИ ПРОИЗВОДИТЕЛЬНОСТИ ДВУХУРОВНЕВОЙ ПАМЯТИ
79
1000
,-..,
(С1/С2)
= 1000
(С/С2 )
= 100
r,J
~
.а
.......
=
:.:
=
=
.......
100
=
~
=
.а
о:
"...
....
=
=
=
10
5
5
6
7 8
910
5
6
7 8
s
9100
ОтноситеJ1ьная емкость двух уровнеii
Рис.
1.22.
6
7 R
1ООО
(S1/S1)
Зависимость средней стоимости двухуровневой памяти
от относительной емкости уровней
Теперь рассмотрим время доступа. Для высокой производительности двухуровневой
памяти необходимо, чтобы выполнялось условие ~;:::; Т 1 • Поскольку обычно Т 1 «Т2 , нуж
но, чтобы результативность поиска была близка к 1.
Таким образом, мы хотим, чтобы уровень
Ml
обладал малой емкостью (что позво
лило бы снизить стоимость), но был достаточно большим для того, чтобы повысить ре
зультативность поиска и как следствие производительность. Можно ли так подобрать
размер М 1, чтобы в определенной степени он удовлетворял обоим требованиям? Этот
вопрос можно разбить на несколько подвопросов.
Какая емкость М 1 даст гарантию достижения требуемойрезультативности поиска?
•
Будет ли эта емкость иметь приемлемую стоимость?
Чтобы ответить на эти вопросы, рассмотрим величину Т/7;;. которая называется эф
фективностью доступа. Она является мерой того, насколько среднее время доступа ~
отличается от времени доступа Т 1 к М
~
Т,
На рис.
1.23
1.
Из уравнения
( 1.1)
находим
(1.3)
1+(1-Н)!-'7;
представлен график зависимости Т 1 1~ от результативности поиска Н при
разных значениях параметра Т2 /Т 1 . Чтобы удовлетворить требованиям эффективности,
похоже, величина результативности поиска должна находиться в пределах от
Эффективность доступа в зависимости от результативности поиска
Теперь вопрос об относительной емкости памяти можно сформулировать более точ
но. Можно ли при условии
значения
0,8
S1 «S2
добиться, чтобы результативность поиска достигала
или превышала его? Это зависит от нескольких факторов, в число которых
входят вид используемого программного обеспечения и детали устройства двухуровне
вой памяти. Основное влияние, конечно, оказывает степень локальности. На рис.
1.24
показано, какое влияние оказывает локальность на результативность поиска. Очевидно,
что если емкость уровня
1.0,
Ml
равна емкости уровня М2, то результативность поиска будет
поскольку все содержимое М2 находится в
Ml.
Теперь предположим, что нет ни
какой локальности, т.е. все обращения происходят в случайном порядке. В этом случае
результативность поиска линейно зависит от относительного размера памяти. Например,
если объем М 1 равен половине объема М2, то в любой момент времени на уровне М 1
находится ровно половина всех данных уровня М2, и результативность поиска равна
0,5.
Однако на практике проявляется эффект локальности обращений. На графике показано
влияние локальности средней и сильной степени.
Таким образом, сильная локальность позволяет достичь высокой результативности
поиска даже при сравнительно небольших объемах памяти верхнего уровня. Например,
многочисленные исследования подтверждают, что при сравнительно небольшом размере
кеша результативность поиска превышает О, 75 независимо от размера основной памя
ти
([1], [195], [246]
и
[234]).
В то время как типичный размер основной памяти в наши
дни составляет гигабайты, вполне достаточным является кеш, емкость которого лежит в
пределах от
1 тысячи
до
128
тысяч слов. При рассмотрении виртуальной памяти и дис
кового кеша можно сослаться на другие исследования, подтверждающие справедливость
такого же утверждения, а именно
-
благодаря локальности относительно малый размер
М 1 обеспечивает высокую результативность поиска.
ПРИЛОЖЕНИЕ 1.д. ХАРАКТЕРИСТИКИ ПРОИЗВОДИТЕЛЬНОСТИ ДВУХУРОВНЕВОЙ ПАМЯТИ
81
0,8
~
у
=
=
=
.а 0,6
~
=
llQ
;=
!;; 0,4
Локальность
~
отсутствует
~
~
0,2
0,0 -----.-------.-----.-------.--------1
1,0
0,8
0,6
0,4
0,2
0,0
Оrносительный размер памяти (S1/S2)
Рис.
1.24.
Результативность поиска в зависимости от относительного
размера памяти
Теперь можно перейти к последнему из перечисленных ранее вопросов: удовлетворя
ет ли относительный размер двух уровней памяти требованиям стоимости? Ответ очеви
ден: да. Если для повышения производительности достаточно добавить верхний уровень
сравнительно небольшой емкости, то средняя стоимость обоих уровней в расчете на
один бит будет лишь немного превосходить стоимость бита более дешевой памяти вто
роrо уровня. Обратите внимание, что проведенный анализ при наличии кеша
L2 и LЗ) становится
[188) и [101).
более при наличии кешей
суждение приведено в
L2
(и тем
гораздо более сложным. Подробное об
("ЛАВ-А
ОБЗОР
ОПЕРАЦИОННЫХ СИСТЕМ
В ЭТОЙ ГЛАВЕ ...
2.1.
Цели и функции операционных систем
Операционная система как интерфейс между пользователем и компьютером
Операционная система как диспетчер ресурсов
Простота развития операционной системы
2.2.
Эволюция операционных систем
Последовательная обработка
Простые пакетные системы
Многозадачные пакетные системы
Системы, работающие в режиме разделения времени
2.3.
Основные достижения
Процессы
Управление памятью
Защита информации и безопасность
Планирование и управление ресурсами
2.4. Разработки, ведущие к современным операционным системам
2.5. Отказоустойчивость
Фундаментальные концепции
Отказы
Механизмы операционных систем
2.6. Вопросы проектирования операционных систем
для многопроцессорных и многоядерных систем
Операционные системы для
SMP
Вопросы проектирования операционных систем для многоядерных систем
Параллелизм в приложениях
Виртуальная машина
84
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
2.7. Обзор операционной системы Microsoft Windows
Основы
Архитектура
Организация операционной системы
Процессы пользовательского режима
Модель "клиент/сервер"
Потоки и симметричная многопроцессорность
Объекты
Windows
2.8. Традиционные системы UNIX
Историческая справка
Описание
2.9. Современные системы UNIX
System V Release 4 (SVR4)
BSD
Solaris 11
2.10. Liпux
История
Модульная структура
Компоненты ядра
2.11. Aпdroid
Программная архитектура
Android
Приложения
Каркас приложений
Системные библиотеки
Ядро
Linux
Система времени выполнения
Виртуальная машина
Формат
Android
Dalvik
Dex
Концепции
Android Runtime
Преимущества и недостатки
Системная архитектура
Android
Операции
Управление электропитанием
2.12.
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
2. 1. ЦЕЛ И И ФУН КЦ ИИ О ПЕРАЦИ О НН Ы Х С И СТЕМ
85
УЧЕБНЫЕ ЦЕЛИ
•
•
Понимать ключевые высокоуровневые функции операционных систем.
Обсудить эволюцию операционных систем от ранних простых пакетных систем до
современных сложных операционных систем .
•
Дать краткие пояснения каждого из основных достижений в области изучения опе
рационных систем.
•
Обсудить ключевые области, сыгравшие особую роль в развитии современных опе
рационных систем.
•
•
Определить и обсудить виртуальные машины и виртуализацию.
Понимать вопросы проектирования операционных систем, связанные с многопроцессорными и многоядерными системами.
•
Понимать базовую структуру Windows.
•
Описать основные элементы традиционных Uniх-систем.
•
Пояснить новые функциональные возможности современных Uпiх-систем.
•
Обсудить операционную систему Liпux и ее взаимосвязь с Uпix.
Мы начинаем изучение операционных систем с краткого обзора истории развития
операционных систем. Эта история интересна как сама по себе, так и как обзор при
нципов построения операционных систем . В первом разделе изучаются цели и функции
операционных систем. Затем рассматривается эволюция операционных систем от при
митивных пакетных систем до сложных многозадачных многопользовательских систем.
Оставшаяся часть главы представляет собой обзор истории и характеристик двух опера
ционных систем, которые служат в этой книге в качестве примеров.
2.1.
ЦЕЛИ И ФУНКЦИИ ОПЕРАЦИОННЫХ СИСТЕМ
Операционная система
-
это программа , контролирующая выполнение прикладных
программ и исполняющая роль интерфейса между приложениями и аппаратным обеспе
чением компьютера. Ее предназначение можно разделить на три основные составляю
щие.
•
Удобство . Операционная система делает использование компьютера простым и
удобным.
•
Эффективность. Операционная система позволяет эффективно использовать ре
сурсы компьютерной системы.
•
Возможность развития. Операционная система должна быть организована так ,
чтобы допускать эффективную разработку, тестирование и внедрение новых при
ложений и системных функций, причем это не должно мешать нормальному фун
кционированию вычислительной системы.
Рассмотрим поочередно все три аспекта работы операционных систем .
ГЛАВА 2. ОБЗОР ОП ЕРАЦИОННЫХ СИСТЕМ
86
Операционная система как интерфейс
между пользователем и компьютером
На рис .
2.1
представлена "слоистая " структура программного и аппаратного обес
печения , использующегося для
предоставления конечному пользователю возможности
работы с приложениями . Конечный пользователь обычно не интересуется деталями
устройства аппаратного обеспечения компьютера. Компьютер видится ему как набор
приложений. Приложение можно написать на каком-то из языков программирования;
эту задачу выполняют прикладные программисты. Если бы кто-то задумал разработать
реализованную в виде набора машинных команд программу, которая полностью отвеча
ет за управление аппаратным обеспечением компьютера, то это оказалось бы слишком
сложной задачей. Чтобы ее упростить, имеется набор системных программ , некоторые
из которых называются утилитами или библиотечными программами. С их помощью
реализуются часто использующиеся функции, которые помогают при создании пользо
вательских программ , работе с файлами и управлении устройствами ввода-вывода. Про
граммист использует эти средства при разработке собственных программ, а приложения
во время выполнения обращаются к утилитам для выполнения определенных функuий.
Наиболее важной из системных программ является операционная система, которая
скрывает от программиста детали аппаратного обеспечения и предоставляет ему удоб
ный интерфейс для использования системы. Операционная система выступает в роли
посредника, облегчая программисту и программным приложениям доступ к различным
службам и возможностям.
Интерфейс прикладного
программирования
Бинарный интерфейс
Прикладные программы
Программное
Библиотеки/утилиты
обеспечение
приложения
Операционная система
Архитектура
набора команд
-
Исполняющее аппаратное
обеспечение
Трансляция
Системное
соединение (шина)
Устройства
ввода-вывода
и сети
Рис.
2.1.
памяти
Аппаратное
обеснечение
Основная
память
Структура программного и аппаратного обеспечения компьютера
Приведем краткий список услуг, предоставляемых типичными операционными сис
темами.
•
Разработка программ. Содействуя программисту при разработке программ, опера
ционная система предоставляет ему разнообразные инструменты и службы, напри
мер редакторы или отладчики. Обычно эти службы реализованы в виде программ
утилит, которые поддерживаются операционной системой, хотя и не входят в ее ядро.
Такие программы называются инструментами разработки прикладны х программ .
2. 1. ЦЕЛИ И ФУНКЦИИ ОПЕРАЦИОННЫХ СИСТЕМ
•
87
Выполнение программ. Для выполнения программы требуется совершить ряд
действий. Следует загрузить в основную память команды и данные, инициали
зировать устройства ввода-вывода и файлы, а также подготовить другие ресурсы.
Операционная система выполняет всю эту рутинную работу вместо пользователя.
•
Доступ к устройствам ввода-вывода. Для управления работой каждого устройс
тва ввода-вывода нужен свой особый набор команд или контрольных сигналов.
Операционная система предоставляет пользователю единообразный интерфейс,
который скрывает все эти детали и обеспечивает программисту доступ к устройс
твам ввода-вывода с помощью простых команд чтения и записи.
•
Контролируемый доступ к файлам. При работе с файлами управление со сторо
ны операционной системы предполагает не только глубокое понимание природы
устройств ввода-вывода (дисковода, лентопротяжного устройства), но и знание
структур данных, записанных в файлах. Многопользовательские операционные
системы, кроме того, могут обеспечивать работу механизмов защиты при обраще
нии к файлам.
•
Системный доступ. Операционная система управляет доступом к совместно ис
пользуемой или общедоступной вычислительной системе в целом, а также к отде
льным системным ресурсам. Она должна обеспечивать защиту ресурсов и данных от
несанкционированного использования, а также разрешать конфликтные ситуации.
•
Обнаружение ошибок и их обработка. При работе компьютерной системы мо
гут происходить разнообразные сбои. К их числу относятся внутренние и вне
шние ошибки, возникшие в аппаратном обеспечении (например, ошибки памяти,
отказ или сбой устройств). Возможны и различные программные ошибки (такие,
как арифметическое переполнение, деление на нуль, попытка обратиться к ячей
ке памяти, доступ к которой запрещен, или невозможность выполнения запроса
приложения). В каждом из этих случаев операционная система должна выполнить
действия, минимизирующие влияние ошибки на работу приложения. Реакция опе
рационной системы на ошибку может быть различной
-
от простого сообщения
об ошибке до аварийного останова программы, вызвавшей ее.
•
Учет использования ресурсов. Хорошая операционная система должна иметь
средства учета использования различных ресурсов и отображения параметров
производительности. Эта информация крайне важна в любой системе, особенно
в связи с необходимостью дальнейших улучшений и настройки вычислительной
системы мя повышения ее производительности. В многопользовательских систе
мах эта информация может применяться мя выставления счетов.
На рис.
2.1
также показаны три ключевых интерфейса типичной вычислительной
системы.
•
Структура системы команд
(instruction set architecture -
ISA).
Определяет набор
команд машинного языка, которые может выполнять компьютер. Этот интерфейс
является границей между аппаратным и программным обеспечением. Обратите вни
мание, что и прикладные программы, и утилиты могут получить непосредственный
доступ к
ISA).
ISA.
Для этих программ доступно подмножество команд (пользовательская
Операционная система имеет доступ к дополнительным командам машинного
языка, которые относятся к управлению ресурсами системы (системная
ISA).
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
88
•
Бинарный интерфейс приложения
(application
Ьinary
interface -
ределяет стандарт бинарной переносимости между программами.
ABI). ABI оп
ABI определяет
интерфейс системных вызовов операционной системы и аппаратных ресурсов и
служб, доступных в системе через пользовательскую
•
Интерфейс прикладного программирования
face -
ISA.
(application programming inter-
АР!). АР! обеспечивает программе доступ к аппаратным ресурсам и служ
бам, доступным в системе через пользовательскую
ISA
с библиотечными вызо
вами на языке высокого уровня. Обычно любые системные вызовы выполняются
через библиотеки. Применение АР! обеспечивает легкую переносимость приклад
ного программного обеспечения на другие системы, поддерживающие тот же АР!,
путем перекомпиляции.
Операционная система как диспетчер ресурсов
Операционная система ответственна за управление использованием ресурсов ком
пьютера, таких как ввод-вывод, основная и вторичная память и время работы процес
сора. Обычно мы представляем себе управляющий механизм как нечто внешнее по от
ношению к тому, чем он управляет, или по крайней мере как нечто отличающееся от
управляемой системы или являющееся ее отдельной частью. (Например, система отоп
ления жилых помещений управляется термостатом, который реализован в виде отде
льного узла и отличается от аппаратуры выделения и распределения тепла.) С операци
онной системой дело обстоит по-другому, так как этот управляющий механизм является
необычным в двух отношениях.
•
Функции операционной системы работают точно так же, как и все остальное про
граммное обеспечение, т.е. они реализованы в виде отдельных программ или на
бора программ, исполняющихся процессором.
•
Операционная система часто передает управление другим процессам и должна
ожидать, когда процессор снова позволит ей выполнять свои обязанности.
Как и любая другая программа, операционная система состоит из команд, выполня
емых процессором. Во время работы операционная система указывает процессору, как
использовать другие системные ресурсы и как распределять время при исполнении дру
гих программ. Но для того, чтобы реализовать действия, предписываемые операционной
системой, процессор должен приостановить работу с ней и перейти к выполнению дру
гих программ. Таким образом, операционная система уступает управление процессору,
чтобы он смог выполнить некоторую "полезную" работу, а затем возобновляет контроль
ровно настолько, чтобы подготовить процессор к следующей части работы. Прочитав
данную главу, читатель должен получить отчетливое представление о механизмах, при
нимающих участие в этих процессах.
На рис.
2.2
показаны основные ресурсы, которыми управляет операционная система.
Часть операционной системы находится в основной памяти. В эту часть входит ядро
(kemel, nucleus),
содержащее основную часть наиболее часто используемых функций;
там же находятся и некоторые другие компоненты операционной системы, использую
щиеся в данный момент времени. Остальная используемая часть основной памяти со
держит другие программы и данные пользователя. Вскоре читатель сможет убедиться,
что размещение этих данных в основной памяти управляется совместно операционной
системой и аппаратной частью процессора, предназначенной для управления памятью.
2. 1. ЦЕЛИ И ФУНКЦИИ ОПЕРАЦИОННЫХ СИСТЕМ
89
Операционная система принимает решение, когда исполняющаяся программа может ис
пользовать нужные ей устройства ввода-вывода, и управляет доступом к файлам и их
использованием. Процессор сам по себе также является ресурсом, поэтому операцион
ная система должна определить, сколько времени он должен уделить исполнению той
или иной пользовательской программы.
Компьютерная система
Устройства
ввода-вы вода
Память
Контроллер i+.~--------i
Программное
П р интеры,
ввода-вывода
обеспечение
операционной
клав иатуры ,
циф ровые
Контроллер ~1----------+-1
системы
камеры и т.п .
ввода - вывода
•
•
•
Программы
и данные
•
•
•
Контроллер ~1---------~
ввода-вывода
/
/
/
/
/
Процессор
•••
/
Процессор
/
/
1
Внешняя
1
1
1
1
1
1
1
1
1
память
1
Операцион ная
система
Рис.
2.2.
Операционная система как диспетчер ресурсов
Простота развития операционной системы
Большинство операционных систем постоянно развиваются. Происходит это в силу
следующих причин.
•
Обновление и возникновение новых видов аппаратного обеспечения. Напри
мер, ранние версии операционных систем
UNIX
и
Macintosh OS
не использовали
механизмы страничной организации памяти, потому что они работали на маши
нах, не обеспеченных соответствующими аппаратными средствами 1• Более поз
дние версии операционных систем были доработаны таким образом, чтобы они
могли использовать новые аппаратные возможности . Точно так же на устройство
операционных систем повлияло использование графических терминалов и терми
налов, работающих в страничном режиме, вместо алфавитно-цифровых термина
лов с построчной разверткой. Такой терминал позволяет пользователю работать
1 Краткое рассмотрение страничной организации памяти nриведеfю в последующих разделах дан
7, "Управление 11амятыо".
ной ~лавы; более подробно 1ТОТ материал изложен в главе
90
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
одновременно с несколькими приложениями в различных окнах экрана. Такая воз
можность требует более сложной поддержки со стороны операционной системы.
•
Новые сервисы. Для удовлетворения требований пользователей или нужд систем
ных администраторов операционные системы предоставляют новые возможности.
Например, если станет трудно поддерживать высокую производительность при
работе с имеющимся на определенный момент инструментарием пользователя, в
операционную систему могут быть добавлены новые инструменты для контроля и
оценки производительности.
•
Исправления. В каждой операционной системе есть ошибки. Время от времени
они обнаруживаются и исправляются. Конечно, в исправление могут вкрасться но
вые ошибки.
Необходимость регулярных изменений операционных систем накладывает опреде
ленные требования к их устройству. Очевидно, что эти системы должны иметь модуль
ную конструкцию с четко определенным взаимодействием модулей; очень важную роль
играет хорошая и полная документированность. Для больших программ, которыми на
сегодняшний день являются типичные операционные системы, недостаточно выполнить
то, что называется непосредственной модуляризацией
[64];
нужно сделать нечто боль
шее, чем простая разбивка целой программы на отдельные подпрограммы. В данной
главе мы вернемся к этому вопросу.
2.2.
Эволюция ОПЕРАЦИОННЫХ СИСТЕМ
Пытаясь понять основные требования, предъявляемые к операционным системам, а
также значение основных возможностей современных операционных систем, полезно
проследить за их эволюцией, происходившей на протяжении многих лет.
Последовательная обработка
В первых компьютерах, в период от конца 1940-х до средины 1950-х годов, програм
мы непосредственно взаимодействовали с аппаратным обеспечением машины; опера
ционных систем в то время еще не было. Эти компьютеры управлялись с пульта уп
равления, состоящего из сигнальных ламп, тумблеров, некоторого устройства для ввода
данных и принтера. Программы в машинных кодах загружались через устройство вво
да данных (например, устройство ввода с перфокарт). Если из-за ошибки происходил
останов программы, о возникновении сбойной ситуации свидетельствовали аварийные
сигнальные лампы. Чтобы определить причину ошибки, программист должен был про
верить состояние регистров процессора и основной памяти. Если программа успешно
завершала свою работу, ее выходные данные распечатывались на принтере. Эти ранние
системы имели две основные проблемы.
•
Расписание работы. На большинстве машин нужно было предварительно заказать
машинное время, записавшись в специальный график. Обычно пользователь мог
заказать время, кратное некоторому периоду, например получасу. Тогда, записав
шись на
1 час,
он мог закончить работу за
45
минут, что приводило к простою ком
пьютера. С другой стороны, если пользователь не укладывался в отведенное время,
он должен был прекращать работу, прежде чем задача завершит выполнение.
2.2. Эволюция ОПЕРАЦИОННЫХ СИСТЕМ
•
91
Время подготовки к работе. Для запуска каждой программы, называемой зада
нием
Gob ),
нужно было загрузить в память компилятор и саму программу, обычно
составленную на языке высокого уровня (исходный текст), сохранить скомпилиро
ванную программу (объектный код), а затем загрузить и скомпоновать объектный
код с библиотечными функциями. Для каждого из этих этапов могли понадобиться
установка и съем магнитных лент или загрузка колоды перфокарт. При возник
новении фатальной ошибки беспомощному пользователю не оставалось ничего
другого, как начинать весь подготовительный процесс заново. Таким образом,
значительное время затрачивалось лишь на то, чтобы подготовить программу к
собственно исполнению.
Такой режим работы можно назвать последовательной обработкой
(serial processing).
Это название отражает тот факт, что пользовательские программы выполнялись на ком
пьютере последовательно. Со временем в попытке повысить эффективность последо
вательной обработки были разработаны различные системные инструменты. К ним
относятся библиотеки функций, редакторы связей, загрузчики, отладчики и драйверы
ввода-вывода, существующие в виде программного обеспечения, общедоступного для
всех пользователей.
Простые пакетные системы
Ранние машины были очень дорогими, поэтому было важно использовать их как
можно эффективнее. Простои, происходившие из-за несогласованности расписания, а
также время, затраченное на подготовку задачи,
-
все это обходилось слишком дорого;
эти непроизводительные затраты были непозволительной роскошью.
Чтобы повысить эффективность работы, была предложена концепция пакетной опе
рационной системы. Похоже, первые пакетные операционные системы (и вообще пер
вые операционные системы какого бы то ни было типа) были разработаны в средине
1950-х годов в компании
General Motors
для машин \ВМ
701 [266].
Впоследствии эта
концепция была усовершенствована и внедрена рядом пользователей на JВМ
704.
В на
чале 1960-х годов некоторые поставщики разработали пакетные операционные системы
для своих компьютеров. Одной из заметных систем того времени является IВSYS фир
мы \ВМ, разработанная для компьютеров
7090/7094
и оказавшая значительное влияние
на другие системы.
Центральная идея, лежащая в основе простых пакетных схем обработки, состоит в
использовании программы, известной под названием монитор
(monitor).
Используя опе
рационную систему такого типа, пользователь не имеет непосредственного доступа к
машине. Вместо этого он передает свое задание на перфокартах или магнитной ленте
оператору компьютера, который собирает разные задания в пакеты и помещает их в уст
ройство ввода данных. Так они передаются монитору. Каждая программа составлена та
ким образом, что при завершении ее работы управление переходит к монитору, который
автоматически загружает следующую программу.
Чтобы понять работу этой схемы, рассмотрим ее с точки зрения монитора и процес
сора.
•
Работа схемы с точки зрения монитора. Монитор управляет последовательнос
тью событий. Чтобы это было возможно, большая его часть должна всегда нахо
диться в основной памяти и быть готовой к работе (рис.
2.3).
Эту часть монитора
92
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
называют резидентным монитором. Оставшуюся часть составляют утилиты и об
щие функции, которые загружаются в виде подпрограмм, вызываемых программой
пользователя в начале выполнения каждого задания (если они для него требуют
ся). Монитор считывает с устройства ввода данных (обычно это устройство ввода
с перфокарт или магнитная лента) по одному заданию. При этом текущее задание
размещается в области памяти, предназначенной для программ пользователя, и
ему передается управление. По завершении задания оно возвращает управление
монитору, который сразу же начинает считывать следующее задание. Результат ис
полнения каждого задания направляется на устройство вывода, например на прин
тер для передачи пользователю.
Обработка
прерываний
Драйверы
устройств
Монитор
Обработка
последовательности
заданий
Граница
монитора
----
Интерпретатор
языка управления
Область программ
пользователей
Рис.
•
2.3.
Схема размещения резидентного монитора в памяти
Работа схемы с точки зрения процессора. В некоторый момент времени процес
сор выполняет команды, которые находятся в той части основной памяти, которую
занимает монитор. Это приводит к тому, что в другую область памяти считывается
новое задание. После того как задание полностью считано, монитор отдает про
цессору команду перехода, по которой он должен начать исполнение программы
пользователя. Процессор переходит к обработке программы пользователя и вы
полняет ее команды до тех пор, пока не дойдет до конца или пока не возникнет
сбойная сиrуация. В любом из этих двух случаев следующей командой, которую
процессор извлечет из памяти, будет команда монитора. Таким образом, фраза
"контроль передается заданию" означает, что процессор перешел к извлечению и
выполнению команд программы пользователя. Фраза же "контроль возвращается
монитору" означает, что теперь процессор извлекает из памяти и выполняет ко
манды монитора.
2.2. Эволюция ОПЕРАЦИОННЫХ СИСТЕМ
93
Как видите, монитор выполняет функцию планирования: задания в пакетах выстра
иваются в очередь и выполняются без простоев настолько быстро, насколько это воз
можно. Кроме того, монитор помогает в подготовке программы к исполнению. В каждое
задание включаются простые команды языка управления заданиями
guage -
JCL).
Gob control lan-
Это специальный тип языка программирования, используемый для того,
чтобы отдавать команды монитору. Рассмотрим простой пример, в котором нужно при
нять на обработку программу пользователя; составленную на языке
FORTRAN, и до
FORTRAN
полнительные данные, используемые этой программой. Все команды языка
и данные находятся на отдельных перфокартах или в отдельных записях на магнитной
ленте. Каждое задание, кроме операторов языка
FORTRAN
и данных, содержит команды
управления заданием, каждая из которых начинается знаком
$.
Формат задания в целом
выглядит следующим образом.
$JOB
$FTN
}
Команды
}
Д~ные
FORTRAN
$LOAD
$RUN
$END
Чтобы выполнить это задание, монитор читает строку
$ FTN
и загружает с запомина
ющего устройства большой емкости (обычно это лента) компилятор соответствующего
языка. Компилятор преобразует программу пользователя в объектный код, который запи
сывается в память или на запоминающее устройство. Если этот код заносится в память,
то операция называется "компиляция, загрузка и запуск". Если же он записывается на
магнитную ленту, то нужна дополнительная команда
$LOAD.
Монитор, к которому вер
нулось управление после компиляции, читает эту команду и обращается к загрузчику,
который загружает объектную программу в память (на место компилятора) и передает
ей управление. В таком режиме различные подсистемы совместно используют один и
тот же участок основной памяти, хотя в каждый момент времени работает только одна
из этих подсистем.
Во время выполнения программы пользователя по каждой команде ввода считыва
ется только одна строка данных. Команда ввода программы пользователя обращается к
подпрограмме ввода, которая является составной частью операционной системы. Под
программа ввода проверяет, не произошло ли случайное считывание строки языка
JCL.
Если это произошло, управление передается монитору. По завершении задания пользо
вателя монитор проверяет строки задания, пока не дойдет до строки с командой на язы
ке управления, что защищает систему от программ, в которых оказалось слишком много
или слишком мало строк с данными.
94
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Таким образом, монитор, или пакетная операционная система,
-
это обычная ком
пьютерная программа. Ее работа основана на способности процессора выбирать коман
ды из различных областей основной памяти; при этом происходит передача и возврат
управления. Желательно также использование и других возможностей аппаратного обес
печения.
•
Защита памяти. Во время работы программа пользователя не должна вносить
изменения в область памяти, в которой находится монитор. Если же такая попытка
предпринята, аппаратное обеспечение процессора должно обнаружить ошибку и
передать управление монитору. Затем монитор снимет задачу с выполнения, рас
печатает сообщение об ошибке и загрузит следующее задание.
•
Таймер. Таймер используется для того, чтобы предотвратить ситуацию, когда одна
задача захватывает безраздельный контроль над системой. Таймер выставляется в
начале каждого задания. По истечении определенного промежутка времени про
грамма пользователя останавливается и управление передается монитору.
•
Привилегированные команды. Некоторые команды машинного уровня имеют
повышенные привилегии и могут выполняться только монитором. Если процес
сор
натолкнется
на такую команду во время исполнения программы
пользовате
ля, возникнет ошибка, при которой управление будет передано монитору. В число
привилегированных команд входят команды ввода-вывода; это значит, что все уст
ройства ввода-вывода контролируются монитором. Это, например, предотвращает
случайное чтение программой пользователя команд управления, относящихся к
следующему заданию. Если программе пользователя нужно произвести ввод-вы
вод, она должна запросить для выполнения этих операций монитор.
•
Прерывания. В первых моделях компьютеров этой возможности не было. Она
придает операционной системе большую гибкость при передаче управления про
грамме пользователя и его возобновлении.
Вопросы защиты памяти и привилегированных команд памяти приводят к концепции
режимов работы. Программа пользователя выполняется в пользовательском режиме,
в котором определенные области памяти защищены от использования пользователем и
некоторые команды не могут быть выполнены. Монитор работает в системном режиме,
позже названном режимом ядра, в котором могут выполняться привилегированные ко
манды и могут быть доступными защищенные области памяти.
Конечно, операционную систему можно разработать и без учета описанных выше
возможностей. Однако поставщики компьютеров скоро поняли, что это приведет к хао
су, поэтому даже сравнительно простые пакетные операционные системы использовали
эти возможности аппаратного обеспечения.
При работе пакетных операционных систем машинное время распределялось между
исполнением программы пользователя и монитора. При этом в жертву приносились два
вида ресурсов: монитор занимал некоторую часть оперативной памяти, им же потреб
лялось некоторое машинное время. И то, и другое приводило к непроизводительным
издержкам. Несмотря на это простые пакетные системы существенно повышали эффек
тивность использования компьютера.
95
2.2. Эволюция ОПЕРАЦИОННЫХ СИСТЕМ
Многозадачные пакетные системы
Процессору часто приходилось простаивать даже при автоматическом выполнении
заданий под управлением простой пакетной операционной системы. Проблема заклю
чается в том, что устройства ввода-вывода работают намного медленнее, чем процес
сор. На рис.
2.4
представлены соответствующие расчеты, выполненные для программы,
которая обрабатывает файл с записями, причем для обработки одной записи требуется
в среднем
100
машинных команд. В этом примере
96%
всего времени процессор ждет,
пока устройства ввода-вывода закончат передачу данных в файл и из него. На рис.
2.5, а
показана такая ситуация для одной программы. Некоторое время процессор выполняет
команды; затем, дойдя до команды ввода-вывода, он должен подождать, пока она закон
чится. Только после этого процессор сможет продолжить работу.
Чтение одной записи из файла
Внесение одной записи в файл
15 мкс
1 мкс
15 мкс
Всего
31
Выполнение
100 машинных
команд
Степень использования процессора
Рис.
2.4.
мкс
-1 = 0,032 = 3,2%
31
Пример использования системы
Эффективность использования процессора можно повысить. Мы знаем, •по памяти
должно хватить, чтобы разместить в ней операционную систему (резидентный монитор)
и программу пользователя. Предположим, что в памяти достаточно места для опера
ционной системы и двух программ пользователя. Теперь, когда одно из заданий ждет
завершения операций ввода-вывода, процессор может переключиться на другое задание,
для которого в данный момент ввод-вывод, скорее всего, не требуется (рис.
2.5, б).
Более
того, если памяти достаточно для размещения большего количества программ, то про
цессор может выполнять их параллельно, переключаясь с одной на другую (рис. 2.5,в).
Такой режим известен как многозадачность
(multiprogramming)
и является основной
особенностью современных операционных систем.
Приведем простой пример, иллюстрирующий преимущества многозадачности. Рас
смотрим компьютер, имеющий
250
Мбайт доступной памяти (не используемой операци
онной системой), диск, терминал и принтер. На обработку одновременно приняты три
программы,
JOB 1, JOB2
и
JOB3,
атрибуты которых перечислены в табл.
жим, что для выполнения заданий
и задание
JOB3
JOB2
и
JOB3
Задание
в течение
15
Предполо
постоянно обращается к диску и принтеру. В простой среде с пакетной
обработкой эти задания выполняются последовательно. Дпя завершения
5 мин.
2.1.
использование процессора минимально
JOB2
должно ждать, пока пройдут эти
мин. По истечении
заканчивается через
30
20
5 мин,
JOBI
требуется
после чего оно выполняется
мин начинает рабоrу задание
JOB3;
его выполнение
мин после того, как оно было принято на обработку. Средний
процент использования ресурсов, производительность и время отклика показаны в стол
бце табл.
2.2,
соответствующем однозадачности, а на рис.
2.6, а
показано использование
различных устройств в этом режиме. Очевидно, что эффективность использования всех
ресурсов, усредненная по всему периоду времени
(30
мин), является крайне низкой.
96
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Программа А
R
R
Ожидание
Время
Ожидание
а) Однозадачность
Программа А
Программа В
Совместная
работа
R
R
Ожидание
Ожидание !Работа\
\Ра6ота\
Ожидание
Работа Ра6ота
в
А
Ожидание
Ожидание
Работа Работа
в
А
Ожидание
Ожидание
Время
6) Многозадачность:
Программа А
Программа В
R
Совместная
работа
R
Ожидание
Ожидание В
Ожидание
Программа С
две программы
R
Ожидание
R
Работа Работа Работа
С
В
А
Ожидание
Ожидание
Ожидание
R
Ожидание
Работа Работа Ра6ота
С
В
А
Ожидание
Ожидание
Время
в) Многозадачность: три программы
Рис. 2.5. Пример многозадачности
ТА&ЛИЦА
2.1.
СВОЙСТВА ТРЕХ ПРОГРАММ-ПРИМЕРОВ
JOB2
JОВЗ
Интенсивные
Интенсивный
Интенсивный
вычисления
ввод-вывод
ввод-вывод
Продолжительность
5 мин
15
Требуемая память
50
Требуется ли диск
JOB1
Тип задания
МИН
10
мин
100 Мбайт
75
Мбайт
Нет
Нет
Да
Требуется ли терминал
Нет
Да
Нет
Требуется ли принтер
Нет
Нет
Да
Мбайт
97
2.2. Эволюция ОПЕРАЦИОН НЫХ СИ СТЕМ
ТАБЛИЦА
2.2.
ВЛИЯНИЕ МНОГОЗАДАЧНОСТИ НА ИСЛОЛЬЗОВАНИЕ РЕСУРСОВ
Однозадачность
Теперь предположим, что задания выполняются одновременно под управлением мно
гозадачной операционной системы. Из-за того что они используют разные ресурсы, их
совместное выполнение на компьютере длится минимальное время (при условии, что
заданиям
JOB2
и JОВЗ предоставляется достаточно процессорного времени для под
держки осуществляемого ими ввода и вывода в активном состоянии). Для выполнения
задания
JOB 1 потребуется 5 мин ,
но к этому времени задание
JOB2
будет выполнено на
98
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
треть, а задание JОВЗ
-
на половину. Все три задания будут выполнены через
Если посмотреть на столбец табл.
2.2,
15
мин.
соответствующий многозадачному режиму, его
преимущества станут очевидными, как и из гистограммы, приведенной на рис.
2.6,6.
Работа многозадачной пакетной системы, как и работа простой пакетной системы,
базируется на некоторых аппаратных возможностях компьютера. Наиболее значительны
ми дополнениями, полезными для многозадачности, являются аппаратное обеспечение,
поддерживающее прерывания ввода-вывода, и прямойдоступ к памяти. Используя эти
возможности, процессор может генерировать команду ввода-вывода для одного задания
и переходить к другому на то время, пока контроллером устройства выполняется ввод
вывод. После завершения операции ввода-вывода процессор прерывается и управление
передается программе обработки прерываний из состава операционной системы. Затем
операционная система передает управление другому заданию.
Многозадачные операционные системы сложнее однозадачных систем последова
тельной обработки заданий. Для того чтобы можно было обрабатывать несколько зада
ний одновременно, они должны находиться в основной памяти, а для этого требуется
некоторая система управления памятью. Кроме того, если к работе готовы несколько
заданий, процессор должен решить, какое из них следует запустить, для чего необходим
некоторый алгоритм планирования. Эти концепции обсуждаются ниже в данной главе.
Системы, работающие в режиме разделения времени
Использование многозадачности в пакетной обработке может привести к сущест
венному повышению эффективности. Однако для многих заданий желательно обеспе
чить такой режим, в котором пользователь мог бы непосредственно взаимодействовать
с компьютером. В самом деле, во многих случаях интерактивный режим является обяза
тельным условием работы.
Сегодня требование интерактивных вычислений может быть удовлетворено путем
использования отдельного персонального компьютера или рабочей станции. Этот вари
ант был недоступен в 1960-е годы, когда большинство компьютеров были большими и
дорогостоящими. Тогда и был разработан режим разделения времени.
Многозадачность позволяет процессору одновременно обрабатывать не только не
сколько заданий в пакетном режиме, но и несколько интерактивных заданий. Такую ор
ганизацию называют разделением времени,
потому что
процессорное время распре
деляется между различными пользователями. В системе разделения времени несколько
пользователей одновременно получают доступ к системе с помощью терминалов, а опе
рационная система чередует исполнение
программ каждого пользователя через малые
промежутки времени. Таким образом, если нужно одновременно обслужить п пользо
вателей, каждому из них предоставляется в среднем лишь \/п часть рабочего времени
компьютера, не считая затрат на работу операционной системы. Однако, принимая во
внимание относительно медленную реакцию человека, время отклика на компьютере с
хорошо настроенной системой будет сравнимо со временем реакции пользователя.
Как пакетная обработка, так и разделение времени используют многозадачность. Ос
новные различия этих двух режимов перечислены в табл.
2.3.
Одной из первых операционных систем разделения времени была система
(CompatiЫe
Time-Sharing System) [52],
ком институте группой, известной как
tiple-Access Computers). Система
перенесена на IBM 7094.
CTSS
разработанная в Массачусетском технологичес
Project
МАС
(Machine-Aided Cognition или Mul1961 году для IBM 709, а затем
была разработана в
2.2. Эволюция ОПЕРАЦИОННЫХ СИСТЕМ
ТАБЛИЦА
2.3.
99
ПАКЕТНАЯ МНОГОЗАДАЧНОСТЬ И РАЗДЕЛЕНИЕ ВРЕМЕНИ
Основная цель
Пакетная многозадачность
Разделение времени
Максимальное использование
Уменьшение времени отклика
процессора
Источник указаний
Команды языка управления
Команды, вводимые с тер-
операционной системе
заданиями, помещаемые в
минала
задание
По сравнению с более поздними системами,
CTSS была довольно примитивна. Она
32 ООО 36-битовых слов, из которых
работала на машине с основной памятью емкостью
5 ООО
слов занимал монитор. Когда управление должно было быть передано очередному
интерактивному пользователю, его программа и данные загружались в остальные
27000
слов основной памяти. Программа всегда загружалась так, что ее начало находилось
в ячейке номер
5000,
что уnрощало уnравление как монитором, так и памятью. При
близительно через каждые
0,2
с системный таймер генерировал nрерывание. При каж
дом nрерывании таймера управление nередавалось оnераuионной системе, и
npoueccop
мог перейти в распоряжение другого пользователя. Такая технология получила назва
ние квантование времени
(time slicing).
через регулярные интервалы
Таким образом, данные текущего nользователя
времени выгружались, а вместо них загружались другие.
Перед считыванием программы и данных нового пользователя nрограмма и данные пре
дыдущего nользователя записывались на диск для сохранения до дальнейшего выnолне
ния. Впоследствии, когда очередь этого nользователя настуnит снова, код и данные его
программы будут восстановлены в основной nамяти.
Чтобы уменьшить обмен с диском, содержимое nамяти, занимаемое данными nоль
зователя, записывается на него лишь в том случае, если для загрузки новой программы
не хватает места. Этот принцип проиллюстрирован на рис.
2.7.
Предnоложим, что всего
работает четыре nользователя, которым нужны следующие объемы памяти в словах.
• JOBI: 15000
• JOB2: 20000
•
JОВЗ:
5000
• JOB4: 10000
Сначала монитор загружает задание
JOB 1
и nередает ему уnравление (рис.
Затем он принимает решение nередать уnравление заданию
JOB2.
2.7, а).
JOB2
Из-за того что
JOB 1, сначала нужно сохранить данные JOB 1, а затем
2.7, 6). Затем для обработки загружается JOB3. Но nо
чем JOB2, часть задания JOB2 может оставаться в основ
занимает больше nамяти, чем
можно загружать
JOB2
(рис.
скольку это задание меньше,
ной памяти, сокращая время записи на диск (рис. 2.7,в). Позже монитор вновь nередает
JOB 1. Чтобы загрузить его в nамять, на диск необходимо заnисать
JOB2 (рис. 2.7,г). При загрузке задания JOB4 в nамяти остается часть
JOB 1 и JOB2 (рис. 2. 7, д). Если теперь будет активизировано задание JOB 1 или
управление заданию
еще часть задания
заданий
JOB2,
то потребуется лишь частичная его загрузка. Следующим в этом примере заnуска
ется задание
JOB2.
Для этого требуется, чтобы
JOB4
JOB 1
2.7, е).
и оставшаяся в памяти часть
были записаны на диск, а в память была считана недостающая часть
JOB2
(рис.
100
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
о
Монитор
5000
о
5000
Монитор
JOB 1
о
5000
10000
JOB2
25000
память
32000
32000
а)
о
JOB 1
20000
25000
(JOB 2)
Свободная
память
32000
о
5000
32000
32000
Свободная
память
в)
о
Монитор
5000
(JOB 1)
(JOB 2)
Монитор
Свободная
память
JOB2
25000
32000
д)
Рис.
CTSS
память
25000
JOB4
15000
20000
25000
г)
Подход
Свободная
б)
Монитор
5000
JOB 3
(JOB 2)
20000
Свободная
Монитор
2.7.
Работа
Свободная
память
е)
CTSS
по сравнению с современными принципами разделения времени явля
ется примитивным, но он был вполне эффективным. Его простота позволяла использо
вать монитор минимальных размеров. Из-за того что задание всегда загружалось в одно
и то же место в памяти, не было необходимости применять во время загрузки методы
перемещения (которые рассматриваются позже). Необходим был лишь метод записи,
позволяющий уменьшить активность диска. Работая на машине
служивать до
32
7094, CTSS
могла об
пользователей.
С появлением разделения времени и многозадачности перед создателями операцион
ных систем появилось много новых проблем. Если в памяти находится несколько зада
ний, их нужно защищать друг от друга, иначе одно задание может, например, изменить
данные другого задания. Если в интерактивном режиме работают несколько пользовате
лей, то файловая система должна быть защищена, чтобы к каждому конкретному файлу
доступ был только у определенных пользователей. Нужно разрешать конфликтные ситу
ации, возникающие при работе с различными ресурсами, например с принтером и уст
ройствами хранения данных. Ниже в книге будут рассмотрены эти и другие возможные
проблемы, а также пути их решения.
2.3.
ОСНОВНЫЕ ДОСТИЖЕНИЯ
Операционные системы относят к числу самых сложных программ. Это отражает
стремление их разработчиков сделать системы такими, чтобы они удовлетворяли тре
бованиям удобства и эффективности и при этом не утратили способности к развитию.
Согласно
[64]
в процессе развития операционных систем были проведены исследования
в четырех основных направлениях.
2.3. ОсновныЕ достижЕния
•
Процессы
•
Управление памятью
•
Защита информации и безопасность
•
Планирование и управление ресурсами
101
Каждое из этих направлений можно охарактеризовать набором абстрактных принци
пов, разработанных для решения сложных практических задач. В основном развитие
современных операционных систем также происходит по перечисленным выше направ
лениям. Краткий их обзор, приведенный в этом разделе, поможет читателю получить
представление о содержании большей части настоящей книги.
Процессы
Одной из основополагающих концепций проектирования операционных систем явля
ется концепция процессов. Этот термин впервые был применен в 1960-х годах разработ
чиками операционной системы
Multics (56].
Процесс
-
несколько более общий термин,
чем задание Uob). Есть много определений термина процесс, в том числе:
•
выполняющаяся программа;
•
экземпляр программы, выполняющейся на компьютере;
•
объект, который можно идентифицировать и выполнять на процессоре;
•
единица активности, которую можно охарактеризовать единой цепочкой последо
вательных действий, текущим состоянием и связанным с ней набором системных
ресурсов.
Данная концепция должна становиться более понятной по мере освоения материала.
В процессе развития компьютерных систем при решении проблем, связанных с рас
пределением времени и синхронизацией, вклад в развитие концепции процесса был сде
лан в трех основных направлениях: многозадачные пакетные операции, разделение вре
мени и транзакции в реальном времени. Как мы уже могли убедиться, многозадачный
режим дает возможность процессору и устройствам ввода-вывода работать одновре
менно, повышая тем самым эффективность использования компьютерной системы. При
этом ключевой механизм состоит в следующем: в ответ на сигналы, свидетельствующие
о завершении транзакций ввода-вывода, процессор переключается с одной программы
на другую, находящуюся в основной памяти.
Другим направлением развития являются системы разделения времени общего на
значения. Основная цель их разработки
-
удовлетворение потребностей каждого поль
зователя при обеспечении их одновременной работы (для снижения стоимости). В этих
системах используется тот факт, что пользователь реагирует на события намного мед
леннее, чем компьютер. К примеру, если потребность пользователя во времени процес
сора для обработки его действий в среднем составляет
2св
30
той же системе, не мешая друг другу, могут работать до
течение
1 мин,
то в одной и
пользователей. Конечно же,
в таких расчетах нужно учитывать время, которое требуется для работы самой операци
онной системы.
Еще одним важным направлением развития являются системы обработки транзакций
в реальном времени. При работе таких систем некоторое число пользователей отправля-
102
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
ют запросы в базу данных или вносят в нее изменения. Пример
-
система бронирова
ния авиабилетов. Основное различие между системой обработки транзакций и системой
разделения времени состоит в том, что в первой из них выполняются одно-два приложе
ния, в то время как пользователи системы с разделением времени могут заниматься раз
работкой программ, запускать их и пользоваться многими различными приложениями.
В обоих случаях ключевым фактором является время отклика системы.
Прерывание было важным инструментом, который стал доступен системным про
граммистам еще на ранних стадиях развития многозадачных и многопользовательских
интерактивных систем. Выполнение любого задания может быть прервано при наступ
лении определенного события, например завершения ввода-вывода. При этом процессор
должен сохранить определенную информацию (такую, как содержимое счетчика команд,
общих и системных регистров) и переключиться на выполнение программы обработки
прерываний, которая выясняет природу прерывания, обрабатывает его, а затем возобнов
ляет выполнение одного из заданий.
Дизайн системного программного обеспечения, координирующего подобные процес
сы, оказался очень сложным. При одновременной обработке многих заданий, каждое
из которых включает в себя длинную последовательность действий, становится невоз
можно проанализировать все возможные комбинации последовательностей событий.
Ввиду отсутствия систематических средств обеспечения координации и взаимодействия
разных видов деятельности систем программисты обратились к специальным методам,
основанным на представлении о той среде, работу которой должна контролировать опе
рационная система. При этом они подвергались риску допустить трудноуловимые ошиб
ки, которые проявляются только в очень редких случаях, при выполнении определенных
последовательностей событий. Такие ошибки трудно обнаружить, потому что их нуж
но отличить от ошибок в приложениях и ошибок, возникающих при сбоях аппаратного
обеспечения. Еще одной особенностью, затрудняющей определение причины этих оши
бок (когда они обнаружены), является то, что воспроизвести точные условия, в которых
эти ошибки проявляются, крайне трудно. Ниже перечислены основные причины подоб
ных ошибок
•
[64).
Неправильная синхронизация. Часто случается так, что программа должна
приостановить свою работу и ожидать наступления какого-то события в системе.
Например, программа, которая инициировала операцию ввода-вывода, не смо
жет продолжать работу, пока в буфере не будут доступны необходимые ей дан
ные. В этом случае требуется передача сигнала от какой-то другой программы.
Недостаточная надежность сигнального механизма может привести к тому, что
сигнал будет потерян или будет получено два таких сигнала.
•
Сбой взаимного исключения. Часто один и тот же совместно используемый ре
сурс одновременно пытаются использовать несколько пользователей или несколько
программ. Например, два пользователя могут попытаться одновременно редакти
ровать один и тот же файл. Если эти обращения не контролируются должным об
разом, возможно возникновение ошибок. Для корректной работы требуется неко
торый механизм взаимного исключения, позволяющий в каждый момент времени
выполнять обновление файла только одной программе. Правильность реализации
такого взаимного исключения при всех возможных последовательностях событий
крайне трудно проверить.
103
2.3. Основные достижения
•
Недетерминированное поведение программы. Результат работы каждой про
граммы обычно должен зависеть только от ее ввода и не должен зависеть от ра
боты других программ, выполняющихся в этой же системе. Однако в условиях
совместного использования памяти и процессора программы могут влиять на ра
боту друг друга, переписывая общие области памяти непредсказуемым образом.
При этом результат работы программ может зависеть от порядка, в котором они
выполняются.
•
Взаимоблокировки. Возможны ситуации, в которых две или более программ "за
висают", ожидая действий друг друга. Например, двум программам может понадо
биться, чтобы устройства ввода-вывода выполнили некоторую операцию (напри
мер, копирование с диска на магнитную ленту). Одна из этих программ осущест
вляет управление одним из устройств, а другая
-
другим. Каждая из них ждет,
пока другая программа освободит нужный ресурс. Выйти из такой тупиковой си
туации может помочь система распределения ресурсов.
Дпя решения перечисленных проблем нужен систематический метод, основанный на
слежении за различными выполняющимися процессором программами и на управлении
ими. В основе такого метода лежит концепция процесса. Мысленно процесс можно раз
делить на три компонента.
1.
Выполняющаяся программа.
2.
Данные, необходимые для ее работы (переменные, рабочее пространство, буферы
и т.д.).
3.
Контекст выполнения программы.
Последний элемент является очень важным. Контекст выполнения
text),
или состояние процесса
(process state),
(execution con-
включает в себя всю информацию, нужную
операционной системе для управления процессом и процессору
-
для его выполне
ния. Данные, характеризующие это состояние, включают в себя содержимое различных
регистров процессора, таких как счетчик команд и регистры данных. Сюда же входит
информация, использующаяся операционной системой, такая как приоритет процесса и
сведения о том, находится ли данный процесс в состоянии ожидания какого-то события,
связанного с вводом-выводом.
На рис.
2.8
показан пример реализации процессов. Два процесса, А и В, находятся
в различных областях основной памяти. Другими словами, каждому процессу отведен
блок памяти, в котором содержатся код программы, данные и информация о состоянии
процесса. Каждый процесс заносится в список процессов, который создается и подде
рживается операционной системой. Часть этого списка, соответствующая определенно
му процессу, содержит указатель на размещение этого процесса в памяти. Кроме того,
сюда же частично или полностью может входить и информация о состоянии процесса.
Остальные данные могут храниться в другом месте, возможно, в самом процессе (как
показано на рис.
2.8).
В регистре индекса процесса содержится индекс выполняющегося
в текущий момент времени процесса, идентифицирующий его в списке процессов. Со
держимое счетчика команд указывает на очередную инструкцию, которую нужно выпол
нить. Базовый и граничный регистры задают область памяти, занимаемую процессом.
В базовый регистр заносится адрес начальной ячейки этой области, а в граничный
-
ее
размер (в байтах или словах). Содержимое счетчика команд и всех ссылок на данные
104
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
отсчитывается от значения базового регистра; по своей величине эти ссылки не могут
превосходить значение граничного регистра (что защищает процессы от воздействия
один на другой).
Основная
Регистры
память
процессора
Индекс процесса 1
Список
процессов
- -
Счетчик команд
1
Базовый регистр
1
Граничный регистр
Прочие
регистры
1
Б
h
{'
1
1
1
1
•
•
•
1
-::
Контекст
Процесс
А
Данные
Код
программы
ь
Контекст
Процесс
в
h
Данные
Код
программы
Рис.
2.8.
-
Типичная реализация процессов
Регистр индекса процесса, изображенный на рис.
2.8,
указывает, что выполняется
процесс В. До этого выполнялся процесс А, но он временно прерван. Содержимое всех
регистров в момент прекращения этого процесса записано в виде данных о состоянии
процесса. Впоследствии операционная система сможет вернуться к выполнению процес
са А; при этом будет сохранен контекст выполнения процесса В и восстановлен контекст
выполнения процесса А. Когда в счетчик команд загружается значение, указывающее на
область кода программы процесса А, автоматически возобновляется выполнение этого
процесса.
Таким образом, процесс реализуется в виде структуры данных. Он может выполнять
ся или находиться в состоянии ожидания. Состояние процесса в каждый момент време-
2.3. ОСНОВНЫЕ ДОСТИЖЕНИЯ
105
ни заносится в специально отведенную область данных. Использование этой структуры
позволяет развивать мощные методы координации и взаимодействия процессов. В рам
ках операционной системы на основе данных о состоянии процесса путем их расшире
ния и добавления в них дополнительной информации о процессе можно разрабатывать
новые возможности операционных систем (например, приоритеты процессов). При чте
нии книги нам встретится множество примеров использования описанной структуры в
решении задач, возникающих при разработке многозадачных и многопользовательских
операционных систем.
Последний момент, с которым мы вкратце познакомим вас здесь,
ка
(thread).
-
концепция пото
По сути, единый процесс, который получает определенные ресурсы, может
быть разбит на несколько параллельно работающих потоков, которые совместно выпол
няют работу процесса. Это привносит новый уровень параллельности, управляемый ап
паратным и программным обеспечением.
Управление памятью
Лучше всего потребности пользователя удовлетворяются вычислительной средой,
поддерживающей модульное программирование и гибкое использование данных. Нужно
обеспечить эффективный и систематичный контроль над размещением данных в запо
минающем устройстве со стороны управляющих программ операционной системы. Ис
ходя из сформулированных требований, операционная система должна выполнять такие
функции.
1.
Изоляция процессов. Операционная система должна следить за тем, чтобы ни
один из независимых процессов не смог изменить содержимое памяти, отведен
ное другому процессу, и наоборот.
2.
Автоматическое размещение и управление. Программы должны динамически
размещаться в памяти в соответствии с определенными требованиями. Распреде
ление памяти должно быть прозрачным для программиста. Таким образом, про
граммист будет избавлен от необходимости следить за ограничениями, связан
ными с конечностью памяти, а операционная система повышает эффективность
работы вычислительной системы, выделяя заданиям только тот объем памяти,
который нм необходим.
3.
Поддержка модульного программирования. Программист должен иметь воз
можность определять
модули программы, а также динамически
их создавать,
уничтожать и изменять их размер.
4.
Защита и контроль досl)'па. При совместном использовании памяти на каждом
ее иерархическом уровне есть вероятность, что одна программа обратится к про
странству памяти другой программы. Такая возможность может понадобиться,
если она заложена в принцип работы данного приложения. С другой стороны,
это угроза целостности программ и самой операционной системы. Операцион
ная система должна следить за тем, каким образом различные пользователи могут
осуществлять доступ к различным областям памяти.
5.
Долгосрочное хранение. Многим приложениям требуются средства, с помощью
которых можно было бы хранить информацию в течение длительного периода
времени после выключения компьютера.
106
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Обычно операционные системы выполняют эти требования с помощью средств вир
туальной памяти и файловой системы. Файловая система обеспечивает долгосрочное
хранение информации, помещаемой в именованные объекты, которые называются фай
-
лами. Файл
это удобная для программиста концепция, доступ к которой и защита
которой осуществляются операционной системой.
Виртуальная память
-
это функциональная возможность, позволяющая програм
мистам рассматривать память с логической точки зрения, не заботясь о наличии физи
ческой памяти достаточноr·о объема. Принципы работы с виртуальной памятью были
разработаны, чтобы задания нескольких пользователей, выполняясь параллельно, могли
одновременно присутствовать в основной памяти. При такой организации процессов нет
задержки между их выполнением:
как только один из процессов заносится на вспомо
гательное запоминающее устройство, считывается следующий процесс. Из-за различий
в количестве памяти, требующемся для разных процессов, при переключении процес
сора с одного процесса на другой трудно компактно разместить их в основной памяти.
Поэтому были разработаны системы со страничной организацией памяти, при которой
процесс разбивается на блоки фиксированного размера, которые называются страница
ми. Обращение программы к слову памяти происходит по виртуальному адресу
tual address),
(vir-
который состоит из номера страницы и смещения относительно ее начала.
Страницы одного и того же процесса могут быть разбросаны по всей основной памяти.
Системы со страничной организацией обеспечивают динамическое отображение вирту
ального адреса, использующегося программой, и реальным
(real address),
или физичес
ким, адресом основной памяти.
Следующим логическим шагом развития в этом направлении (при наличии аппарат
ного обеспечения, позволяющего выполнять динамическое отображение) было исклю
чение требования, чтобы все страницы процесса одновременно находились в основной
памяти; достаточно, чтобы все они хранились на диске. Во время выполнения процес
са только некоторые его страницы находятся в основной памяти. Если программа об
ращается к странице, которая там отсутствует, аппаратное обеспечение, управляющее
памятью, обнаруживает это и организует загрузку недостающих страниц. Такая схема
называется виртуальной памятью; она проиллюстрирована на рис.
2.9.
Аппаратное обеспечение процессора вместе с операционной системой предоставляют
пользователю "виртуальный процессор", который имеет доступ к виртуальной памяти.
Это хранилище может быть организовано в виде линейного адресного пространства или
в виде коллекции сегментов, представляющих собой смежные блоки переменной длины.
При каждом из этих способов организации можно обращаться к ячейкам виртуальной
памяти, в которых содержатся программа и ее данные, с помощью команд языка про
граммирования. Чтобы изолировать процессы один от другого, каждому из них можно
выделить свою область памяти, не пересекающуюся с областью памяти другого процес
са. Общее использование памяти можно организовать, частично перекрывая части двух
пространств виртуальной памяти. Файлы хранятся на долговременном запоминающем
устройстве. Чтобы с ними могли работать программы, файлы или их фрагменты могут
копироваться в виртуальную память.
На рис.
2.10
поясняется концепция адресации в схеме виртуальной памяти. Храни
лище состоит из основной памяти, открытой для прямого доступа (осуществляемого с
помощью машинных команд), а также более медленной вспомогательной памяти, доступ
к которой осуществляется косвенно, путем загрузки блоков в основную память. Между
процессором и памятью находятся аппаратные средства (модули управления памятью)
для трансляции адресов.
2.3. ОсновныЕ д о стижЕния
107
А.1
А.О
А.2
о
А.5
о
1
В.О
В.1
В.2
В.3
А.7
А.9
2
2
3
3
4
4
5
5
6
6
7
Пользовательская
программа В
8
9
А.8
10
Пользовательская
программа А
В.5
В.6
Основная память
Диск
Основная память состоит из
кадров (блоков, или фреймов)
фиксированного размера,
Вторичная память (диск) может
хранить большое количество
страниц фиксированного размера.
равного размеру страницы.
Пользовательская программа состоит
Дn.я работы программы некоторые
из некоторого количества страниц.
(или все) ее страницы должны
находиться в основной памяти
Рис.
2.9.
Страницы всех программ и
операционной системы хранятся
на диске, как и файлы
Концепция виртуальной памяти
Программы обращаются к ячейкам памяти с использованием виртуальных адресов ,
транслируемых в ходе обращения в реальные адреса основной памяти. Если происходит
обращение к виртуальному адресу, который не загружен в основную память, то один
из блоков реальной памяти меняется местами с нужным блоком, который находится во
вспомогательной памяти . Во время этого обмена процесс , который обратился к данному
адресу, должен быть приостановлен . Задача разработки такого механизма преобразова
ния адресов, который не требовал бы больших дополнительных ресурсов, и такой стра
тегии размещения данных в хранилище, которая сводила бы к минимуму перемещение
данных между различными уровнями памяти, возлагается на разработчика операцион
ной системы.
108
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
/
/
/
/
Реальный
(физический)
Модуль
Процессор
/
ВИJлуальный
адрес
управления
памятью
v,__
адрес
Основная
память
Дисковый
адрес
/
!'--.....
_./
Вторичная
память
Рис.
2.1 О.
Адресация виртуальной памяти
Защита информации и безопасность
С ростом популярности систем разделения времени
компьютерных сетей
-
-
а впоследствии с появлением
возникла проблема защиты информации. В зависимости от об
стоятельств природа угрозы, нависшей над определенной организацией, может быть са
мой разнообразной. Однако в компьютеры и операционные системы могут быть встрое
ны некоторые инструменты общего назначения, поддерживающие различные механизмы
защиты и обеспечивающие безопасность. Если говорить в общих чертах, мы сталкива
емся с проблемой контроля над доступом к компьютерным системам и хранящейся в
них информации.
Большую часть задач по обеспечению безопасности и защиты информации можно
условно разбить на четыре категории.
1.
Доступ. Связан с защитой системы от постороннего вмешательства.
2.
Конфиденциальность. Гарантирует невозможность чтения данных неавторизо
ванным пользователем.
3.
4.
Целостность данных. Защита данных от неавторизованного изменения.
Аутентификация. Обеспечение надлежащей верификации пользователей и кор
ректности сообщений или данных.
Планирование и управление ресурсами
Одной из важных задач операционной системы является управление имеющимися в
ее распоряжении ресурсами (основной памятью, устройствами ввода-вывода, процессо
ром), а также планирование их использования между разными активными процессами.
При разработке стратегии распределения ресурсов необходимо принимать во внимание
следующие факторы.
2.3. ОСНОВНЫЕ ДОСТИЖЕНИЯ
1.
109
Равноправность. Обычно желательно, чтобы всем процессам, претендующим на
какой-то определенный ресурс, предоставлялся к нему одинаковый доступ. В осо
бенности это касается заданий, принадлежащих к одному и тому же классу, т.е.
заданий с аналогичными требованиями к ресурсам.
2.
Дифференциация отклика. С другой стороны, может понадобиться, чтобы опе
рационная система по-разному относилась к заданиям различных классов, име
ющим различные запросы. Нужно попытаться сделать так, чтобы операционная
система выполняла распределение ресурсов в соответствии с целым набором тре
бований. Операционная система должна действовать динамически, в зависимости
от обстоятельств. Например, если какой-то процесс ожидает доступа к устройс
тву ввода-вывода, операционная система может спланировать выполнение этого
процесса так, чтобы как можно скорее освободить устройство для дальнейшего
использования другими процессами.
3.
Эффективность. Операционная система должна повышать пропускную способ
ность системы, сводить к минимуму время ее отклика и, если она работает в сис
теме разделения времени, обслуживать максимально возможное количество поль
зователей. Эти требования несколько противоречат друг другу; насущной пробле
мой исследования операционных систем является поиск нужного соотношения в
каждой конкретной ситуации.
Задача управления ресурсами и их распределения типична для исследований в об
ласти операционных систем; здесь могут применяться математические результаты, полу
ченные в этой области. Кроме того, важно измерять активность системы, что позволяет
следить за ее производительностью и вносить коррективы в ее работу.
На рис.
2.11
показаны основные элементы операционной системы, участвующие в
планировании процессов и распределении ресурсов в многозадачной среде. Операци
онная система поддерживает несколько очередей, каждая из которых является просто
списком процессов, ожидающих своей очереди на использование какого-то ресурса.
В краткосрочную очередь заносятся процессы, которые (или по крайней мере основные
части которых) находятся в основной памяти и готовы к выполнению. Выбор очередно
го процесса осуществляется краткосрочным планировщиком, или диспетчером. Общая
стратегия состоит в том, чтобы каждому находящемуся в очереди процессу давать до
ступ по очереди; такой метод называют циклическим (round-roЬin). Кроме того, процес
сам можно присваивать различный приоритет.
В долгосрочной очереди находится список новых процессов, ожидающих возможнос
ти использовать процессор. Операционная система добавляет их в систему, перенося из
долгосрочной очереди в краткосрочную. В этот момент процессу необходимо выделить
определенную часть основной памяти. Таким образом, операционная система должна
следить за тем, чтобы не перегрузить память или процессор, добавляя в систему слиш
ком много процессов. К одному и тому же устройству ввода-вывода могут обращаться
несколько процессов, поэтому для каждого устройства создается своя очередь (запрос
на использование одного и того же устройства ввода-вывода может исходить от разных
процессов, и все процессы, ожидающие доступ к данному устройству, выстраиваются в
очередь этого устройства). И здесь операционная система должна решать, какому про
цессу предоставить освободившееся устройство ввода-вывода в первую очередь.
11 о
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Операционная система
Обработчик
Вызов службы
из процесса --.....н~ вызовов служб
(код)
Прерывание
от процесса
Прерывание
---+-1.i
Обработчик
прерываний
Долгосрочная
Краткосрочнах
очсрсдь
очередь
ствам
ввода
от устройства - - - + - 1 . i~--(_ко_д_)_~
ввода-вывода
Очереди к
устрой-
вывода
Краткосрочный
планировщик
(код)
Передача управления
процессу
Рис.
2.11.
Ключевые элементы многозадачной операционной системы
Во время прерывания управление переходит к обработчику прерываний, который яв
ляется частью операционной системы. В силу своей функциональности процесс может
обратиться к некоторой службе операционной системы, например к драйверу устройства
ввода-вывода. При этом происходит вызов обработчика обращений к службам, который
становится точкой входа в операционную систему. Независимо от того, произошло ли
прерывание или обращение к службе, после его обработки планировщик выберет из
краткосрочной очереди процесс для выполнения.
Далее в этом разделе приводится чисто функциональное описание; эти модули в
различных операционных системах имеют разные особенности и устройство. Большая
часть научно-исследовательских усилий в области операционных систем была направле
на на выбор алгоритмов и структур данных для этой функциональности, обеспечиваю
щих равноправность, дифференциацию отклика и эффективность.
2.4.
РАЗРАБОТКИ, ВЕДУЩИЕ К СОВРЕМЕННЫМ
ОПЕРАЦИОННЫМ СИСТЕМАМ
Год за годом происходит эволюция структуры и возможностей операционных систем.
В последнее время в состав новых операционных систем и новых версий уже существу
ющих операционных систем вошли некоторые структурные элементы, которые внесли
большие изменения в природу этих систем. Современные операционные системы отве
чают требованиям постоянно развивающегося аппаратного и программного обеспечения
и новым угрозам для систем безопасности. Они способны управлять работой многопро
цессорных систем, работающих быстрее обычных машин, высокоскоростных сетевых
2.4. РАЗРАБОТКИ, ВЕДУЩИЕ К СОВРЕМЕННЫМ ОПЕРАЦИОННЫМ СИСТЕМАМ
111
приспособлений и разнообразных запоминающих устройств, число которых постоянно
увеличивается. Из приложений, оказавших влияние на устройство операционных сис
тем, следует отметить мультимедийные приложения, средства доступа к Интернету, а
также модель "клиент/сервер". Что касается безопасности, то в результате возможностей
доступа к компьютерам через Интернет значительно возросли потенциальные угрозы
их безопасности, а все более сложные атаки (вирусов, червей и взломщиков) оказали
глубокое влияние на дизайн операционных систем.
Неуклонный рост требований к операционным системам приводит не только к усо
вершенствованию их архитектуры, но и к возникновению новых способов их организа
ции. В экспериментальных и коммерческих операционных системах опробуются самые
разнообразные подходы и структурные элементы, большинство из которых можно объ
единить в следующие категории.
•
Архитектура микроядра
•
Многопоточность
•
Симметричная многопроцессорность
•
Распределенные операционные системы
•
Объектно-ориентированный дизайн
Отличительной особенностью большинства операционных систем до сегодняшне
го дня является большое монолитное ядро. Ядро операционной системы обеспечивает
большинство ее возможностей, включая планирование, работу с файловой системой, се
тевые функции, работу драйверов различных устройств, управление памятью и многие
другие. Обычно монолитное ядро реализуется как единый процесс, все элементы кото
рого используют одно и то же адресное пространство. В архитектуре микроядра ядру
отводится лишь несколько самых важных функций, в число которых входят управление
адресным пространством, обеспечение взаимодействия между процессами
communication -
IPC)
(interprocess
и основное планирование. Работу других сервисов операционной
системы обеспечивают процессы, которые иногда называют серверами. Эти процессы
запускаются в пользовательском режиме, и микроядро работает с ними так же, как и с
другими приложениями. Такой подход позволяет разделить задачу разработки операци
онной системы на разработку ядра и разработку сервера. Серверы можно настраивать
для требований конкретных приложений или среды. Выделение в структуре системы
микроядра упрощает реализацию системы, обеспечивает ее гибкость, а также хорошо
вписывается в распределенную среду. Фактически микроядро взаимодействует с локаль
ным и удаленным серверами по одной и той же схеме, что упрощает построение распре
деленных систем.
Многопоточность
(multithreading) -
это технология, при которой процесс, выпол
няющий приложение, разделяется на несколько одновременно выполняемых потоков.
Ниже приведены основные различия между потоком и процессом.
•
Поток
(thread).
Диспетчеризуемая единица работы, включающая контекст процес
сора (в который входит содержимое счетчика команд и указателя вершины сте
ка), а также собственную область стека (для организации вызова подпрограмм).
Команды потока выполняются последовательно; поток может быть прерван при
переключении процессора на обработку другого потока.
112
•
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Процесс. Набор из одного или нескольких nотоков, а также связанных с этими
nотоками системных ресурсов (таких, как область nамяти, в которую входят код
и данные, открытые файлы, различные устройства). Эта концеnция очень близка
концеnции выnолняющейся nрограммы. Разбивая nриложение на несколько nото
ков, nрограммист nолучает все nреимущества модульности nриложения и возмож
ность уnравления связанными с nриложением временными событиями.
Многоnоточность оказывается весьма nолезной для nриложений, выnолняющих
несколько независимых заданий, которые не требуют nоследовательного выnолнения.
В качестве nримера такого nриложения можно nривести сервер базы данных, который
одновременно nринимает и обрабатывает несколько заnросов клиентов. Если в nределах
одного и того же nроцесса работают несколько nотоков, то nри nереключении между
различными nотоками неnроизводительный расход ресурсов nроцессора меньше, чем
nри nереключении между разными nроцессами. Кроме того, nотоки nолезны nри оnи
санном в nоследующих главах структурировании
nроцессов, которые являются частью
ядра оnерационной системы.
Симметричная многопроцессорность
(symmetric multiprocessing -
SMP) -
тер
мин, относящийся к архитектуре аnnаратного обесnечения комnьютера (оnисанной в гла
ве
1,
"Обзор комnьютерной системы"), а также к nоведению оnерационной системы, со
ответствующему этой архитектурной особенности. Оnерационная система симметричной
многоnроцессорности расnределяет nроцессы и nотоки
nотенциальных nреимуществ
no
no
nроцессорам.
SMP
имеет ряд
сравнению с одноnроцессорными системами, включая
следующие.
•
Производительность. Если задание, которое должен выnолнить комnьютер, мож
но организовать так, что какие-то части этого задания будут выnолняться nарал
лельно, это nриведет к nовышению nроизводительности
no
сравнению с одноnро
цессорной системой с nроцессором того же тиnа. Сформулированное выше nоло
жение nроиллюстрировано на рис.
2.12.
В многозадачном режиме в один и тот же
момент времени можетвыnолняться только один nроцесс, тогда как остальные
nроцессы вынуждены ожидать своей очереди. В многоnроцессорной системе мо
гут выnолняться одновременно несколько nроцессов, nричем каждый из них будет
работать на отдельном nроцессоре.
•
Надежность. При симметричной многоnроцессорной обработке отказ одного из
nроцессоров не nриведет к остановке машины, nотому что все nроцессоры могут
выnолнять одни и те же функции. После такого сбоя система nродолжит свою ра
боту, хотя nроизводительность ее несколько снизится.
•
Наращивание. Добавляя в систему доnолнительные nроцессоры, nользователь
может nовысить ее nроизводительность.
•
Масштабируемость. Производители могут nредлагать свои nродукты в различ
ных
no
цене и nроизводительности конфигурациях, nредназначенных для работы
с разным количеством nроцессоров.
Важно отметить, что nеречисленные выше nреимущества являются скорее nотенци
альными, чем гарантированными. Чтобы надлежащим образом реализовать nотенциал,
заключенный в многоnроцессорных вычислительных системах, оnерационная система
должна nредоставлять адекватный набор инструментов и возможностей.
2.4. РАЗРАБОТКИ, ВЕДУЩИЕ К СОВРЕМЕННЫМ ОПЕРАЦИОННЫМ СИСТЕМАМ
Время
Процесс
1
Процесс
2
Процесс
3
113
--------+-
а) Чередование (много задач, один процессор)
Процесс
1
Процесс
2
Процесс
3
б) Чередование и перекрытие (много задач, два процессора)
c::::J
Заблокирован
Рис.
l=::::J Выполняется
2.12.
Многозадачность и многопроцессорность
Часто можно встретить совместное обсуждение многопоточности и многопроцессор
ности, однако эти два понятия являются независимыми. Многопоточность
-
полезная
концепция для структурирования процессов приложений и ядра даже на машине с од
ним процессором. С другой стороны, многопроцессорная система может обладать пре
имуществами по сравнению с однопроцессорной, даже если процессы не разделены на
несколько потоков, потому что в такой системе можно запустить несколько процессов
одновременно. Однако обе эти возможности хорошо согласуются между собой, а их сов
местное использование может дать заметный эффект.
Привлекательной особенностью многопроцессорных систем является то, что нали
чие нескольких процессоров прозрачно для пользователя
-
за распределение потоков
между процессорами и за синхронизацию разных процессов отвечает операционная сис
тема. В этой книге рассматриваются механизмы планирования и синхронизации, кото
рые используются, чтобы все процессы и процессоры были видны пользователю в виде
единой системы. Другая задача более высокого уровня
-
представление в виде единой
системы кластера из нескольких отдельных компьютеров. В этом случае мы имеем дело
с набором компьютеров, каждый из которых обладает собственной основной и вторич
ной памятью и своими модулями ввода-вывода. Распределенная операционная систе
ма создает иллюзию единого пространства основной и вторичной памяти, а также еди-
114
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
ной файловой системы. Хотя популярность кластеров неуклонно возрастает и на рынке
появляется все больше и больше кластерных продуктов, современные распределенные
операционные системы по-прежнему отстают в развитии от одно- и многопроцессорных
систем. С подобными системами вы познакомитесь ниже в данной книге.
Одним из последних новшеств в устройстве операционных систем стало использова
ние объектно-ориентированных технологий. Объектно-ориентированный дизайн по
могает навести порядок в процессе добавления к основному небольшому ядру дополни
тельных модулей. На уровне операционной системы основанная на объектах структура
позволяет программистам _настраивать операционную систему,
не нарушая ее целост
ности. Кроме того, этот подход облегчает разработку распределенных инструментов и
полноценных распределенных операционных систем.
2.5.
ОТКАЗОУСТОЙЧИВОСТЬ
Отказоустойчивость означает способность системы или компонента к продолжению
нормальной работы, несмотря на наличие ошибок аппаратного или программного обес
печения. Обычно отказоустойчивость предполагает определенную степень избыточнос
ти. Отказоустойчивость предназначена для повышения степени надежности системы.
Как правило, увеличение отказоустойчивости (и соответственно, повышение надежнос
ти) имеет определенную стоимость, либо финансовую, либо выражающуюся в падении
производительности (либо и то, и другое одновременно). Таким образом, определение
желаемой степени отказоустойчивости должно учитывать, что именно является крити
ческим ресурсом.
Фундаментальные концепции
Имеются три основных показателя качества функционирования системы, связанных
с отказоустойчивостью: надежность, среднее время наработки на отказ и доступность.
Эти концепции разработаны с особым акцентом на аппаратные сбои, но в целом приме
няются к сбоям как аппаратного, так и программного обеспечения.
Надежность
(reliabllity) R(t) системы определяется как вероятность ее бессбойной
t при условии ее корректной работы в момент времени t=O. Для
работы до времени
операционных систем и компьютеров термин бессбойная работа означает правильное
выполнение набора программ и защиту данных от случайного изменения. Среднее вре
мя наработки на отказ
(mean time to failure -
MTTF)
определяется как
r
f
MTTF = R(t)dt
о
Среднее время восстановления
(mean time to repair -
MTTR)
представляет со
бой среднее время, необходимое для ремонта или замены неисправного элемента. На
рис.
2.13
показана связь между
MTTF
и
MTTR.
2.5. ОТКАЗОУСТОЙЧИВОСТЬ
'~
В1
Сбой
В2
-
Работа
МПR = А 1 + А2 +АЗ
М1ТF= Bl +В2+В3
3
3
Рис.
Досrупность
--
.......
АЗ
А2
А1
вз
-
-
.........
__..
115
2. 13.
(availabllity)
Оперативное состояние системы
системы или службы определяется как доля времени, ког
да система досrупна для обслуживания запросов пользователей. Досrупность, по сути,
является вероятностью того, что система при заданных условиях корректно функцио
нирует в данный момент времени. Время, в течение которого система недосrупна, на
(downtime); время, в течение которого она доступна, работы (uptime). Досrупность системы может быть выражена
зывается простоем
безотказной
временем
следующим
образом:
MTTF
MTTF + MTTR
Доступность=------
В табл.
2.4
показаны некоторые распространенные уровни досrупности и соответ
ствующие времена простоя в течение года.
ТА&ЛИЦА
2.4.
КЛАССЫ ДОСТУПНОСТИ
Ежегодный простой
Кпасс
Доступность
Непрерывная работа
1,0
о
Отказоустойчивый
0,99999
5 мин
Восстанавливаемый
0,9999
53
Высокодоступный
0,999
0,99-0,995
8,3 ч
Обычная доступность
Зачасrую среднее время наработки на отказ
мин
44-87 ч
MTTF
является лучшим показателем,
чем досrупность. Небольшое время простоя в сочетании с краткими периодами безот
казной работы могут привести к высокому показателю досrупности, но пользователи
не смогут воспользоваться всеми услугами системы, если время ее безотказной работы
меньше времени, необходимого для завершения действий службы.
116
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Отказы
Словарь стандартов
определяет отказ
IEEE
(fault)
как ошибочное состояние аппарат
ного или программного обеспечения в результате сбоя некоторого компонента, ошибки
оператора, физической помехи от окружающей среды, ошибки проектирования, програм
мирования или структуры данных. Стандарт также определяет, что отказ проявляется
как
дефект аппаратного устройства или компонента (например, короткое замыкание
1)
или обрыв соединения) или
2)
неправильное действие, процесс или данные в компью
терной программе.
Можно сгруппировать отказы в следующие категории.
•
Постоянные. Такой сбой, после того как происходит, присутствует в системе пос
тоянно. Неисправность приводит к некорректной работе системы до тех пор, пока
неисправный компонент не будет заменен или отремонтирован. Примерами могут
служить поломка считывающих головок диска, ошибка программного обеспечения
или сгоревшая сетевая плата.
•
Временные. Сбой, который не сохраняется все время эксплуатации системы.
Такие сбои можно разделить на следующие группы.
•
Преходящие. Такой сбой однократен. Например, сбой при передаче в некото
ром бите из-за импульсного шума в линии или изменение бита памяти из-за
внешнего излучения.
•
Периодические. Сбои, происходящие в разные, непредсказуемые моменты вре
мени. Примером такого периодического сбоя могут быть ошибки, вызванные
неплотным соединением, приводящим к кратковременным потерям связи.
В общем случае отказоустойчивость системы обеспечивается путем внесения в нее
избыточности. К методам резервирования относятся следующие.
•
Пространственная (физическая) избыточность. Физическая избыточность пред
полагает использование нескольких
компонентов, которые одновременно выпол
няют одну и ту же функцию или настроены так, что один компонент доступен
в качестве резервной копии, включающейся в случае сбоя другого компонента.
Примерами могут служить использование нескольких параллельных схем или ре
зервный сервер доменных имен в Интернете.
•
Временная избыточность. Временная избыточность включает повторение выпол
нения функции или операции при обнаружении ошибки. Этот подход эффективен
для временных ошибок, но непригоден для постоянных сбоев. Примером является
ретрансляция блока данных при обнаружении ошибки передачи, как это делают
протоколы управления линиями передачи данных.
•
Информационная избыточность. Данная избыточность обеспечивает отказо
устойчивость путем репликации или кодирования данных таким образом, чтобы
ошибки в отдельных битах могли быть обнаружены и исправлены. Примером яв
ляются схемы с коррекцией ошибок, используемые в системах памяти, а также
методы коррекции ошибок в RАID-дисках, о чем будет рассказано позже.
2.6. ВОПРОСЫ ПРОЕКТИРОВАНИЯ ОПЕРАЦИОННЫХ СИСТЕМ ДЛЯ МНОГОПРОЦЕССОРНЫХ И МНОГОЯДЕРНЫХ СИСТЕМ
117
Механизмы операционных систем
Ряд методов поддержки отказоустойчивости могут быть включены в программное
обеспечение операционных систем. Ряд примеров будет встречаться вам на протяжении
всей книги. В следующем списке приведены некоторые из примеров.
•
Изоляция процессов: как упоминалось ранее в этой главе, процессы обычно изо
лированы один от другого с точки зрения основной памяти, доступа к файлам и
потока выполнения. Структура, предоставляемая операционной системой для уп
равления процессами, обеспечивает определенный уровень защиты от сбойного
процесса других процессов.
•
Управление параллелизмом: в главах
ключения и многозадачность", и
6,
5,
"Параллельные вычисления: взаимоис
"Параллельные вычисления: взаимоблокировка
и голодание", будут обсуждаться некоторые трудности и ошибки, которые могут
возникнуть при взаимодействии процессов или обмене информацией между ними.
В этих главах будут также рассмотрены методы, используемые мя обеспечения
корректной работы и восстановления после сбоев, таких как, например, взаимо
блокировка.
•
Виртуальные машины: виртуальные машины, которые будут рассмотрены в гла
ве
14,
"Виртуальные машины'', обеспечивают более высокую степень изоляции
приложений, а следовательно, и изоляцию сбоев. Виртуальные машины могут так
же использоваться мя обеспечения избыточности, когда одна виртуальная машина
выступает в качестве резервной копии для другой.
•
Точки восстановления и откаты: точка восстановления представляет собой ко
пию состояния приложения, сохраненную в некотором устройстве хранения, защи
щенном от рассматриваемых сбоев. Откат перезапускает выполнение из ранее со
храненной точки восстановления. При возникновении сбоя состояние приложения
откатывается до предыдущей точки восстановления и перезапускается. Этот метод
может использоваться для восстановления как после временных, так и после пос
тоянных аппаратных сбоев и определенных типов сбоев программного обеспече
ния. Системы управления базами данных и транзакциями обычно обладают таки
ми возможностями, встроенными в сами системы.
Можно было бы обсудить гораздо более широкий спектр методов, но полное рас
смотрение отказоустойчивости операционных систем выходит за рамки данной книги.
2.6.
ВОПРОСЫ ПРОЕКТИРОВАНИЯ ОПЕРАЦИОННЫХ
СИСТЕМ ДЛЯ МНОГОПРОЦЕССОРНЫХ
И МНОГОЯДЕРНЫХ СИСТЕМ
Операционные системы для
В системе
SMP
SMP
ядро может выполняться на любом процессоре, и обычно каждый
процессор самостоятельно планирует свою работу из пула доступных процессов или по
токов. Ядро может быть построено как многопроцессное или многопоточное, позволяя
118
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
параллельно выполняться нескольким частям ядра. SМР-подход усложняет операцион
ную систему. Проектировщик операционной системы должен решать сложные вопросы
совместного использования ресурсов (например, различных структур данных), коорди
нации действий (например, доступа к устройствам) нескольких частей операционной
системы в одно и то же время. Дпя решения этих вопросов требуется применение самых
современных технологий.
Операционная система, предназначенная мя симметричной многопроцессорной сис
темы, управляет процессорами и другими ресурсами компьютера таким образом, чтобы
с точки зрения пользователя многопроцессорная система выглядела так же, как и мно
гозадачная однопроцессорная система. Пользователь может создавать приложения с ис
пользованием нескольких процессов или нескольких потоков в процессах, не заботясь о
том, какое количество процессоров будет доступно
-
один или несколько. Таким обра
зом, многопроцессорная операционная система должна выполнять все функции многоза
дачной системы, а также обладать дополнительными возможностями по распределению
вычислений среди процессоров. В число особенностей архитектуры такой операционной
системы входят следующие.
•
Одновременные параллельные процессы или потоки. Чтобы несколько различ
ных
процессов могли одновременно выполнять один и тот же код ядра, он дол
жен быть реентерабельным. При выполнении несколькими процессорами одного
и того же кода ядра (или разных его частей) необходима организация управления
таблицами и управляющими структурами ядра, чтобы избежать взаимоблокировок
или неправильного выполнения операции.
•
Планирование. Планирование может выполняться на любом из процессоров, по
этому необходимо предусмотреть механизм, позволяющий избежать конфликтов
повреждения данных. При использовании многопоточности на уровне ядра не
сколько потоков одного и того же процесса могут выполняться на разных процес
сорах. Планирование в многопроцессорных системах рассматривается в главе
10,
"Многопроцессорное планирование и планирование реального времени".
•
Синхронизация. В ситуации, когда несколько активных процессов имеют возмож
ность доступа к совместным адресным пространствам или ресурсам ввода-вывода,
необходимо позаботиться об их эффективной синхронизации. Синхронизация
-
это средство, обеспечивающее реализацию взаимоисключений и упорядочение
событий. Общепринятым механизмом синхронизации в многопроцессорных опе
рационных системах являются блокировки, описанные в главе
5,
"Параллельные
вычисления: взаимоисключения и многозадачность".
•
Управление памятью. Система управления памятью в многопроцессорной систе
ме должна быть способна разрешать все проблемы, возникающие в однопроцес
сорных машинах. Кроме того, операционная система должна уметь использовать
возможности, предоставляемые аппаратным обеспечением, для достижения на
ивысшей производительности. Механизмы страничной организации памяти раз
ных процессоров должны быть скоординированы, чтобы обеспечить согласован
ность работы в ситуации, когда несколько процессоров используют одну и ту же
страницу или один и тот же сегмент и принимают решение по вопросу замещения
страниц.
2.6. ВОПРОСЫ ПРОЕКТИРОВАНИЯ ОПЕРАЦИОННЫХ СИСТЕМ ДЛЯ МНОГОПРОЦЕССОРНЫХ И МНОГОЯДЕРНЫХ СИСТЕМ
•
119
Надежность и отказоустойчивость. При отказе одного из процессоров опера
ционная система должна обеспечить продолжение корректной работы системы.
Планировщик операционной системы (как и другие ее части) должен получить
информацию о потере одного из процессоров и соответствующим образом пере
строить свои управляющие таблицы.
Поскольку при описании архитектуры многопроцессорной операционной системы,
как правило, рассматриваются те же вопросы (с добавлением некоторых других), что и
при описании устройства однопроцессорной операционной системы, мы не будем оста
навливаться на многопроцессорных операционных системах отдельно. Вместо этого по
ходу изложения материала книги будем обращаться к вопросам, являющимся специфич
ными для многопроцессорных систем.
Вопросы проектирования операционных
систем для многоядерных систем
Вопросы проектирования для многоядерных систем включают в себя все вопросы,
которые рассматриваются в данном разделе для SМР-систем. Однако возникают и до
полнительные проблемы. Одним из вопросов является масштаб потенциального па
раллелизма. В настоящее время производители многоядерных процессоров предлагают
системы с десятью и более ядрами на одном кристалле. С каждым новым поколением
технологии процессоров количество ядер, как и количество общего и выделенного кеша
памяти, постоянно увеличивается, так что сейчас мы вступаем в эпоху многоядерных
систем.
При проектировании многоядерных систем необходимо эффективно использовать всю
мощь многоядерной обработки данных и грамотно управлять значительными ресурсами
процессоров. Центральной проблемой является обеспечение соответствия параллельной
природы многоядерных систем требованиям к производительности приложений. Потен
циал параллелизма в современной многоядерной системе существует на трех уровнях.
Во-первых, имеется аппаратный параллелизм в рамках каждого ядра процессора, извес
тный как параллелизм уровня команд, который может использоваться программистами
приложений и компиляторами (но может и остаться неиспользованным). Во-вторых,
существует потенциал для многозадачности и многопоточного выполнения программ в
рамках каждого процессора. Наконец, потенциально единое приложение может выпол
няться параллельными процессами или потоками на нескольких ядрах. Без мощной и
эффективной поддержки только что упомянутых последних двух типов параллелизма
операционной системой аппаратные ресурсы не будут использоваться эффективно.
По сути, с появлением многоядерных технологий разработчики операционных сис
тем постоянно решают проблемы, как повысить степень использования параллелизма.
В настоящее время активно изучаются различные подходы, которые будут использованы
в грядущем поколении операционных систем. В этом разделе мы представим две общие
стратегии и рассмотрим некоторые их детали в последующих главах.
параллелизм в приложениях
Большинство приложений в принципе могут быть подразделены на несколько задач,
которые могут выполняться параллельно, причем эти задачи реализуются как несколько
процессов, возможно, каждый из них
-
с несколькими потоками. Трудность заключает-
120
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
ся в том, что разработчик должен решить, как разделить работу приложения на незави
симо выполняемые задачи. То есть разработчик должен решить, какие части могут (или
должны) быть выполнены асинхронно, или параллельно. В основном процесс разработ
ки параллельных программ поддерживается компилятором и возможностями языка про
граммирования. Операционная система может поддерживать этот процесс как минимум
путем эффективного распределения ресурсов среди параллельных задач, определенных
разработчиком.
Одним из наиболее эффективных инициатив по поддержке разработчиков является
технология
Grand Central Dispatch (GCD), реализованная в последних версиях опера
iOS и Мае OS Х на базе UNIX. GCD представляет собой технологию
ционных систем
поддержки многоядерных процессоров. Она не помогает разработчику решить, как раз
делить задачу или приложение на отдельные параллельные части. Но после того как
разработчик определил, что именно можно выделить в отдельную задачу, технология
GCD
облегчает выполнение этой задачи.
По сути,
GCD
представляет собой механизм пула потоков, в котором операционная
система отображает задания на потоки, представляющие доступную степень паралле
лизма (плюс потоки, блокируемые вводом-выводом).
Windows
(начиная с версии
2000)
также использует механизм пула потоков; подобные пулы потоков активно использу
ются в серверных приложениях многие годы. Новинкой в
GCD
является расширение
для языков программирования, которое позволяет использовать безымянные функции
(именуемые блоками) в качестве способа указания задач. Следовательно,
GCD
не явля
ется крупным эволюционным шагом. Тем не менее это новый и ценный инструмент для
использования доступных параллелизма в многоядерных системах.
Один из лозунгов
Apple
для
GCD -
"острова сериализации в море параллелиз
ма". Он относится к реальной практике, добавляя больший параллелизм в выполнение
обычных настольных приложений. Эти острова изолируют разработчиков от сложных
проблем одновременного доступа к данным, взаимоблокировок и прочих ловушек мно
гопоточности. Разработчикам предлагается просто определить функции в их приложе
ниях, которые желательно выполнять вне основного потока, даже если они состоят из
нескольких последовательных или частично взаимозависимых задач.
GCD
позволяет
легко разделить модуль работы на части при сохранении существующего порядка и за
висимостей между подзадачами. В последующих главах мы рассмотрим некоторые под
робности работы с
GCD.
Виртуальная машина
Этот альтернативный подход заключается в признании, что при постоянно растущем
количестве ядер на чипе попытка программировать отдельные ядра для поддержки не
скольких приложений может оказаться просто неверным использованием ресурсов
[ 117).
Если вместо этого позволить одному или нескольким ядрам быть выделенными для кон
кретного процесса, а затем
предоставить
процессору самостоятельно направлять свои
усилия на выполнение этого процесса, то таким образом можно избежать множества
накладных расходов, связанных с переключениями и планированием задач. Многоядер
ная операционная система может выступать в качестве гипервизора, который принимает
решения высокого уровня о выделении ядер приложениям, но, кроме этого, мало забо
тится о распределении ресурсов.
Обоснование такого подхода заключается в следующем. На раннем этапе развития
вычислительной техники одна программа выполнялась на одном процессоре. При мно-
2. 7. ОБЗОР ОПЕРАЦИОННОЙ СИСТЕМЫ
MICROSOFT WINDOWS
121
гозадачности у каждого приложения возникает иллюзия, что оно работает на выделен
ном для него процессоре. Многозадачность основана на концепции процесса, который
представляет собой абстракцию среды выполнения. Для управления процессами опера
ционная система требует защищенного пространства, с которым не могут взаимодейство
вать пользователи и программы. С этой целью бьта разработана возможность работы в
режиме ядра и в пользовательском режиме. По сути, режим ядра и пользовательский ре
жим работы разделяют процессор на два. Однако эти виртуальные процессоры начинают
борьбу за внимание реального процессора. Накладные расходы переключения между все
ми этими процессорами начинают расти до точки, когда начинает страдать отклик сис
темы, в особенности при наличии нескольких ядер. Но в многоядерных системах можно
подумать об отбрасывании различий между режимами пользователя и ядра. При таком
подходе операционная система действует в большей степени как гипервизор. Сами про
граммы берут на себя многие из функций управления ресурсами. Операционная система
назначает приложению процессор и некоторую память, и программа, используя сгенери
рованные компилятором метаданные, сама знает, как использовать эти ресурсы.
2.7.
ОБЗОР ОПЕРАЦИОННОЙ СИСТЕМЫ
MICROSOFT WINDOWS
Основы
Впервые
Microsoft
использовала имя
"Windows"
в
1985
году для операционной сре
ды, расширяющей возможности примитивной операционной системы
MS-DOS,
кото
рая успешно использовалась на ранних персональных компьютерах. Такая комбинация
Windows/MS-DOS в конечном итоге была заменена новой версией Windows, известной
как Windows NT, впервые выпущенной в 1993 году и предназначенной для ноутбуков и
настольных систем. Хотя основная внутренняя архитектура остается примерно той же,
что и в
Windows NT,
сама операционная система продолжает развиваться и дополняться
новыми функциями и возможностями. Последняя версия на момент написания этой кни
ги
-
Windows 1О. Windows 1О
включает в себя возможности предыдущей операцион
ной системы для настольных и портативных компьютеров
Windows,
Тhings -
Windows 8.1,
а также версий
предназначенных для мобильных устройств для Интернета вещей
lоТ).
Windows 1О
(lntemet of
One.
также включает в себя программное обеспечение ХЬох
В результате единая унифицированная операционная система
Windows 1О
One.
поддерживает
настольные компьютеры, ноутбуки, смартфоны, планшеты и ХЬох
Архитектура
2.14 представлена общая структура Windows.
Windows отделяет программное обеспечение,
На рис.
системы,
Как и почти все операционные
ориентированное на приклад
ные программы, от ядра операционной системы. К последним относятся исполняющая
система, микроядро, драйверы устройств и уровень аппаратных абстракций
abstraction layer -
HAL),
(hardware
которые работают в режиме ядра. Программы, выполняющи
еся в этом режиме, имеют доступ к системным данным и к аппаратному обеспечению.
Остальные программы, работающие в пользовательском режиме, имеют ограниченный
доступ к системным данным.
Диспетчер системных служб
Интерфейсы вызова привилег ированных служб ядра
Диспетчер
ввода-вывщ а
Драйверы
устройств
и файловой
системы
>:S:
~~
,;!
~
$:s:
8
~
u
=
~
Q)
$
о
е-
g
c:..~t
~ ~>:S:
8~~
~
~~
u
::i:
~
~
о
>.
"'o:s
:s:
о. :х:
Q)
о.
::r !;:
1-
~о
:х:
~ ~
~~
t:::{
3
Q)
:s:
u
o:s
:х:
о~
~~
Q)
\О
"'o:s:х:"'
~"'
"' 1-
~~
~~
P:J
:;; :s:
u
u
Q)
::r
~
о
1-
о
g_~
~
о.
Q)
~
:s:
:s:::r~
2.t"
~ i':'
Q)
:s: Q)
u
:s: ~~5
~
~
:х:
~~
~
о
Q)
::r
t::: о
~ §"
м
:;;
P:J
Ядро
Уровень аппаратных абстракций
POSIX
GDI DLL -
G
о
~
1
Lsass
:s:
о
Win32 USER,
GDI
Графические
драйверы
1
(Hardware abstraction layer - HAL)
сервер проверки подлинности локальной
системы безопасности
1
Выделенная область показывает
исполнительную систему
интерфейс переносимых операционных систем
интерфейс графического устройства
динамически подключаемая библиотека
Рис.
2. 14.
Архитектура
Windows [212]
Организация операционной системы
Windows
присуще четкое разделение на модули. Каждая функция системы управля
ется только одним компонентом операционной системы. Остальные ее части и все при
ложения обращаются к этой функции через стандартный интерфейс. Доступ к основным
системным данным можно получить только через определенные функции. В принципе
любой модуль можно удалить, обновить или заменить, не переписывая всю систему или
Исполнительная система. Содержит основные службы операционной системы,
такие как управление памятью, процессами и потоками, безопасность, ввод-вывод
и межпроцессное взаимодействие.
•
Ядро. Управляет работой процессоров. Ядро управляет планированием потоков,
переключением процессов, обработкой исключений и прерываний, а также много
процессорной синхронизацией. В отличие от остальной части исполняющей сис
темы и уровня пользователя, код самого ядра не выполняется потоками.
•
Уровень аппаратных абстракций. Выполняет отображение обобщенных команд
и ответов аппаратного обеспечения на уникальные команды и ответы аппаратного
обеспечения конкретной платформы. Изолирует операционную систему от разли
чий аппаратных платформ.
мого доступа
(DMA),
HAL делает
системную шину, контроллер памяти пря
контроллер прерываний, системные таймеры и контроллер
памяти разных компьютеров выглядящими одинаково для компонентов исполни
тельной системы и ядра. Он также обеспечивает необходимую для
SMP поддержку
(о чем будет сказано ниже).
•
Драйверы устройств. Динамические библиотеки, расширяющие функциональ
ность исполнительной системы. К ним относятся драйверы устройств аппаратного
обеспечения, которые транслируют пользовательские вызовы функций ввода-выво
да в запросы к конкретным аппаратным устройствам, и программные компоненты
реализации файловых систем, сетевых протоколов и других системных расшире
ний, которые должны выполняться в режиме ядра.
•
Оконная и графическая системы. Реализует функции графического интерфейса
пользователя, такие как работа с окнами, управление интерфейсом пользователя и
вывод на экран.
Исполнительная система
Windows
включает компоненты для определенных систем
ных функций и предоставления работающим в пользовательском режиме программам
соответствующего
API.
Ниже приведено краткое описание каждого из модулей испол
нительной системы.
•
Диспетчер ввода-вывода. Поддерживает каркас, с помощью которого устройства
ввода-вывода доступны для приложений, и отвечает за координацию работы драй
веров устройств, выполняющих дальнейшую обработку. Диспетчер ввода-вывода
реализует все
API
ввода-вывода
Windows
и (с помощью диспетчера объектов) сле
дит за безопасностью и именованием устройств, сетевых протоколов и файловых
систем. Система ввода-вывода
Windows
рассматривается в главе
11,
"Управление
вводом-выводом и планирование дисковых операций".
•
Диспетчер кеша. Повышает производительность файлового ввода-вывода путем
хранения в основной памяти тех данных с диска, к которым недавно производи
лось обращение. Кроме того, обеспечивает отложенную запись на диск, некоторое
время храня в памяти обновления дисковых файлов.
•
Диспетчер объектов. Создает и удаляет объекты и абстрактные типы данных ис
полнительной системы
Windows,
а также управляет ими. Эти объекты и абстракт
ные типы данных используются для представления таких ресурсов, как процессы,
потоки и объекты синхронизации. Диспетчер объектов обеспечивает выполнение
стандартных правил поддержки объектов, именования и безопасности. Кроме того,
этот диспетчер создает дескрипторы объектов, в которых содержится информация
124
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
о правах доступа и указатель на объект. Объекты операционной системы
Windows
обсуждаются немного позже.
•
Диспетчер самонастраиваемых устройств. Определяет, какие драйверы требу
ются для поддержки определенного устройства, и загружает их.
•
Диспетчер электропитания. Координирует энегропитание различных устройств
и может быть настроен для снижения энергопотребления путем отключения без
действующих устройств, погружения процессора в состояние сна и даже для запи
си памяти на диск и выключения питания всей системы.
•
Монитор безопасности. Обеспечивает выполнение правил прав доступа и ауди
та. Объектно-ориентированная модель операционной системы
Windows
позволяет
сформировать согласованный и единообразный взгляд на безопасность фундамен
тальных составляющих исполнительной системы. Так, для авторизации доступа
и аудита всех защищенных объектов, включая файлы, процессы, адресные про
Windows использует
Windows обсуждается в гла
странства и устройства ввода-вывода, операционная система
одни и те же служебные программы. Безопасность
ве
кой памятью и файлами подкачки на диске. Контролирует аппаратное обеспечение
управления памятью и структурами данных, которые отображают виртуальные ад
реса адресного пространства процессов на физические страницы памяти компью
тера. Управление виртуальной памятью в операционной системе
в главе
•
Windows
описано
"Виртуальная память".
8,
Диспетчер процессов и потоков. Создает и удаляет объекты, а также следит за
процессами и потоками. Управление процессами и потоками в операционной сис
теме
•
Windows
рассматривается в главе
4,
"Потоки".
Диспетчер конфигурации. Отвечает за реализацию и управление системным
реестром, который является единым хранилищем настроек и параметров как для
всей системы, так и для каждого пользователя.
•
Расширенный вызов локальных процедур. Это средство
dure call -
ALPC)
(advanced local proce-
обеспечивает эффективный механизм межпроцессного вызова
процедур для обмена информацией между локальными процессами, реализующи
ми службы и подсистемы.
procedure
са\1
-
RPC),
ALPC
схоже с вызовом удаленных процедур
(remote
используемым при распределенных вычислениях.
процессы пользовательского режима
Windows
1.
поддерживает четыре основных типа процессов пользовательского режима.
Специальные системные процессы. К таким процессам относятся служебные
программы, которые не вошли в операционную систему
Windows,
например про
цесс входа в систему, система аутентификации и диспетчер сессий.
2.
Служебные процессы. Очередь заданий принтера, запись событий, пользователь
ские компоненты для взаимодействия с драйверами устройств, различные сетевые
службы и многое другое. Службы используются как
Microsoft,
так и сторонними
разработчиками для расширения функциональности системы, поскольку являют
ся единственным средством выполнения фоновой пользовательской активности в
системе
Windows.
2. 7. ОБЗОР ОПЕРАЦИОННОЙ СИСТЕМЫ
3.
MICROSOFT WINDOWS
Подсистемы среды. Предоставляют приложениям пользователя службы
dows,
125
Win-
обеспечивая, таким образом, среду операционной системы. Поддерживают
Пользовательские приложения. Выполнимые файлы (ЕХЕ) и динамически
подключаемые библиотеки
(DLL),
обеспечивающие пользователям возможность
применения системы. В общем случае выполнимые файлы и динамически под
ключаемые библиотеки ориентированы на подсистему конкретной среды, хотя
некоторые из программ, предоставляемых в качестве части операционной систе
мы, используют естественные системные интерфейсы
(NT API).
Имеется также
поддержка выполнения 32-разрядных программ в 64-разрядных системах.
Операционная система
Windows
поддерживает приложения, написанные для разных
операционных систем. Эта поддержка обеспечивается с помощью общего набора ком
понентов ядра, лежащих в основе подсистем операционных сред. Реализация каждой
подсистемы среды включает отдельный процесс, который содержит общие структуры
данных, привилегии и дескрипторы исполнимых объектов, необходимые для реализации
конкретной среды. Такой процесс запускается диспетчером сеансов при первом запуске
приложения соответствующего типа. Процесс подсистемы работает от имени пользова
теля системы, так что исполнительная система защищает его адресное пространство от
процессов других пользователей.
Подсистема среды обеспечивает пользовательский интерфейс
-
графический или
командной строки, который определяет внешний вид операционной системы для поль
зователя. Кроме того, каждая подсистема предоставляет
API
для этой конкретной среды.
Это означает, что приложения, созданные для конкретной операционной среды, долж
ны всего лишь быть перекомпилированы для запуска на
Windows.
Поскольку интерфейс
операционной системы для всех приложений такой же, как и у систем, для которых они
были написаны; исходный код не требует внесения изменений.
Модель ··клиент/ сервер"
Структура исполнительной системы, защищенных подсистем и приложений выпол
нена в соответствии с вычислительной моделью "клиент/сервер"
делью распределенных вычислений, которая обсуждается в части
- общепринятой мо
VI, "Дополнительные
темы". Эта же архитектура может использоваться внутренне в одной системе, что мы и
видим на примере
Естественный
Windows.
NT АР! представляет
собой набор служб на базе ядра, которые обес
печивают основные абстракции, используемые в системе, такие как процессы, потоки,
виртуальная память, ввода-вывода и коммуникации.
Windows
предоставляет гораздо
больший набор служб, используя модель "клиент/сервер" для реализации функциональ
ности пользовательских процессов. Как подсистемы среды, так и службы пользователь
ского режима
Windows реализованы как
RPC. Каждый серверный
использованием
процессы, которые общаются с клиентами с
процесс ожидает от клиента запрос к одной из
его служб (например, к службе памяти, службе создания процессов или сетевых служб).
Клиент, который может быть прикладной программой или другой серверной програм
мой, запрашивает службу путем отправки сообщения. Сообщение направляется через
126
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
исполнительную систему соответствующему серверу. Сервер выполняет запрашиваемую
операцию и возвращает информацию о состоянии или результаты посредством другого
сообщения, отправляемого через исполнительную систему обратно клиенту.
К преимуществам модели "клиент/сервер" можно отнести следующие.
•
Упрощение исполнительной системы. Можно разработать ряд АР!, не имеющих
конфликтов или дублирования по отношению к исполнительной системе. Новые
АР! могут быть легко добавлены в систему.
•
Повышение надежности. Каждый новый сервер запускается вне ядра, в виде от
дельного процесса, которому отводится своя область памяти, защищенная от дру
гих серверов. Сбой в работе одного из серверов не приводит к аварийному отказу
или повреждению остальной части операционной системы.
•
Приложениям с помощью
RPC
предоставляются однотипные средства обмена
информацией с исполнительной системой без потери гибкости. Процесс пере
дачи сообщения скрыт от клиента функциями-заглушками, которые представляют
собой небольшие фрагменты кода вокруг вызовов
API
RPC.
При вызове приложением
заглушка пакует переданные при вызове параметры и передает их в виде со
общения процессу сервера, реализующему этот вызов.
•
Модель является базой для распределенных вычислений. Обычно распреде
ленные вычисления используют модель "клиент/сервер" с реализацией удаленных
вызовов процедур посредством распределенных модулей клиентов и серверов, а
также путем обмена сообщениями между клиентами и серверами. В операционной
системе
Windows
локальный сервер может передавать сообщение отлокального
приложения-клиента для обработки на удаленном сервере. Клиентам нет нужды
знать о том, как обрабатываются их запросы
-
локально или удаленно. Способ
обработки может изменяться динамически в зависимости от загруженности систе
мы и от изменений конфигурации.
Потоки и симметричная многопроцессорность
Возможности поддержки потоков и поддержки симметричной многоnроцессорности,
о которых мы говорили в разделе
темы
Windows.
операционной системе
•
2.4, -
две важные характеристики операционной сис
Ниже перечислены основные возможности поддержки потоков и
SMP
в
Windows [212].
Служебные программы операционной системы могут выполняться на любом из
свободных процессоров; различные программы могут выполняться одновременно
на разных процессорах.
•
Операционная система
Windows
поддерживает выполнение одного процесса, раз
деленного на несколько потоков. Эти потоки могут выполняться одновременно на
нескольких процессорах.
•
Серверные процессы могут использовать несколько потоков для одновременной
обработки запросов, поступающих от разных клиентов.
•
Операционная система
Windows
предоставляет механизмы совместного использо
вания данных и ресурсов различными процессами, а также гибкие возможности
обмена информацией между процессами.
2.7. ОБЗОР ОПЕРАЦИОННОЙ СИСТЕМЫ
MICROSOFT WINDOWS
127
Windows
Объекты
Хотя ядро операционной системы
Windows
написано на языке программирования С,
его дизайн в значительной мере следует концепциям объектно-ориентированного проек
тирования. Этот подход способствует совместному использованию ресурсов и данных
различными
процессами, а также защите ресурсов
от несанкционированного доступа.
Среди ключевых объектно-ориентированных концепций, использованных в операцион
ной системе
•
Windows,
следует упомянуть следующие.
Инкапсуляция. Объект состоит из одного или нескольких элементов данных (ат
рибутов) и одной или нескольких процедур, выполняемых над этими данными
(методы, сервисы). Единственный способ получить доступ к данным объекта
-
запросить один из его методов (сервисов). Таким образом, данные объекта легко
защитить от несанкционированного или некорректного использования (например,
от попытки выполнить невыполнимый фрагмент данных).
•
Классы объектов и экземпляры. Класс объекта представляет собой шаблон, в
котором перечислены его атрибуты и сервисы, а также определены некоторые его
характеристики. При необходимости операционная система может создавать эк
земпляры объектов класса. Например, имеется класс одиночных процессов, объек
том которого является текущий процесс. Такой подход упрощает создание объек
тов и управление ими.
•
Наследование. Хотя реализация этого механизма требует ручного кодирования,
исполнительная система использует его для расширения возможностей объектов
путем добавления новых возможностей. Каждый класс исполнительной системы
основан на базовом классе, который определяет виртуальные методы для под
держки создания, именования, обеспечения безопасности и удаления объектов.
Объекты диспетчеров представляют собой объекты исполнительной системы, ко
торые наследуют свойства объекта события, так что они могут использовать обыч
ные методы синхронизации. Другие типы объектов, такие как класс устройства,
позволяют классам конкретных устройств наследовать базовый класс и добавлять
к нему данные и методы.
•
Полиморфизм. Внутренне для управления объектами любого типа операционная
система
Windows
использует общий набор функций
ее полиморфизм. Однако
Windows
API -
в этом и заключается
не является полностью полиморфной, потому
что в ее состав входит множество АР! для конкретных типов объектов.
Читатель, не знакомый с объектно-ориентированными концепциями, должен обра
титься к приложению Г, "Объектно-ориентированное проектирование".
Не все сущности операционной системы
Windows
являются объектами. Объекты ис
пользуются в тех случаях, когда данные открыты для доступа в пользовательском ре
жиме, а также при совместном использовании данных и ограничении доступа. Среди
представляемых объектами сущностей
и графические окна.
же способом
-
Windows
-
файлы, процессы, потоки, семафоры, таймеры
создает все типы объектов и управляет ими одним и тем
с помощью диспетчера объектов. Этот диспетчер отвечает за создание
и уничтожение объектов, нужных для работы приложений, а также за предоставление
доступа к сервисам и данным объектов.
128
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Каждый объект исполнительной системы (иногда эти объекты называются объектами
ядра, чтобы отличать их от объектов пользовательского уровня, не имеющих отношения
к исполнительной системе) находится в области памяти, выделяемой ядром, доступ к
которой имеют только компоненты ядра. Некоторые элементы структуры данных при
сущи объектам всех типов (например, имена объектов, параметры безопасности, счет
чик использований). С другой стороны, каждый отдельный тип объектов имеет свои
специфические элементы (например, приоритет потока объекта). Поскольку структуры
данных таких объектов являются частью адресного пространства процесса, доступного
только ядру, приложение не может ни размещать в памяти эти структуры данных, ни не
посредственно считывать или записывать в них информацию. Вместо этого приложения
работают с объектами опосредованно, через набор функций для работы с объектами,
которые поддерживаются исполнительной системой. Когда создается объект для какого
нибудь приложения, последнему возвращается дескриптор созданного объекта. По сути,
дескриптор является индексом записи в таблице исполнительной системы для данного
процесса, которая содержит указатель на этот объект. Этот дескриптор объекта может
использоваться любым потоком этого процесса при вызове функций
Win32,
работающих
с объектами, или может быть дублирован в другой процесс.
С объектами может быть связана информация о безопасности, представленная в виде
дескриптора безопасности
(Security Descriptor -
SD).
Эта информация используется для
ограничения доступа к объекту на основе содержимого объекта, описывающего опре
деленного пользователя. Например, процессом может быть создан объект, являющийся
именованным семафором, открывать и использовать который будет позволено лишь не
которым пользователям. В дескрипторе безопасности этого семафора могут быть пере
числены пользователи, которым разрешен (или запрещен) к нему доступ, а также тип
разрешенного доступа (для чтения, записи, изменения и т.д.).
В операционной системе
Windows
объекты могут быть именованными или неимено
ванными. Если при работе процесса создается неименованный объект, то диспетчер объ
ектов возвращает дескриптор этого объекта. Впоследствии обратиться к этому объекту
можно будет только через его дескриптор. Дескрипторы могут наследоваться дочерними
процессами или дублироваться для передачи между процессами. У именованного объек
та, кроме того, есть имя, с помощью которого другие процессы могут получить его де
скриптор. Например, если нужно, чтобы процесс А выполнялся синхронно с процессом
В, в нем можно создать объект-событие, а затем передать его имя процессу В, в котором
это событие будет использовано для синхронизации. Однако если нужно синхронизовать
два потока одного и того же процесса А, то в нем можно создать неименованный объект
событие, потому что другие процессы не должны ничего о нем знать.
Имеется две категории объектов, используемых операционной системой
Windows
для
синхронизации.
•
Объекты диспетчера. Подмножество объектов исполнительной системы, которые
могут ожидаться потоками для диспетчеризации и синхронизации операций сис
темы на уровне Потоков. Эти объекты описаны в главе 6, "Параллельные вычисле
ния: взаимоблокировка и голодание".
•
Объекты управления. Объекты этого типа используются компонентами ядра для
управления операциями процессора в областях, не управляемых обычным плани
рованием потоков. Объекты управления ядра перечислены в табл.
2.5.
2.8. ТРАДИЦИОННЫЕ СИСТЕМЫ UNIX
ТА&ЛИЦА
2.5.
129
О&'ЬЕКТЫ УПРАВЛЕНИЯ ЯДРА WINDOWS
Асинхронный
Используется для прерывания выполнения определенного
вызов процедуры
потока и вызова процедуры в указанном режиме процессора
Отложенный вызов
Используется для откладывания обработки прерывания во избежа
процедуры
ние задержки аппаратных прерываний. Используется также для реа
лизации таймеров и межпроцессорных сообщений
Используется для связи источника прерывания с программой об
Прерывание
служивания прерывания посредством записи из таблицы диспетче
ризации прерываний
(lnterrupt Dispatch ТаЫе -
ЮТ). Такая таблица,
используемая для диспетчеризации прерываний, имеется у каждого
процессора
Представляет собой виртуальное адресное пространство и управ
Процесс
ляющую информацию, которые необходимы для выполнения набора
потоков. В процессе содержится указатель на карту адресов, список
готовых к выполнению потоков, список всех потоков процесса, сово
купное время выполнения всех потоков процесса, а также базовый
приоритет
Представляет объекты потоков, включая приоритет планирования и
Поток
квантования, а также информацию о том, на каких процессорах мо
жет выполняться поток
Используется в качестве меры при распределении времени выпол
Профиль
нения в пределах блока кода. Профиль может быть определен как
для кода пользователя, так и для системного кода
Операционная система
Windows
не является в полной мере объектно-ориентирован
ной. Она реализована не на объектно-ориентированном языке программирования. Струк
туры данных, содержащиеся в компоненте исполнительной системы, не представлены в
виде объектов. Тем не менее
Windows
иллюстрирует мощь объектно-ориентированной
технологии и ее использование при проектировании операционных систем.
2.8.
ТРАДИЦИОННЫЕ СИСТЕМЫ
UNIX
Историческая справка
UNIX была разработана компанией Bell Labs и за
1970 году на системе PDP-7. В результате разработки системы
Bell Labs, а впоследствии - и в других местах, появились различные
Изначально операционная система
пущена в эксплуатацию в
UNIX
в компании
версии этой операционной системы. Первой значительной вехой стал перенос системы
UNIX
UNIX
с
PDP-7
на
PDP-11.
Это послужило первым указанием на тот факт, что система
может быть использована в качестве операционной системы на всех компьюте
рах. Вторым важным этапом развития этой системы стало то, что она была переписана
на языке программирования С. Дпя того времени это было неслыханно. Считалось, что
такая сложная программа, какой является операционная система, для которой важным
параметром является время ее работы, должна быть написана только на языке ассемб
лера.
130
ГЛАВА 2. ОБЗОР ОПЕРАЦИОННЫХ СИСТЕМ
Причины такого мнения включают в себя следующее.
•
Память (как основная, так и вторичная) была в то время малого размера и дорогой
по сегодняшним меркам, поэтому было крайне важно эффективное ее использо
вание, включавшее различные методы перекрытия в памяти различных сегментов
кода и данных и применение самомодифицирующегося кода.
•
Несмотря на доступность компиляторов с 1950-х годов, в компьютерной промыш
ленности было распространено (не изжитое и поныне) скептическое отношение к
качеству автоматически сгенерированного кода. При малых доступных ресурсах
небольшой эффективный (как с точки зрения времени выполнения, так и с точки
зрения требуемой памяти) код имеет важное значение.
•
В то время и процессор, и шина были относительно медленными, так что эконо
мия тактов процессора могла привести к существенному различию времени вы
полнения.
Реализация на языке С продемонстрировала преимущество языка программирования
высокого уровня если не для всех, то для подавляющего большинства фрагментов сис
темного кода. В настоящее время почти все реализации операционной системы
UNIX
написаны на С.
Ранние версии
тема
UNIX
UNIX
были очень популярны в компании
была впервые описана в техническом журнале
шой интерес. Лицензии на
университетам. Версия
6
1978
были предоставлены коммерческим организациям и
этой системы, появившаяся в
используемой за пределами
ная в
UNIX
Bell Labs. В 1974 году сис
[206], что вызвало к ней боль
Bell Labs
1976
году, стала первой широко
версией. Следующая версия, версия
году, стала прототипом большинства современных систем
7, выпущен
UNIX. Наиболее
важные системы, не являющиеся продуктами фирмы АТ&Т, были разработаны в Кали
форнийском университете в Беркли и получили название
ровались на машинах
системы. В
мы
ем
UNIX BSD; они эксплуати
VAX. Фирма АТ&Т доработала и усовершенствовала эти
компания Bell Labs скомбинировала несколько вариантов систе
PDP
и
1982 году
UNIX фирмы АТ&Т в единую систему,
"UNIX System Ш". Впоследствии к этой
которая появилась в продаже под названи
операционной системе было добавлено не
сколько новых возможностей, в результате чего появилась система
UNIX System V.
Описание
Классическую архитектуру системы
UNIX
можно изобразить с помощью трех уров
ней: аппаратное обеспечение, ядро и пользовательский уровень. Операционную систему
часто называют системным ядром или просто ядром, чтобы подчеркнуть ее изолирован
ность от пользователя и приложений. Именно эта часть системы
лять для нас интерес в данной книге.
UNIX
UNIX
будет представ
также снабжается различными пользователь
скими сервисами и интерфейсами, которые рассматриваются как часть этой системы. Их
можно сгруппировать в оболочку, которая поддерживает системные вызовы от приложе
ний, другое интерфейсное программное обеспечение и компоненты компилятора С (ком
пилятор, ассемблер, загрузчик). Внешний по отношению к этой части системы уровень
состоит из приложений пользователя и интерфейса компилятора С.
Рис.
2. 15
дает более полное представление о системе. Программы пользователя мо
гут вызывать сервисы операционной системы как непосредственно, так и через библи
отечные программы.
2.8. ТРАДИЦИОННЫЕ СИСТЕМЫ UNIX
131
Пользовательские
программы
Ловушки
.- - - - - - - - -
Библиотеки
-~_\_.: .-_.:~-.~·-.- -.- . ___ ~-=~-:-=·=-~·::-::-_~~о_в:~~:_ ~
:s::
:i:
'!>
р.,
6
5%
g
u
;>,
10%
'!>
о
:i:
..Q
4
t=:
~
:s::
u
о
:i:
с5
2
о
2
3
4
5
6
7
8
Количество npOiteccopoв
а) Ускорение для различного количества последовательного кода
2.5 - - - - - - - - - - - - - - - - - - - - -
15
:i:
..Q
~
:s::
1.0 -~--------------------
u
g
о
0.5 - - - - - - - - - - - - - - - - - - - - - -
о
2
3
4
5
6
7
8
Количество процессоров
6)
Рис.
4.7.
Ускорение с учетом накладных расходов
Зависимость производительности вычислений от количества ядер
230
ГЛАВА 4. Потоки
Однако разработчики программного обеспечения решают эти проблемы, и сущест
вует множество приложений, которые эффективно используют возможности многоядер
ных систем. В
сообщается о наборе приложений дЛЯ работы с базами данных, в
[167]
которых большое внимание уделялось сокращению не распараллеливаемой части кода
в аппаратных архитектурах, операционных системах и прикладном программном обес
печении. На рис.
4.8
показаны достигнутые результаты. Как демонстрирует этот при
мер, системы управления базами данных и приложения для работы с базами данных
являются одной из областей, в которых могут эффективно использоваться многоядерные
системы. Многие виды серверов также могут эффективно использовать параллельные
многоядерные архитектуры, так как обычно серверы работают с многочисленными от
носительно независимыми операциями, которые могут быть обработаны параллельно.
Масштабирование загрузок баз данных в многопроцессорных системах
Помимо серверного программного обеспечения общего назначения, имеется ряд
классов приложений, получающих преимущества от возможности масштабирования
пропускной способности с увеличением количества ядер. В работе
[ 166]
содержатся
следующие примеры.
•
Изначально многопоточные приложения. Многопоточные приложения харак
теризуются небольшим количеством процессов с большим количеством потоков.
Примерами таких приложений являются
•
Lotus Domino
и
Siebel CRM.
Многопроцессные приложения. Многопроцессные приложения характеризуют
ся большим количеством однопоточных процессов. Примерами многопроцессных
приложений являются база данных
•
Приложения
Java.
Приложения
Oracle, SAP
Java
и
PeopleSoft.
тесно связаны с потоками. Язык
Java
не
только значительно облегчает написание многопоточных приложений; сама вир
туальная машина
Java
является многопоточным процессом, который обеспечивает
231
4.3. МногоядЕРность и многопоточность
планирование и управления памятью Jаvа-приложений. Приложения
Java,
могущие
получить выгоду непосредственно от использования многоядерных систем, вклю
чают такие серверы приложений, как
IВМ
Websphere
приложения, использующие серверы
(платформа
Oracle Java Application Server, ВЕА WeЫogic,
Tomcat с открытым исходным кодом. Все
приложений Java 2 Platform Enterprise Edition
и сервер приложений
J2EE),
могут немедленно получить выгоду от использования много
ядерных технологий.
•
Приложения в нескольких экземплярах. Даже если отдельное приложение не
масштабируется, чтобы получить преимущества от использования большого числа
потоков, все еще возможно получить выгоды от многоядерной архитектуры, за
пуская несколько экземпляров приложения одновременно. Если несколько экзем
пляров приложения требуют определенной степени изоляции, для предоставления
каждому из них собственной отдельной и безопасной среды выполнения можно
использовать технологию виртуализации (для аппаратного обеспечения операци
онной системы).
Пример приложения: игровые программы
Valve -
Valve
компания, разработавшая ряд популярных игр, а также популярный игро
вой механизм ("движок"
engine) Source, который представляет собой анимационный
Valve для своих игр и лицензированный для других
-
механизм, широко используемый
разработчиков.
За последние годы
Valve
переписала программное обеспечение
Source
таким обра
зом, чтобы использовать все преимущества многопоточности на многоядерных процес
сорах от
AMD [200]. Переделанный механизм Source обеспечивает более мощную
Valve, таких как Half Life 2.
зрения Valve имеются следующие варианты зернистости потоков [102].
Intel
и
поддержку игр
С точки
•
Грубая многопоточность. Отдельные модули, именуемые системами, назначают
ся отдельным процессорам. В случае механизма
Source
-
ринг на одном процессоре, искусственный интеллект
третьем и так далее
-
это будет означать ренде
на другом, физику
-
на
простое и прямолинейное решение. В сущности, каждый
модуль является однопоточным, а глобальная координация включает синхрониза
цию всех потоков с потоком временной шкалы.
•
Тонкая многопоточность. Много похожих или идентичных задач распределено
между несколькими процессорами. Например, цикл, выполняющий итерации над
массивом данных, можно разделить на несколько небольших циклов в отдельных
потоках, которые могут выполняться параллельно.
•
Гибридная многопоточность. Данная многопоточность предполагает избиратель
ное использование тонкой многопоточности для одних систем и однопоточность
для других.
Компания
Valve
обнаружила, что при использовании грубой многопоточности можно
достичь двукратного повышения
производительности на двух процессорах по сравне
нию с выполнением на одном процессоре. Однако такой прирост производительности
может быть достигнут только для искусственно созданных случаев. Для реальных игр
улучшение оказывается примерно в
1,2
раза. Было также установлено, что эффективное
232
ГЛАВА 4. Потоки
использование мелкозернистой многопоточности
-
достаточно трудная задача. Время
выполнения единичного объема работы может быть переменным, так что глобальное уп
равление временной шкалой приложения требует сложного программирования.
Выяснилось также, что гибридный подход является наиболее перспективным и обес
печивающим лучшее масштабирование для многоядерных систем с
рами.
Valve
8
или
16
процессо
определила системы, которые очень эффективно работают при назначении
одному процессору. Примером может служить система микширования звука, которая
мало взаимодействует с пользователями, не ограничена оконной конфигурацией и рабо
тает с собственным набором данных. Другие модули, такие как обеспечивающие ренде
ринг сцены, могут быть организованы в виде нескольких потоков так, что модуль может
выполняться и на одном процессоре, но при этом чем больше процессоров ему доступ
но, тем большей оказывается его производительность.
Рендеринr
Основное представление
VIР-места
Прочее
Монитор
Список сцен
Для каждого объекта
Частицы
Имитация и вывод
Персонаж
Конфигурация каркаса
Вывод
Прочие
Рис.
На рис.
4.9
4.9.
Гибридная многопоточность для модуля рендеринга
показана структура потоков модуля рендеринга. В этой иерархической
структуре потоки высокого уровня при необходимости создают потоки низкого уровня.
Модуль основан на критической части механизма
Source -
на списке, который является
представлением базы данных визуальных элементов в мире игры. Первая задача заклю
чается в определении, какие области игрового мира должны быть отображены. Следу
ющая задача состоит в выяснении, какие объекты находятся в сцене при рассмотрении
ее под разными углами, с нескольких точек. Затем наступает время интенсивной работы
процессора. Модуль рендеринга должен визуализировать каждый объект с нескольких
точек зрения, таких как точка зрения игрока, монитора или отражения в воде.
4.4. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ В
WINOOWS
233
Некоторые из ключевых элементов стратегии многопоточности для модуля ренде
ринга перечислены в
•
[148]
и включают следующее.
Построение списков рендеринга сцен параллельно для нескольких сцен (напри
мер, мир и его отражение в воде).
•
Симуляция перекрытия изображений.
•
Параллельное вычисление трансформаций каркаса для всех персонажей во всех
сценах.
•
Разрешение параллельного вывода с помощью нескольких потоков.
Проектировщики обнаружили, что простая блокировка ключевых баз данных, таких
време
как списки элементов мира, на уровне потоков слишком неэффективна. Более
95%
ни поток пытается прочитать информацию из набора данных и не более
времени
5%
-
выполнять запись. Таким образом, в этом случае эффективно работает механизм парал
лельных вычислений, известный как модель "один писагель
4.4.
-
несколько читагелей".
УПРАВЛЕНИЕ ПРОЦЕССАМИ
И ПОТОКАМИ В WINDOWS
Этот раздел начинается с обзора ключевых объектов и механизмов, которые поддер
живают выполнение приложений в
Windows.
В оставшейся части раздела более подроб
но рассматривается управление процессами и потоками в
Windows.
Приложение состоит из одного или нескольких процессов. Каждый процесс предо
ставляет ресурсы, необходимые для выполнения программы. Процесс имеет вир'I)'альное
адресное пространство, выполнимый код, открытые дескрипторы системных объектов,
контекст безопасности, уникальный идентификатор процесса, переменные среды, класс
приоритета, минимальный и максимальный размеры рабочего множества и по крайней
мере один поток выполнения. Каждый процесс запускается с одним потоком, который
часто называют основным или первичным, но любой из его потоков может создавать
дополнительные потоки.
Поток является сущностью в рамках процесса, которая может быть запланирована
к выполнению. Все потоки процесса разделяют его виртуальное адресное пространство
и системные ресурсы. Кроме того, каждый поток поддерживает обработчики исключе
ний, приоритет планирования, локальную память потока, уникальный идентификатор
потока и набор структур, которые система будет использовать для сохранения контекста
потока до тех пор, пока он не будет запущен планировщиком. В многопроцессорном
компьютере система может одновременно выполнять столько потоков, сколько имеется
процессоров.
Объект задания
Gob object)
позволяет группировать процессы для управления ими
как единым целым. Объекты заданий представляют собой именуемые, защищаемые,
совместно используемые объекты, которые управляют атрибутами связанных с ними
процессов. Операции, выполняемые над объектами заданий, влияют на все процессы,
связанные с объектом задания. Примеры включают соблюдение ограничений, такие как
размер рабочего множества или приоритет процесса, или завершение работы всех про
цессов, связанных с заданием.
234
ГЛАВА 4. Потоки
Пул потоков
это коллекция рабочих потоков, которые эффективно выполняют
-
асинхронные обратные вызовы от имени приложения. Пул потоков используется глав
ным образом для сокращения числа потоков приложения и управления рабочими по
токами.
Волокно
(fiber) -
это единица выполнения, которая должна планироваться приложе
нием вручную. Волокна выполняются в контексте потоков, которые их планируют. Каж
дый поток может планировать несколько волокон. В общем случае волокна не предостав
ляют преимущества по сравнению с хорошо спроектированным многопоточным приложе
нием. Однако применение волокон может упростить перенос приложений, которые были
разработаны с применением планирования собственных потоков. С точки зрения системы
волокно является тождественным потоку, который его выполняет. Например, если волокно
обращается к локальной памяти потока, оно обращается к локальной памяти того потока,
которые его выполняет. Кроме того, если волокно вызывает функцию
Exi tThread,
то
поток, который его выполняет, завершает свою рабоrу. Однако волокно не имеет всей той
же информации о состоянии, связанной с ним, что и информация, связанная с потоком.
Единственная поддерживаемая волокном информация о состоянии
-
его стек, подмно
жество его регистров и данные волокна, предоставленные при его создании. Сохраненные
регистры представляют собой набор регистров, обычно сохраняемых при вызове функции.
Волокна не подпежат вытесняющему планированию. Поток выполняет планирование, пе
реключаясь на одно волокно с другого. Система же по-прежнему занимается планирова
нием выполнения потоков. Когда прерывается поток, выполняющий волокна, выполнение
текущего волокна прерывается, но оно остается выбранным.
Пользовательский режим планирования
(user-mode scheduling -
UMS)
представляет
собой облегченный механизм, который приложения могут использовать дпя планирования
собственных потоков. Приложение может переключаться между потоками
UMS
в пользо
вательском режиме без участия системного планировщика и восстанавливать контроль над
процессором, если поток
UMS
блокируется в ядре. Каждый поток
UMS
имеет собствен
ный контекст вместо совместного использования контекста единственного потока. Воз
можность переключения между потоками в пользовательском режиме делает
UMS
более
эффективным, чем пул потоков дпя краткосрочной работы, которая требует нескольких
системных вызовов.
UMS
полезен для приложений с высокими требованиями к произво
дительности, которые должны эффективно выполнять несколько потоков одновременно на
многопроцессорных или многоядерных системах. Чтобы воспользоваться преимущества
ми
UMS,
приложение должно реализовать компонент планировщика, который управляет
UМS-потоками приложения и определяет, когда они должны быть выполнены.
Управление фоновыми задачами
и жизненным циклом приложений
Начиная с
Windows 8
и до
Windows 1О
за управление состоянием отдельных прило
жений отвечают их разработчики. Предыдущие версии
Windows
всегда давали полный
контроль над жизненным циклом процесса пользователю. В классической среде рабо
чего стола ответственность за закрытие приложения несет пользователь. При этом мо
жет открыться диалоговое окно, предлагающее сохранить сделанную рабоrу. В новом
интерфейсе
Metro
за процесс жизненного цикла приложения отвечает
одновременно с пользовательским интерфейсом
Metro
Windows.
Хотя
с использованием функциональ-
4.4. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ В
ности
SnapView
WINDOWS
235
параллельно с основным приложением может выполняться ограничен
ное количество приложений, в любой момент времени может выполняться только одно
приложение
Store.
Это является прямым следствием нового дизайна.
Windows Live Tiles
показывает приложения, запущенные в системе, получая рush-уведомления и не исполь
зуя системные ресурсы для отображения предлагаемого динамического содержимого.
Приложение переднего плана в интерфейсе
Metro
имеет доступ ко всем процессор
ным, сетевым и дисковым ресурсам, доступным пользователю. Все прочие приложения
приостанавливаются и не имеют доступа к этим ресурсам. Когда приложение входит в
режим приостановки, должно быть запущено событие для сохранения состояния поль
зовательской информации. За это отвечает разработчик приложения.
Windows
может за
вершить фоновое приложение по ряду причин, например из-за потребности в ресурсах,
или из-за тайм-аута. Это существенное отличие от предшествующих версий операцион
ных систем
Windows.
Приложение должно сохранить любые введенные пользователем
данные, измененные им настройки и т.д. Это означает, что вы должны сохранить состо
яние вашего приложения при его приостановке в случае, если
Windows
завершает его,
так, чтобы восстановить его состояние позже. Когда приложение возвращается на пере
дний план, запускается другое событие
-
для получения пользовательского состояния
из памяти. При прекращении работы фонового приложения никакие события не иниции
руются. Вместо этого данные приложения остаются резидентными в системе (как будто
приложение просто приостановлено) до тех пор, пока приложение не будет запущено
снова. Пользователи находят приложение в том же состоянии, в котором они его оста
вил и, независимо от того, было ли оно приостановлено или прекращено
Windows
или
закрыто пользователем. Прикладные программисты могут использовать код для выясне
ния, следует ли восстанавливать сохраненное состояние приложения.
Некоторые приложения, такие как каналы новостей, могут смотреть на дату преды
дущего выполнения и выбрасывать старые данные, освобождая место для новой инфор
мации. Это выяснение даты выполняется разработчиком приложения, а не операционной
системой. Если приложение закрывает пользователь, то несохраненные данные теряют
ся. Приложения переднего плана, занимающие все системные ресурсы и приводящие к
голоданию фоновых приложений
печальная реальность
-
ки важным для успеха приложения в
Windows
Windows.
Поэтому критичес
является его разработка с учетом возмож
ности изменений состояния.
Для обработки потребностей фоновых задач создан специальный интерфейс при
кладного программирования
(API)
для фоновых задач, который позволяет приложениям
выполнять небольшие задачи, пока они не находятся на переднем плане. В такой ог
раниченной среде приложения могут получать рush-уведомления от сервера или поль
зователь может принять телефонный звонок. Рush-уведомления являются шаблонными
ХМL-строками. Они управляются посредством облачной службы, известной как служба
уведомлений
Windows (Windows Notification Service -
WNS).
Время от времени она
будет передавать уведомления фоновым приложениям пользователя.
API
будет ставить
эти запросы в очередь и обрабатывать их, когда будет получать достаточные для этого
ресурсы процессора. Фоновые задачи серьезно ограничены в использовании процессо
ра, получая только одну процессорную секунду из каждого процессорного часа. Такая
стратегия гарантирует, что критические задачи будут получать необходимую им квоту
ресурсов, но не гарантирует, что будут работать фоновые приложения.
236
ГЛАВА 4. Потоки
Процессы в
Windows
Важными характеристиками процессов
•
•
•
•
Windows
Процессы
Windows
являются следующие.
реализованы как объекты.
Процесс может быть создан как новый процесс или как копия существующего.
Выполнимый процесс может содержать один или несколько потоков.
Как объекты процессов, так и объекты потоков имеют встроенные возможности
синхронизации.
На рис.
4.1 О
(основанном на
[212])
проиллюстрирован способ взаимосвязи между
процессом и ресурсами, которыми этот процесс управляет или которые использует. В це
лях безопасности каждому процессу присваивается признак доступа, который называется
первичным токеном
(token)
или маркером процесса. При входе пользователя в
Windows
создается маркер доступа, в который входит идентификатор безопасности пользователя.
Каждый процесс, который создается данным пользователем или запускается от его име
ни, содержит копию этого маркера. Указанный маркер используется операционной сис
темой
Windows
для проверки возможности доступа пользователя к защищенным объек
там или возможности выполнения специальных функций в системе и над защищенными
объектами. Маркер доступа управляет возможностью изменения процессом собственных
атрибутов. В этом случае процесс не имеет дескриптора, открытого для его маркера до
ступа. Если процесс попытается открыть такой дескриптор, система безопасности опре
делит, разрешено ли это, а значит, может ли процесс изменить свои атрибуты.
С процессами связан и ряд блоков, которые определяют виртуальное адресное про
странство, закрепленное в данный момент за процессом. Процесс не может непосред
ственно изменять эти структуры; в этом он должен полагаться на менеджер виртуальной
памяти, предоставляющий сервис выделения памяти процессу.
Дескрипторы виртуального адресного пространства
Объект
процесса
Таблица
дес крипторов
Дескриптор
1
Дескриптор
2
Поток х
Файл у
1-
Дескриптор
3
Доступные
бъекты
Раздел
1
1
z
•
•
•
Рис.
4.1 О.
Процессы
Windows
и их ресурсы
4.4. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ В
WINDOWS
237
Наконец, процесс включает таблицу объектов, которая управляет другими объектами,
известными процессу. На рис.
4.1 О
показан один поток, но их может быть много. Кроме
того, процесс имеет доступ к объектам файлов и разделов, которые определяют раздел
совместно используемой памяти.
Объекты процессов и потоков
Объектно-ориентированная структура операционной системы
Windows облегчает раз
Windows использует
Процесс - это объект,
работку подсистемы общего назначения для работы с процессами.
два типа связанных с процессами объектов: процессы и потоки.
соответствующий заданию или приложению пользователя, который владеет собствен
ными ресурсами, такими как память и открытые файлы. Поток
-
это диспетчеризуемая
единица работы, которая выполняется последовательно и является прерываемой, что
позволяет процессору переключиться на выполнение другого потока.
Каждый процесс в операционной системе
Windows
представлен объектом. Каждый
объект процесса включает некоторое количество атрибутов и инкапсулирует ряд дейс
твий, или служб, которые он может выполнять. Процесс будет выполнять действия при
вызове через ряд опубликованных методов интерфейса. При создании нового процесса
операционная система
Windows
использует класс или тип объекта, определенный как
шаблон процесса для генерации новых экземпляров объектов процессов
Windows.
Во
время создания объекта его атрибутам присваиваются конкретные значения. В табл.
4.3
приводится краткое описание каждого атрибута процессов.
ТАБЛИЦА
4.3.
АТРИБУТЫ ОБЪЕКТА ПРОЦЕССА WINDOWS
Идентификатор
Уникальное значение, идентифицирующее процесс в операцион
процесса
ной системе
Дескриптор защиты
Описывает, кто создал объект, кто обладает правом доступа к нему
или может им пользоваться и кто определяет права доступа к объекту
Базовый приоритет
Базовый приоритет выполнения потоков, принадлежащих процессу
Процессор
Заданный по умолчанию набор процессоров, на котором возможно
по умолчанию
выполнение потоков процесса
Квоты
Максимальное количество страничной и прочей системной памяти,
объем в страничном файле и процессорное время, доступные данному процессу
Время выполнения
Суммарное время, затраченное на выполнение всех потоков про
цесса
Счетчики
Переменные, в которые заносятся сведения о количестве и типе
ввода-вывода
операций ввода-вывода, выполненных потоками процесса
Счетчики операций с
Переменные, в которые заносятся сведения о количестве и типе
виртуальной памятью
операций с виртуальной памятью, выполненных потоками процесса
Порты исключений/
Каналы обмена информацией между процессами, в которые дис
отладки
петчер процессов должен отправить сообщение при возникнове
нии исключительной ситуации из-за одного из потоков процесса
Состояние выхода
Причина завершения процесса
ГЛАВА 4. Потоки
238
Процесс
Windows
перед выполнением должен содержать хотя бы один поток, который
затем может создавать другие потоки. В многопроцессорной системе несколько потоков
одного и того же процесса могут выполняться параллельно. В табл.
4.4
определены ат
рибуты объекта потока. Заметим, что некоторые атрибуты потока подобны атрибутам
процесса. Значения таких атрибутов потока извлекаются из значений соответствующих
атрибутов процесса. Например, в многопроцессорной системе сродные потоку процес
соры
-
это множество процессоров, на которых может выполняться данный поток; это
множество совпадает с множеством процессоров, сродных процессу, или является его
подмножеством.
Обратите внимание, что одним из атрибутов процесса является его контекст, который
содержит значения регистров процессора при последнем выполнении потока. Эта инфор
мация позволяет операционной системе приостанавливать и возобновлять потоки. Более
того, приостановив поток и изменив его контекст, можно изменить его поведение.
Т А&лицА
4.4. АтРи&vты о&ъектА потокА Wrнoows
Идентификатор
Уникальное значение, идентифицирующее поток, когда он вызы
потока
вает сервис
Контекст потока
Набор значений регистров и другие данные, которыми определя
ется состояние выполнения потока
Динамический
Приоритет выполнения потока в данный момент времени
приоритет
Базовый приоритет
Процессоры потока
Нижний предел динамического приоритета потока
Множество процессоров, на которых может выполняться поток.
Это множество является подмножеством процессоров, сродных
процессу потока, или совпадает с ним
Время выполнения
Совокупное время, затраченное на выполнение потока в пользо
потока
вательском режиме и в режиме ядра
Статус оповещения
Флаг, который указывает, следует ли потоку выполнять асинхрон
ный вызов процедуры
Счетчик
В нем указывается, сколько раз выполнение потока было приос
приостановок
тановлено без последующего возобновления
Признак
Временный признак доступа, позволяющий потоку выполнять опе
имперсонации
рации от имени другого процесса (используется подсистемами)
Порт завершения
Канал обмена информацией между процессами, на который дис
петчер процессов должен отправить сообщение при завершении
потока (используется подсистемами)
Состояние
Причина завершенияпотока
выхода потока
Многопоточность
Операционная система
Windows
поддерживает параллельное выполнение процессов,
потому что потоки различных процессов могут выполняться параллельно (демонстри
руя одновременное выполнение своей работы). Более того, нескольким потокам одного
4.4. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ
8 WINDOWS
239
и того же nроцесса могут быть выделены различные nроцессоры, и эти nотоки также
могут выnолняться одновременно. Параллелизм достигается в мноrопоточном процессе
без накладных расходов на использование нескольких процессов. Потоки одного и того
же процесса могут обмениваться между собой информацией с nомощью общего адрес
ного nространства и имеют достуn к совместным ресурсам процесса. Потоки, принадле
жащие разным nроцессам, могут обмениваться между собой информацией с nомощью
общей области памяти, установленной для этих двух процессов.
Объектно-ориентированный многоnоточный процесс является эффективным средс
твом реализации серверных приложений. Наnример, один обслуживающий nроцесс мо
жет обслуживать несколько клиентов. Каждый заnрос клиента приводит к созданию в
сервере нового nотока.
Состояния потоков
Поток, созданный в
4.11 ).
(рис.
Windows,
может находиться в одном из шести состояний
Перечислим эти состояния.
Работоспособный
Резервный
Вытеснение
Снятие блокировки/
возобновление
Ресурсы доступны
Ресурсы
оступны
Переходный
Снятие блокировки
Ресурсы недоступны
Завершение
Ожидающий
Завершенный
Неработоспособный
Рис.
4.11.
Состояния потоков в операционной системе
Windows
1. Готовый к выполнению. Поток, который может быть направлен на выполнение.
Дисnетчер ядра отслеживает все готовые к выполнению nотоки и осуществляет
их nланирование в соответствии с приоритетом.
2.
Резервный. Поток, который будет заnущен следующим на данном nроцессоре.
Поток находится в этом состоянии до тех
nop,
nока процессор не освободится.
Если приоритет резервного nотока достаточно высок, то он может вытеснить
выnолняющийся в данный момент nоток. В nротивном случае резервный nоток
ждет, пока nроизойдет блокировка выnолняющегося потока или пока истечет вы
деленный ему nромежуток времени.
240
3.
ГЛАВА 4. Потоки
Выполняющийся. Как только диспетчер ядра выполнит переключение потоков,
резервный поток перейдет в состояние выполнения и будет пребывать в нем до
тех пор, пока не произойдет одно из следующих событий: поток будет вытеснен,
закончится отведенный ему интервал времени, поток будет блокирован или завер
шен. В первых двух случаях поток снова переходит в состояние готовности.
4.
Ожидающий. Поток входит в состояние ожидания, если
1)
ким-то событием (например, операцией ввода-вывода),
он добровольно ждет
синхронизации или
3)
2)
он блокирован ка
среда подсистемы предписывает потоку, чтобы он сам себя
приостановил. После того как условия ожидания удовлетворены, поток переходит
в состояние готовности, если все его ресурсы доступны.
5.
Переходный. Поток переходит в это состояние, если он готов к выполнению, но
ресурсы недоступны (например, страницы стека потока могут быть сброшены на
диск). После того как необходимые ресурсы станут доступными, процесс перей
дет в состояние готовности.
6.
Завершенный. Завершение потока может быть инициировано самим потоком
либо другим потоком или может произойти вместе с завершением родительско
го процесса. После завершения необходимых операций освобождения ресурсов и
тому подобного поток удаляется из системы (или может быть сохранен исполни
тельной системой 6 ДJIЯ дальнейшей повторной инициализации).
Поддержка подсистем операционной системы
Средства общего назначения ДJIЯ работы с процессами и потоками должны поддержи
вать структуры процессов и потоков, соответствующие различным средам операционной
системы. В обязанности каждой подсистемы входит использование функций обработки
процессов и потоков операционной системы
Windows
для эмуляции функций обра
ботки процессов и потоков соответствующей подсистемы операционной системы. Сис
тема управления процессами и потоками довольно сложна; здесь мы приводим лишь ее
краткий обзор.
Процесс создается по запросу приложения операционной системы, который поступа
ет в соответствующую защищенную подсистему. Подсистема, в свою очередь, отправ
ляет запрос на создание процесса исполнительной системе
Windows,
которая создает
объект-процесс и возвращает подсистеме его дескриптор. Создавая процесс, операцион
ная система
Windows
не создает поток автоматически (в отличие от
Win32,
создание но
вого процесса в которой всегда сопровождается созданием потока). Поэтому подсистема
Win32
повторно обращается к менеджеру процессов
Windows,
чтобы создать поток но
вого процесса и получить его дескриптор. Затем соответствующая информация о потоке
и процессе возвращается приложению. В
подсистема
POSIX
POSIX
потоки не поддерживаются. Поэтому
получает поток ДJiя нового процесса от
Windows,
так что процесс
может быть активирован, но приложению возвращается только информация о процессе.
Тот факт, что процесс
нительной системой
POSIX реализуется с помощью как процесса, так
Windows, ДJiя приложения остается незамеченным.
6 Исполнительная система Windows описана в главе
и потока испол
2, "Обзор операционных систем". Она вклю
чает базовые службы операционной системы, такие как управление памятью, процессами и потока
ми, безопасностью, вводом-выводом и межпроцессным взаимодействием.
4.5. УПРАВЛЕНИЕ потокАми и SMP в SoLARIS
241
Когда исnолнительной nодсистемой создается новый лроцесс, он наследует многие
атрибуты создавшего его nроцесса. Однако в среде
Win32
лроцесс создается неnрямым
образом. Процесс клиентского nриложения генерирует заnрос на создание лроцесса в
адрес nодсистемы
Win32;
nодсистема, в свою очередь, отnравляет залрос на создание
nроцесса исnолнительной системе
Windows.
Так как новый лроцесс должен наследовать
характеристики процесса-клиента, а не обслуживающего лроцесса,
Windows
позволяет
подсистеме указывать родительский процесс нового процесса. Затем новый процесс на
следует маркер доступа, квоты, базовый приоритет и принятое
no
умолчанию сродство
процессоров родительского процесса.
4.5.
УПРАВЛЕНИЕ ПОТОКАМИ и SMP в SOLARIS
В операционной системе
Solaris
реализован многоуровневый nодход к управлению по
токами, способствующий значительной гибкости исnользования процессорных ресурсов.
Многопоточная архитектура
В операционной системе
Solaris
используются четыре отдельные концепции, связан
ные с лотоками.
1.
Процесс. Это обычный процесс
UNIX,
который включает в себя лользовательское
адресное пространство, стек и управляющий блок процесса.
2.
Потоки на пользовательском уровне. Эти потоки реализуются с помощью биб
лиотеки потоков в адресном пространстве лроцесса; они невидимы для операци
онной системы. Потоки на пользовательском уровне (user-level thread -
ULT 7)
играют роль интерфейса для параллелизма приложений.
3.
Облегченные процессы. Облегченный лроцесс
(lightweight process -
LWP)
мож
но рассматривать как отображение между лотоками на пользовательском уровне
и потоками ядра. Каждый из облегченных процессов поддерживает один или не
сколько nотоков на пользовательском уровне и отображает их в один поток ядра.
Планирование облегченных лроцессов производится ядром независимо. В много
процессорной системе облегченные процессы могут вьшолняться параллельно на
нескольких nроцессорах.
4.
Потоки ядра. Эти лотоки являются фундаментальными элементами; лланирова
ние и выполнение каждого из них может осуществляться на одном из системных
процессоров.
На рис.
4.12
проиллюстрирована взаимосвязь между этими четырьмя элементами.
Заметим, что каждому облегченному процессу всегда соответствует один поток ядра.
Облегченный процесс видим для приложения в рамках процесса. Таким образом, струк
туры данных облегченного процесса существуют в рамках адресного пространства со
ответствующего им процесса. В то же время каждый облегченный процесс связан с
единственным диспетчеризуемым потоком ядра, а структуры данных этого потока ядра
поддерживаются в адресном пространстве ядра.
7 Эта аббревиатура используется только в данной книге; ее нет в литературе, посвященной
Solaris.
242
ГЛАВА 4. Потоки
Процесс
Поток
Поток
ядра
ядра
Системные вызовы
Ядро
Аппаратное обеспечение
Рис.
4.12.
Процессы и потоки в
Процесс может состоять из одного
ULT,
Solaris [ 167)
связанного с одним
LWP.
В этом случае
имеется единственный поток выполнения, соответствующий традиционному процессу
UNIX.
Если в рамках одного процесса параллелизм не требуется, приложение исполь
зует эту структуру процесса. Если же приложению нужен параллелизм, его процесс со
держит несколько потоков, каждый из которых связан с одним
LWP,
который, в свою
очередь, связан с одним потоком ядра.
Кроме того, имеются потоки ядра, не связанные с
LWP.
Ядро создает, выполняет и
уничтожает эти потоки ядра для выполнения определенных системных функций. Ис
пользование потоков ядра вместо процессов ядра для реализации системных функций
уменьшает накладные расходы переключения в ядре (из процесса в поток).
Мотивация
Трехуровневая структура потока
(ULT, LWP,
поток ядра) в
Solaris
предназначена для
облегчения управления потоками со стороны операционной системы и обеспечения яс
ного интерфейса для приложений. ULТ-интерфейс может быть библиотекой стандартных
потоков. Определенные
ULT
отображаются на
LWP,
которые управляются операционной
системой; те же взаимно однозначно связаны с потоками ядра. Таким образом, управле
ние параллелизмом и выполнением происходит на уровне потоков ядра.
Кроме того, приложение имеет доступ к аппаратному обеспечению через интерфейс
прикладного программирования, состоящий из системных вызовов. Этот АР! позволяет
пользователю вызывать службы ядра для выполнения от имени вызывающего процесса
привилегированных задач, таких как чтение или запись файлов, выдача команд управле
ния устройствами, создание новых процессов или потоков, выделение памяти для про
цессов и т.д.
Структура процессов
На рис.
4.13
приведено общее сравнение структуры процессов в традиционной опе
рационной системе
UNIX
со структурой процессов в операционной системе
Solaris.
4.5. УпРдВЛЕНИЕ потокдми и SMP в SoLдR1s
В типичных реализациях
UNIX
243
в структуру процесса входят такие составляющие:
•
идентификатор процесса,
•
идентификаторы пользователя,
•
таблица диспетчеризации сигналов, которую ядро использует для того, чтобы принимать решение о том, что должно быть сделано при отправке сигнала процессу;
•
дескрипторы файлов, описывающие состояние используемых процессом файлов;
•
схема распределения памяти, определяющая адресное пространство процесса;
•
структура состояния процессора, включающая стек ядра для процесса.
В операционной системе
Solaris
эта базовая структура остается, но в ней блок состо
яния процессора заменен списком структур, в котором для каждого облегченного про
цесса имеется свой блок данных.
Структура процесса в
В структуру данных облегченного процесса входят такие элементы:
•
•
идентификатор облегченного процесса;
приоритет данного облегченного процесса (и следовательно, потока ядра, который
его поддерживает);
•
маска сигналов, предоставляющая ядру информацию о том, какие сигналы могут
быть восприняты процессом;
•
сохраненные значения регистров пользовательского уровня (когда облегченный
процесс не выполняется);
•
стек ядра данного облегченного процесса, в который входят аргументы системного
вызова, результаты и коды ошибок каждого уровня;
•
данные по использованию ресурсов и профилированию;
•
указатель на соответствующий поток ядра;
•
указатель на структуру процесса.
Выполнение потоков
На рис.
4.14
показана упрощенная схема состояний выполнения потоков. Эти состо
яния отражают статус выполнения как потоков ядра, так и связанных с ними облегчен
ных процессов. Как упоминалось ранее, некоторые потоки ядра не связаны с облегчен
ными процессами; к ним применима та же диаграмма.
ресурсы потока освобождены и поток ожидает удаления из структуры дан
ных потоков операционной системы.
• PINNED:
контекст сохраняется, и поток приостанавливается до тех пор, пока не
будет обработано прерывание.
Поток перемещается из состояния
ONPROC
в
RUN
при вытеснении потоком с более
высоким приоритетом или из-за завершения кванта времени. Поток перемещается из со
стояния
ONPROC
в
SLEEP,
если он заблокирован и должен ожидать некоторого события
для возвращения в состояние
RUN.
Блокирование выполняется, если поток осуществля
ет системный вызов и должен ожидать его завершения. Поток входит в состояние
STOP,
если его процесс останавливается; это может быть сделано в целях отладки.
Прерывания в роли потоков
В большинстве операционных систем приняты две основные формы параллельной
деятельности: процессы и прерывания. Процессы (или потоки) взаимодействуют один с
другим и управляют использованием совместных структур данных с помощью различ
ных примитивов, обеспечивающих взаимоисключения (когда в каждый момент времени
только один процесс может выполнять определенный код или осуществлять доступ к
определенным данным) и синхронизирующих их выполнение. Прерывания синхронизи
руются путем предотвращения их обработки на некоторое время. В операционной сис
теме
Solaris эти
две концепции объединяются в одной модели потоков ядра; прерывания
в такой модели преобразуются в потоки ядра.
Эти преобразования выполняются для сокращения накладных расходов. Обработчики
прерываний часто манипулируют данными, которые используются совместно с осталь
ной частью ядра. Поэтому во время работы процедуры ядра, осуществляющей доступ
к этим данным, прерывания должны быть заблокированы, даже если большинство пре
рываний не оказывают влияния на эти данные. Обычно для этого приходится повышать
уровень приоритета прерываний, чтобы блокировать прерывания на время выполнения
подпрограммы. После завершения подпрограммы уровень приоритета понижается. Все
эти операции отнимают время. В многопроцессорной системе проблема усиливается.
Ядро должно защищать большее количество объектов, и ему может понадобиться бло
кировать прерывания на всех процессорах.
Solaris, выглядит так.
Solaris используются потоки
Решение, принятое в операционной системе
1.
Для обработки прерываний в системе
ядра. Как и
любой другой поток ядра, поток прерывания обладает собственным идентифика
тором, приоритетом, контекстом и стеком.
2.
Ядро управляет доступом к структурам данных и синхронизирует потоки преры
ваний с помощью примитивов взаимоисключений (рассматривающихся в главе
5,
246
ГЛАВА 4. Потоки
"Параллельные вычисления: взаимоисключения и многозадачность"). Таким об
разом, для обработки прерываний используются обычные методы синхронизации
потоков.
3.
Потокам прерываний присваиваются более высокие приоритеты, чем всем другим
типам потоков ядра.
Если происходит прерывание, оно передается определенному процессору, а выполня
ющийся на этом процессоре поток закрепляется. Закрепленный
(pinned)
поток не может
перейти на другой процессор; его контекст сохраняется, и процесс приостанавливается
до тех пор, пока не будет обработано прерывание. После этого процессор приступает к
выполнению потока прерывания. В наличии всегда имеется запас деактивированных по
токов прерываний, так что новый поток создавать не нужно. Затем выполняется поток, в
котором происходит обработка прерывания. Если программе обработки понадобится до
ступ к структуре данных, которая каким-то образом заблокирована и используется дру
гим потоком, поток прерывания должен ждать. Поток прерывания может быть вытеснен
только другим потоком прерывания с более высоким приоритетом.
Опыт использования потоков прерываний в операционной системе
Solaris
свидетель
ствует о том, что такой подход обеспечивает производительность, превосходящую про
изводительность традиционных методов обработки прерываний
4.6.
[132).
УПРАВЛЕНИЕ ПРОЦЕССАМИ
И ПОТОКАМИ В LINUX
Задания
Linux
В операционной системе
данных
task_struct.
Linux
процесс, или задание, представляется структурой
В этой структуре данных информация разбита на следующие
категории.
•
Состояние. Состояние выполнения процесса (выполняющийся, готовый к выпол
нению, приостановленный, остановленный, зомби).
•
Информация по планированию. Информация, которая нужна операционной
системе
Linux
для планирования процессов. Процесс может быть обычным или
выполняющимся в реальном времени; кроме того, он обладает некоторым приори
тетом. Процессы, выполняющиеся в реальном времени, планируются до обычных
процессов; в каждой из категорий можно использовать относительные приорите
ты. Счетчик ведет отсчет времени, отведенного процессу.
•
Идентификаторы. Каждый процесс обладает собственным уникальным иденти
фикатором процесса
(PID),
а также идентификаторами пользователя и группы.
Идентификатор группы применяется для того, чтобы назначить группе пользова
теля права доступа к ресурсам.
•
Обмен информацией между процессами. В операционной системе
зуется такой же механизм межпроцессного взаимодействия
ционной системе
UNIX SVR4,
описанной в главе
взаимоблокировка и голодание".
6,
(IPC),
Linux
исполь
как и в опера
"Параллельные вычисления:
4.6. УПРАВЛЕНИ Е П РОЦЕССАМИ И П О Т ОКАМ И В
•
LINUX
247
Связи. Каждый процесс содержит в себе связи с параллельными ему процессами,
с родственными ему процессами (с которыми он имеет общий родительский nро
цесс) и со всеми своими дочерними процессами.
•
Время и таймеры. Сюда входят время создания процесса, а также количество
процессорного времени, затраченного на данный процесс. С nроцессом также
могут быть связаны интервальные таймеры (один или несколько). Интервальный
таймер задается в процессе с помощью системного вызова; после истечения пери
ода таймера процессу отправляется соответствующий сигнал. Таймер может быть
создан для одноразового или периодического использования.
•
Файловая система. Содержит в себе указатели на все файлы, открытые данным
процессом.
•
Адресное пространство. Определяет отведенную данному процессу виртуальную
память.
•
Контекст, зависящий от процессора. Информация по регистрам и стеку, состав
ляющая контекст данного процесса.
На рис.
•
4.15
nоказаны состояния выполнения nроцесса.
Выполняющийся. Это состояние отвечает на самом деле двум состояниям: теку
щий процесс либо выполняется, либо готов к выnолнению.
•
Прерываемый. Это состояние блокировки, в котором процесс ожидает наступле
ния события, например завершения операции ввода-вывода, освобождения ресур
са или сигнала от другого процесса.
Сигнал
Создание
Зомби
Сигнал или
событие
Рис.
4.15.
Модель процессов и потоков Liпux
ГЛАВА 4. Потоки
248
•
Непрерываемый. Это состояние блокировки другого рода. Его отличие от преды
дущего состоит в том, что в непрерываемом состоянии процесс непосредственно
ожидает выполнения какого-то аппаратного условия, поэтому он не воспринимает
никаких сигналов.
•
Остановленный. Процесс был остановлен и может быть продолжен только при
соответствующем воздействии другого процесса. Например, процесс, который на
ходится в состоянии отладки, может перейти в состояние остановки.
•
Зомби. Процесс был прекращен, но по какой-то причине его структура остается в
таблице процессов.
Потоки
Linux
Традиционные UNIХ-системы поддерживают один поток выполнения для каждого
процесса, в то время как современные UNIХ-системы обычно предоставляют поддержку
нескольких потоков на уровне ядра для каждого процесса. Как и традиционные систе
мы
UNIX,
старые версии ядра
Linux
не поддерживают многопоточность. Вместо этого
приложения необходимо было разрабатывать с набором функций библиотеки пользова
тельского уровня (наиболее популярной из которых является библиотека pthread (POSIX
thread), причем все потоки отображаются на один процесс уровня ядра 8 ). Мы видели,
что современные версии UNIX предлагают потоки на уровне ядра. Linux предоставляет
уникальное решение, состоящее в том, что оно не признает различие между потоками и
процессами. Используя механизм, похожий на облегченные процессы
Solaris,
пользова
тельские потоки отображаются на процессы уровня ядра. Несколько потоков пользова
тельского уровня, которые составляют единый процесс уровня пользователя, отобража
ются на процессы уровня ядра
Linux,
которые разделяют один и тот же идентификатор
группы. Это позволяет данным процессам совместно использовать ресурсы, такие как
файлы и память, и избегать необходимости переключения контекста, когда планировщик
выполняет переключение между процессами в одной и той же группе.
В
Linux
новый процесс создается путем копирования атрибутов текущего процесса.
Можно клонировать новый процесс так, что он будет разделять такие ресурсы, как фай
лы, обработчики сигналов и виртуальная память. Когда два процесса разделяют одну и
ту же виртуальную память, они функционируют как потоки в пределах одного процесса.
Однако для потока не определяется отдельный тип структуры данных. Вместо обычной
функции
fork ()
процессы создаются в
Linux
с помощью вызова
clone
().Эта команда
включает в себя в качестве аргументов набор флагов. Традиционный системный вызов
fork ()
реализуется в
Linux
как системный вызов
clone ()
со сброшенными флагами.
Флаги клонирования включают следующие.
• CLONE NEWPID: создание нового пространства имен PID.
• CLONE PARENT:
вызывающий процесс и новое задание разделяют один и тот же
родительский процесс.
8 POSIX (PortaЫe Operating Systems based on UNIX - переносимые операционной системы на
UNIX) представляет собой стандарт интерфейса прикладного проrраммирова11ия IEEE,
включающий стандарт потокового API. Библиотеки, реализующие стандарт POSIX Threads. часто
именуются Ptl1read. Обычно они ис11ользуются в tJNIХ-подобных системах POSIX. таких как Linux
и Solaris. но имеются их реализации и для Microsoft Windows.
основе
4.6. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ В
• CLONE SYSVSEM:
• CLONE _ THREAD:
применение семантики
из
System
У.
вставка процесса в ту же группу потоков, что и родительский
процесс. Если этот флаг имеет значение
флага
SEM_ UNDO
249
LINUX
true,
он неявно обеспечивает установку
CLONE PARENT.
• CLONE VM:
совместное использование адресного пространства (дескриптор памя
ти и все таблицы страниц).
• CLONE FS:
совместное использование информации о файловой системе (включая
текущий рабочий каталог, корень файловой системы и маску
• CLONE FILES:
совместное
использование таблицы
umask).
дескрипторов
файлов.
Создание или закрытие файлового дескриптора распространяется на другой про
цесс, так же как и изменения флагов файлового дескриптора с помощью систем
ного вызова
Когда ядро
fcntl ().
Linux
выполняет переключение контекста от одного процесса к другому,
оно проверяет, является ли адрес каталога страниц текущего процесса тем же, что и у
планируемого процесса. Если да, то они разделяют одно адресное пространство, так что
переключение контекста в основном состоит просто в переходе из одного места в коде
в другое.
Хотя клонированные процессы, которые являются частью одной и той же группы
процессов, могут разделить одно и то же пространство памяти, они не могут исполь
зовать одни и те же пользовательские стеки. Таким образом, вызов
clone ()
создает
отдельный стек для каждого процесса.
Пространства имен
С каждым процессом в
Linux
Linux
связан набор пространств имен
(namespace).
Про
странство имен позволяет процессу (или нескольким процессам, которые разделяют
одно и то же пространство имен) иметь представление системы, отличное от таково
го у других процессов,
которые имеют другие связанные с ними пространства имен.
Пространства имен и cgroups9 (которые будут описаны в следующем разделе) являются
основой облегченной виртуализации
Linux,
которая представляет собой функциональ
ную возможность, предоставляющую процессу или группе процессов иллюзию, что они
являются единственными процессами в системе. Эта функция широко используется про
ектами Linux Containers. В
mnt, pid, net, ipc, uts и user.
настоящее время имеется шесть пространств имен в
Linux:
clone (), который полу
(CLONE NEWNS,
CLONE _ NEWUTS и CLONE _ NEWUSER).
Пространства имен создаются путем системного вызова
чает в качестве параметра один из шести флагов пространств имен
CLONE _ NEWPI О, CLONE NEWNET, CLONE NEWI РС,
Процесс может также создать пространство имен с
unshare ()
с одним из этих флагов; в отличие от вызова
помощью системного вызова
clone ()
в этом случае новый
процесс не создается; создается только новое пространство имен, которое присоединя
ется к вызывающему процессу.
9 Cgroups (от англ. control group)- механизм ядра Linux, который ограничивает и изолирует вы
числительные ресурсы (процессорные, сетевые. ресурсы nамяти, ресурсы ввода-вывода) для гру1111
процессов.
-
Примеч. пер.
250
ГЛАВА 4. Потоки
пространство имен
MNT
Данное пространство имен обеспечивает процесс некоторым представлением иерархии
файловой системы таким образом, что два процесса с различными пространствами имен
mnt
будут видеть различные иерархии файловых систем. Все файловые операции, которые
выполняет процесс, применяются только к файловой системе, видимой процессу.
Пространство имен
UTS
Пространство имен
uname ( ) .
связано с системным вызовом
UTS (UNIX timesharing)
Linux
Этот вызов возвращает имя и информацию о текущем ядре, включая имя сис
темы в рамках некоторой определяемой реализацией сети, а также имя домена
(Network Information Service -
NIS. NIS
сетевая информационная служба) представляет собой
стандартную схему, используемую всеми крупными
мами. Она позволяет группе машин в домене
NIS
UNIX
и UNIХ-подобными систе
совместно использовать общий набор
конфигурационных файлов, что, в свою очередь, позволяет системному администратору
настроить клиентские системы
NIS
с использованием только минимальной конфигура
ции данных и добавлять, удалять или изменять данные конфигурации из одного мес
тоположения. Применение пространства имен
UTS
позволяет варьировать параметры
инициализации и настройки для различных процессов в одной и той же системе.
Пространство имен
IPC
Пространство имен
твия
(IPC),
IPC
изолирует некоторые ресурсы межпроцессного взаимодейс
такие как семафоры, РОSIХ-очереди сообщений и многое другое. Таким
образом, программист может использовать механизмы параллелизма, обеспечивающие
межпроцессное взаимодействие между процессами, которые разделяют одно и то же
пространство имен
IPC.
пространство имен
PID
Пространства имен
PID
изолируют пространства идентификаторов процессов, так
что процессы в разных пространствах имен
PID
erspace (CRIU).
PID. Эта воз
Linux Checkpoint/Restore In Us-
могут иметь одинаковые
можность используется в программном инструментарии
Используя этот инструмент, можно приостановить запущенное приложе
ние (или его часть) и сбросить его на жесткий диск в виде набора файлов. Затем можно
использовать эти файлы для восстановления и запуска приложения на этом же компью
тере или на другом узле для продолжения его работы. Отличительной особенностью
проекта
CRIU
является то, что он в основном реализован в пространстве пользователя
(после ряда неудачных попыток его реализации в основном в ядре).
Сетевое пространство имен
Сетевые пространства имен обеспечивают изоляцию системных ресурсов, связанных
с сетью. Таким образом, каждое сетевое пространство имен имеет собственные сетевые
устройства,
IP
адреса, таблицы маршрутизации, номера портов и т.д. Эти пространства
имен виртуализируют весь доступ к сетевым ресурсам, что позволяет каждому процессу
или группе процессов, принадлежим к такому сетевому пространству имен, при необ
ходимости получать доступ к сети. В любой момент времени сетевое устройство при
надлежит только одному сетевому пространству имен. Кроме того, сокет также может
принадлежать только одному пространству имен.
4.6. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ В
LINUX
251
пользовательское пространство имен
Пользовательские пространства имен предоставляют контейнер со своим набором
UID,
полностью отделенным от таковых в родительском наборе. Таким образом, ког
да процесс клонирует новый процесс, он может назначить новое пользовательское про
странство имен, а также новое пространство имен
PID
и все другие пространства имен.
Клонированный процесс может иметь доступ ко всем ресурсам родительского процесса
и соответствующие привилегии или подмножество ресурсов и привилегий родительско
го процесса. Пользовательские пространства имен считаются уязвимыми в смысле бе
зопасности, так как позволяют создавать непривилегированные контейнеры (процессы,
которые создаются пользователем, не являющимся корневым).
подсистема
Linux cgroup
Подсистема
Linux cgroup
вместе с подсистемой пространств имен являются основой
для виртуализации облегченных процессов, и таким образом, они формируют основу
контейнеров Linux; почти
Docker, LXC, Kubemetes и
каждый современный проект контейнеров
др.) основан на них обоих. Подсистема
Linux (такой, как
cgroups в Linux обес
печивает управление и учет ресурсов. Она обрабатывает такие ресурсы, как процессор,
сеть, память и многое другое; главным образом это необходимо на "концах спектра"
(во встраиваемых устройствах и серверах) и гораздо меньше
терах. Разработка
была начата в
cgroups
2006
"контейнеры процессов", которое позднее было изменено на
путаницы с контейнерами
Linux . .Цля
в настольных компью
-
году инженерами
реализации
Google nод названием
"cgroups", чтобы избежать
cgroups были добавлены не новые сис
(VFS), "cgroups" (которую также
темные вызовы, а новая виртуальная файловая система
иногда называют
cgroupfs), так как все ее операции основаны на файловой системе. Но
cgroups, nод названием "cgroups v2", была вылущена в версии ядра 4.5 (март
2016). Подсистема cgroup v2 решает многие проблемы несоответствия среди контрол
леров cgroup v 1 и делает cgroup v2 лучше организованной путем применения строгих и
вая версия
последовательных интерфейсов.
В настоящее время имеется
(памяти, ввода-вывода и
лерами
PID);
12
контроллеров
и
cgroup v 1
3
контроллера
cgroup v2
в настоящее время ведется работа над другими контрол
v2.
Д:Ля того чтобы использовать файловую систему
бавлять задания в
cgroups
(т.е. просматривать ее, до
cgroups
и т.д.), сначала ее следует смонтировать, как nри работе с
почти любой другой файловой системой. Файловая система
cgroup
может быть смонти
рована на любом пути файловой системы, так что многие пользовательские приложения
и проекты контейнеров используют в качестве точки монтирования
После монтирования файловой системы
cgroups
/sys/fs/cgroup.
можно создавать noдrpynnы, присоеди
нять к ним процессы и задачи, устанавливать ограничения на различные системные ре
сурсы и делать многое другое. Реализация
с реализацией
cgroup v2
cgroup vl,
вероятно, будет сосуществовать
до тех лор, пока есть проекты, использующие ее. Подобное
встречается и в других подсистемах ядра, когда новая реализация существующей под
системы заменяет текущую; например, в настоящее время сосуществуют iptaЫes и но
вые nftaЫes, а в прошлом iptaЫes сосуществовали с
ipchains.
252
ГЛАВА 4. Потоки
4. 7.
УПРАВЛЕНИЕ ПРОЦЕССАМИ
И ПОТОКАМИ В ANDROID
Прежде чем обсуждать детали подхода
Android
к управлению процессами и потока
ми, нам нужно описать концепции приложений и операций
Приложения
Приложение
Android.
Android
Android
представляет собой программное обеспечение, которое реализу
ет соответствующую функциональность. Каждое приложение
Android
состоит из одного
или нескольких экземпляров одного или нескольких из четырех типов компонентов при
ложений. Каждый компонент выполняет определенную роль в поведении приложения в
целом и каждый компонент может быть активирован в приложении независимо и даже
другими приложениями. Ниже приведены четыре типа компонентов.
1.
Операции
(activities).
Операция соответствует единому экрану, видимому в ка
честве пользовательского интерфейса. Например, приложение электронной почты
может иметь одну операцию, которая показывает список новых сообщений элек
тронной почты, другая операция состоит в составлении сообщения электронной
почты, а еще одна
-
для чтения электронной почты. Хотя операции работают
вместе, образуя единое приложение для работы с электронной почтой, каждая из
них является независимой от других.
Android различает
внутренние и экспортиру
емые операции. Другие приложения могут запускать экспортируемые операции,
которые обычно включают главный экран приложения. Однако сторонние при
ложения не могут запустить выполнение внутренних операций. Например, при
ложение камеры может запустить операцию электронной почты для составления
нового письма, чтобы поделиться с кем-то снятым фото.
2.
Службы
(services).
Службы обычно используются для выполнения фоновых опе
раций, которым требуется значительное количество времени для завершения. Это
обеспечивает малое время отклика главного потока приложения, с которым не
посредственно взаимодействует пользователь (он же
-
поток пользовательского
интерфейса). Например, служба может создать поток для воспроизведения музы
ки в фоновом режиме, пока пользователь находится в другом приложении, или
же создать поток для получения данных по сети без блокировки взаимодействия
пользователя с операцией. Служба может быть вызвана приложением. Кроме
того, существуют системные службы, которые работают все время жизни системы
Aпdroid
(Battery)
-
такие, как менеджер электропитания
или вибратора
(Vibrator).
(Power Manager),
рые являются частью процесса системного сервера
3.
Провайдеры контента
аккумулятора
Эти системные службы создают потоки, кото
(content provider).
(System Server).
Провайдер контента выступает в ка
честве интерфейса к данным приложения, который может использоваться прило
жением. Одной из категорий управляемых данных являются закрытые данные,
используемые только в приложении, содержащем провайдер контента. Например,
приложение
NotePad
(блокнот) использует провайдер контента для сохранения за
метки. Другая категория
-
общие данные, доступные нескольким приложениям.
Эта категория включает данные, хранящиеся в файловых системах, базе данных
4. 7. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ В
SQLite,
ANDROID
253
в Интернете или любом другом месте постоянного хранения, к которому
ваше приложение может получить доступ.
Получатели широковещательных сообщений
4.
(broadcast receiver).
Получатель
широковещательных сообщений отвечает на все оповещения уровня системы. Со
общения могут исходить из другого приложения, например, чтобы дать знать дру
гим приложениям, что некоторые данные загружены на устройство и доступны
для использования, или от системы, например предупреждение о низком заряде
батареи.
Каждое
приложение
работает
на
Выделенный процесс
собственной выделенной виртуальной
машине в виде единственного собствен
ного процесса, который включает в себя
и
приложение,
(рис.
4.16).
и
виртуальную
машину
Получатели ши
П ровайдеры
роковещательных
контента
сообщений
Этот подход, часто именуе
Приложение
мый моделью "песочницы", изолирует
каждое приложение от других. Таким
образом, ни одно приложение не может
иметь доступа
к
ресурсам
другого
Операции
при
ложения без предоставления специаль
ного разрешения. Каждое приложение
рассматривается как отдельный пользова-
тель
Linux
со своим уникальным иденти
Выделенная
фикатором пользователя, который приме
виртуальная
няется для предоставления разрешений.
машина
Операции
Операция представляет собой компо
нент приложения,
который
предостав
ляет экран взаимодействия с пользователями,
что-то
которые
сделать,
могут
с
например
его
помощью
Рис.
4.16.
Приложение
Android
осуществить
телефонный вызов, принять фотографии, отправить письмо по электронной почте или
посмотреть карту. Каждой операции предоставляется окно, в котором оно выводит свой
пользовательский интерфейс. Окно обычно заполняет экран, но может быть и меньшего
размера, чем экран, и размещаться поверх других окон.
Как уже упоминалось, приложение может включать несколько операций. Когда при
ложение выполняется, одна операция
находится на переднем
плане, и именно она вза
имодействует с пользователем. Операции расположены в стеке ("последним вошел
-
первым вышел") в порядке открытия каждой операции. Если пользователь переключает
ся к некоторой другой операции в пределах приложения, создается новая операция, ко
торая помещается на вершину стека; предыдущая операция переднего плана становится
вторым элементом стека данного приложения. Этот процесс может повторяться много
кратно, наращивая стек. Пользователь может вернуться к последней операции переднего
плана, нажав кнопку
Back
(назад) или используя аналогичную функцию интерфейса.
254
ГЛАВА 4. Потоки
Состояния операций
На рис.
4.17
показано упрощенное представление диаграммы переходов состояний
операций. Имейте в виду, что в каждом приложении может быть много операций, и каж
дая из них может находиться в собственной точке на диаграмме переходов . При запуске
новой операции программное обеспечение приложения выполняет ряд вызовов
Manager АР\
(рис .
2.20): onCr e at e ()
onStart ( )
чающую инициализацию всех струкrур данных;
на экране дnя пользователя;
Activity
выполняет статическую настройку операции, вклю
onResume ( )
делает операцию видимой
передает управление операции, так что вводи
мые пользователем данные поступают именно к ней. В этот момент операция находится
в состоянии "Возобновленная"
которое также называют жизненным цuклом
переднего плана
время операция находится на экране на пере
(Resumed),
(foreground lifetime). В это
днем плане, перед всеми иными операциями, и получает фокус ввода пользователя .
с
Операция
1
- 1
onCreate ()
запущена
"
Подный
жизнешrый
цикл
1
Польз ователь
переХОДИТ
копе рации
"
onStart ()
Видимый
жизненный
цикл
1
)
прил ожени я
прекращен
t
11
: onRes tart () 1
'
~
1onResurne ()
Про цесс
1
1
1
1
Жизненный цикл
переднегоТ
Пользователь
плана
возвращается
1
к операции
Восстановлена
Приложени е с более
высоким пр иоритетом
1
нуждаетс я в памяти
1
'
onPause()
1
t
-
Приостановлена
1
Пользователь перех одит
к операции
т
1
onStop()
1
t
Остановлена
1
1'
1 onDestroy () 1
t
с
Рис.
4.17.
О11ерац11я
)
прек:раще11а
Диаграмма переходов состояний операций
4. 7. УПРАВЛЕНИЕ ПРОЦЕССАМИ И ПОТОКАМИ В
ANDROID
255
Действия пользователя могут привести к запуску другой операции в рамках прило
жения. Например, во время выполнения приложения электронной почты, когда пользо
ватель выбирает определенное сообщение электронной почты, открывается новая опе
рация для просмотра этого сообщения. Система реагирует на такую операцию систем
ным вызовом
onPause (),
который помещает текущую операцию в стек, приводя ее в
состояние приостановленной. Затем приложение создает новый вид операции, которая
переходит в состояние возобновленной.
В любое время пользователь может прекратить текущую операцию с помощью кноп
ки
Back
(назад), закрытия окна или некоторых других действий, имеющих отношение
к этой операции. Затем для прекращения операции приложение вызывает
onStop
(О),
после чего обращается к операции на вершине стека и возобновляет ее. Вместе состо
яния возобновления и приостановки составляют видимый жизненный цикл операции.
В это время пользователь может видеть операцию на экране и взаимодействовать с ней.
Если пользователь оставляет одно приложение и переходит к другому, например,
чтобы перейти к главному экрану, текущая работающая операция приостанавливается,
а затем и полностью останавливается. Когда пользователь возобновляет приложение,
остановленная операция, находящаяся на вершине стека, перезапускается и становится
операцией переднего плана приложения.
завершение приложения
Если одновременно выполняется слишком много действий, системе для того, что
бы поддерживать необходимое время отклика, может потребоваться восстановить часть
основной памяти. В этом случае система будет высвобождать память, завершая работу
одной или нескольких операций внутри приложения, а также завершая процесс данного
приложения. Это позволяет освободить память, используемую для управления процес
сом, а также память для управления операциями, которые были завершены. Однако само
приложение по-прежнему существует, а пользователь не знает об изменении его статуса.
Если пользователь возвращается к этому приложению, система должна восстановить все
остановленные операции при их вызове.
Система завершает приложения в стек-ориентированном стиле: первыми закрывают
ся приложения, которые не использовались дольше всех. Закрытие приложений со служ
бами переднего плана является крайне маловероятным.
Процессы и потоки
По умолчанию приложению выделяются единственный процесс и единственный по
ток. Все компоненты приложения выполняются в единственном потоке единственного
процесса данного приложения. Чтобы избежать замедления пользовательского интер
фейса при выполнении компонентом медленных или блокирующих операций, разработ
чик может создать несколько потоков в рамках процесса и/или несколько процессов в
рамках приложения. В любом случае все процессы данного приложения и их потоки
выполняются в пределах одной и той же виртуальной машины.
Чтобы высвободить память в сильно загруженной системе, последняя может при
нудительно завершить один или несколько процессов. Как обсуждалось в предыдущем
разделе, одновременно с процессом завершаются одна или более операций, поддержива
емых этим процессом. Для определения процесса (или процессов), завершение которых
должно высвободить необходимые ресурсы, используется иерархия приоритетов. Каж-
256
ГЛАВА 4. Потоки
дый процесс в каждый момент времени существует на определенном уровне иерархии,
так что завершение процессов начинается с процессов с низким приоритетом. Уровни
иерархии в порядке убывания приоритета перечислены далее.
•
Процесс переднего плана. Процесс, необходимый для поддержки того, что в на
стоящее время делает пользователь. Процессом переднего плана может быть более
чем один процесс одновременно. Например, процессами переднего плана являют
ся одновременно как процесс, который выполняет операцию, с которой взаимо
действует пользователь (операция в состоянии "Возобновленная"), так и процесс,
который содержит службу, связанную с деятельностью операции, взаимодейству
ющей с пользователем.
•
Видимый процесс. Процесс, обеспечивающий работу компонента, который не на
ходится на переднем плане, но является видимым для пользователя.
•
Процесс службы. Процесс, выполняющий службу, которая не попадает ни в одну
из приведенных выше категорий. Примеры таких процессов включают воспроиз
ведение музыки в фоновом режиме или фоновую загрузку данных из сети.
•
•
Фоновый процесс. Процессы операций, находящихся в состоянии остановленных.
Пустой процесс. Процесс, не соответствующий ни одному из активных компонен
тов приложения. Единственная причина его существования
-
с целью кеширова
ния, для снижения времени запуска, когда этот компонент потребуется в следую
щий раз.
4.8.
МАС
os х CiRAND CENTRAL DISPATCH
Как упоминалось ранее, в главе
Central Dispatch (GCD)
2,
"Обзор операционных систем'', Мае
OS
Х
Grand
предоставляет пул доступных потоков. Проектировщики могут
указывать части приложений, именуемые блоками, которые могут быть независимо дис
петчеризованы, и работать параллельно. Операционная система будет предоставлять как
можно большую степень параллелизма, основываясь на количестве доступных ядер и
потоковой емкости системы. Хотя и другие операционные системы реализовывали пулы
потоков,
GCD
обеспечивает качественное улучшение в смысле простоты использования
и эффективности
[152].
Блок представляет собой простое расширение к языку С или к другим языкам, на
пример к С++. Целью определения блока является определение автономной единицы
работы, включая код и данные. Вот простой пример определения блока:
х = л{printf("hello
world\n");)
Блок обозначается с помощью знака вставки (л) в начале функции, которая заключе
на в фигурные скобки. Приведенное выше определение блока определяет х как способ
вызова функции, так что вызов х
()
выведет слова
hello wor/d.
Блоки позволяют программисту инкапсулироватъ сложные функции вместе с их ар
гументами и данными, так что на них можно легко ссылаться в программе и передавать
их, как переменную. Условно:
10
F+
4.8. Мдс OS Х GRдND CENTRдL D 1 sРдтсн
257
Блоки планируются и диспетчеризуются с использованием очередей. Приложение ис
пользует системные очереди, предоставляемые
GCD,
но может использовать и частные
очереди. Блоки помещаются в очереди по мере встречи с ними в процессе выполнения
программы . Затем
GCD
использует эти очереди для описания параллелизма , сериализа
ции и обратных вызовов. Очереди представляют собой облегченные пользовательские
структуры данных, что в общем случае делает их гораздо более эффективными, чем
управление потоками и блокировками вручную. Например, показанная ниже очередь со
держит три блока:
Очередь
В зависимости от очереди и от того, как она определена,
GCD
рассматривает эти бло
ки либо как потенциально параллельные действия , либо как последовательные. В любом
случае блоки диспетчеризуются по принципу "первым вошел
F потоку,
после него -
это параллельная очередь, то диспетчер назначает
ется доступным; затем назначается блок
ная очередь, диспетчер назначает
завершения
F.
F
G,
а
-
первым вышел". Если
как только таковой оказыва
Н. Если это последователь
потоку, но затем назначает
G
потоку только после
Использование предопределенных потоков экономит затраты на создание
нового потока для каждого запроса и сокращает задержки , связанные с обработкой бло
ка. Размеры пулов потоков автоматически изменяются системой таким образом, чтобы
максимизировать производительность приложений с использованием
GCD
при сведении
к минимуму количества бездействующих или конкурирующих потоков.
Помимо непосредственного планирования блоков, приложение может связать один
блок и очередь с источником событий, таким как таймер , сетевой сокет или файловый
дескриптор. Каждый раз, когда источник генерирует событие, выполняется планирование
блока, если он еще не запущен . Это обеспечивает быстрое реагирование без дорогостоя
щего постоянного опроса или связывания отдельного потока с источником события .
258
ГЛАВА 4. Потоки
Пример из
[233)
демонстрирует легкость использования
GCD.
Рассмотрим приложе
ние для работы с документом с кнопкой, после щелчка на которой будут выполнять
ся анализ текущего документа и отображение некоторых статистических данных о нем.
В общем случае этот анализ выполняется около секунды, поэтому для подключения
действия к кнопке используется следующий код:
- (Inaction)analyzeDocument: (NSButton *)sender
NSDictionary *stats = [myDoc analyze];
[myModel setDict:stats];
[myStatsView setNeedsDisplay:YES];
[stats release];
Первая строка тела функции анализирует документ, вторая обновляет внутреннее со
стояние приложения, а третья указывает приложению, что просмотр статистики необхо
димо обновить, чтобы отразить новое состояние информации. Этот код, который следует
распространенному шаблону, выполняется в основном потоке. Такой дизайн является
приемлемым при условии, что анализ выполняется не слишком долго, потому что пос
ле того, как пользователь нажимает кнопку, от главного потока приложения требуется
обработать ввод пользователя как можно быстрее, чтобы он мог вернуться к основному
циклу событий для обработки следующего действия пользователя. Но если пользователь
открывает очень большой или сложный документ, этап анализа может потребовать не
приемлемо длительного времени. Разработчик вряд ли будет рад необходимости изме
нения кода для этого редкого события, при том что такое изменение может затрагивать
глобальные объекты приложения, управление потоками, обратные вызовы, маршалинг
аргументов, контекстные объекты, новые переменные и т.д. Но при работе с
GCD
скром
ное дополнение к коду тут же дает желаемый результат:
помещает задачу в глобальную параллельную очередь. Это сообщает опера
ционной системе, что блок может быть переназначен отдельной параллельной очереди
из основной очереди и выполнен параллельно. Таким образом, нет никакой задержки в
главном потоке выполнения. После завершения анализа происходит внутренний вызов
dispatch async ().
Это указывает операционной системе на необходимость помес
тить следующий блок кода в конец основной очереди для выполнения по достижении
головы очереди. Так, с помощью очень небольшой работы со стороны программиста
достигается выполнение желаемого требования.
4.9. РЕЗЮМЕ
4.9.
259
Резюме
В некоторых операционных системах различаются понятия процесса и потока; пер
вый из них имеет отношение к владению ресурсами, а второй
-
к выполнению про
граммы. Такой подход может привести к повышению эффективности программы и удо
бен при составлении кода. В многопоточной системе в рамках одного процесса есть
возможность задавать несколько потоков. Для этого можно использовать либо потоки
на пользовательском уровне, либо потоки на уровне ядра. Потоки на пользовательском
уровне остаются невидимыми для операционной системы, они создаются и управляются
библиотекой потоков, которая выполняется в пользовательском пространстве процесса.
Потоки на пользовательском уровне очень эффективны, так как при их переключении
не нужно переключать режим работы процессора. Однако в одном процессе в каждый
момент времени
может
выполняться только
один
поток
на пользовательском уровне.
Если один такой поток будет заблокирован, это приведет к блокированию всего процес
са. Потоки на уровне ядра
-
это потоки, которые управляются ядром. Благодаря тому,
что такие потоки распознаются ядром, в многопроцессорной системе могут параллельно
выполняться несколько потоков одного и того же процесса, а блокирование потока не
приводит к блокированию всего процесса. Однако для переключения потоков на уровне
ядра нужно переключать режим работы процессора.
4.1 О.
Ключевые термины,
КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАЧИ
Ключевые термины
Задание
Пользовательский поток
Приложение
Многопоточность
Пользовательский режим планирования
Пространства имен
Нить
Порт
Процесс
Облегченный процесс
Поток
Пул потоков
Объект задания
Поток уровня ядра
Сообщение
Контрольные вопросы
4.1.
В табл.
3.5
перечислены типичные элементы, встречающиеся в управляющем бло
ке процесса операционной системы, в которой не используются потоки. Какие из
них следует отнести к управляющему блоку потока, а какие
-
к управляющему
блоку процесса в мноrопоточной системе?
4.2.
Перечислите причины, по которым переключение потоков обходится дешевле, чем
переключение процессов.
4.3.
Назовите две различные и потенциально независимые характеристики, содержа
4.4.
Приведите четыре общих примера использования потоков в однопользовательской
щиеся в понятии процесса.
многопроцессорной системе.
4.5.
Какие ресурсы обычно совместно используются всеми потоками процесса?
260
4.6.
ГЛАВА 4. Потоки
Перечислите три преимущества потоков на пользовательском уровне над потоками
на уровне ядра.
4.7.
Приведите два недостатка потоков на пользовательском уровне ло сравнению с
потоками на уровне ядра.
4.8.
Что такое
jacketing?
Задачи
4.1.
Отмечено, что использование нескольких потоков в одном и том же процессе пре
доставляет следующие преимущества:
1)
создание нового лотока в уже существу
ющем процессе требует меньших непроизводительных затрат, чем создание нового
процесса, и
2)
упрощается обмен информацией между потоками одного процесса.
Входит ли в число преимуществ использования потоков также то, что переключе
ние потоков одного процесса требует меньших затрат, чем переключение потоков
разных процессов?
4.2.
При сравнении потоков на пользовательском уровне и потоков на уровне ядра упо
миналось, что недостаток потоков на пользовательском уровне состоит в том, что
выполнение системного вызова блокирует не только вызвавший лоток, но и все
остальные потоки данного процесса. Почему так происходит?
4.3.
То, что в других операционных системах воплощено в концепции процесса, в ныне
незаслуженно забытой операционной системе
OS/2
разделено на три составляю
щие: сессия, процессы и лотоки. Сессия является набором одного или нескольких
процессов, имеющих связь с интерфейсом пользователя (клавиатурой, дисплеем,
мышью). Сессия представляет собой интерактивное пользовательское приложение,
в роли которого может выступать текстовый редактор или электронная таблица.
Эта концепция позволяет пользователю персонального компьютера запускать не
сколько приложений, открывая в каждом из них одно или несколько окон. Опера
ционная система должна следить за тем,
какое из окон, а следовательно, какая из
сессий является активной. В зависимости от этого ввод, поступающий с клавиату
ры и мыши, направляется в ту или иную сессию. В любой момент времени одна
сессия обрабатывается на переднем ллане, тогда как остальные сессии находятся в
фоновом режиме. Все, что вводится с помощью клавиатуры и мыши, направляется
в процесс, сессия которого в соответствии с состоянием приложений находится в
приоритетном режиме. Когда сессия находится на переднем ллане, процесс, вы
водящий видеосигнал, пересылает его непосредственно в видеобуфер и, соответс
твенно, на экран пользователя. При переходе сессии в фоновый режим содержимое
физического видеобуфера сохраняется в логическом видеобуфере. Если какой-ни
будь из потоков любого процесса, относящегося к сессии в фоновом режиме, про
изводит вывод на экран, этот вывод направляется в соответствующий логический
видеобуфер. Когда сессия возвращается на передний ллан, происходит обновление
экрана, отражающее текущее содержимое логического видеобуфера этой сессии.
Исключив сессии и связав интерфейс пользователя (клавиатуру, мышь, экран) с
процессами, можно свести количество концепций, имеющих отношение к процес
су, к двум. Таким образом, в каждый момент времени на переднем ллане будет
находиться один процесс.
4.10. КЛЮЧЕВЫЕ ТЕРМИНЫ, КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАЧИ
261
В целях структурирования процессы можно разделить на потоки.
а.
Какие преимущества теряются при таком подходе?
б.
Если такая модификация будет реализована, как следует осуществлять назна
чение ресурсов (памяти, файлов и т.д.)
-
на уровне процесса или на уровне
потока?
4.4.
Рассмотрим среду, в которой осуществляется взаимно однозначное отображение
между потоками на пользовательском уровне и потоками на уровне ядра. В такой
системе один или несколько потоков одного и того же процесса могут производить
блокирующие системные вызовы, в то время как другие будут продолжать выпол
няться. Объясните, почему на однопроцессорной машине в такой системе многопро
цессорные программы могут выполняться быстрее, чем их однопоточные двойники.
4.5.
Если процесс завершается, но какие-то его потоки все еще выполняются, то будут
ли они выполняться и далее?
4.6.
Структурирование операционной системы
OS/390,
предназначенной для мейнфрей
мов, основано на концепциях адресного пространства и задания. В других операци
онных системах адресное пространство, грубо говоря, соответствует приложению
и более или менее соответствует процессу. В рамках одного и того же адресного
пространства можно одновременно создавать и выполнять несколько заданий, что
приближенно соответствует концепции многопоточности. Для управления этими
заданиями создается ряд структур данных, две из которых являются основными.
Независимо от того, является ли данное адресное пространство выполняющим
ся, в соответствующем управляющем блоке адресного пространства
control
Ыосk
-
ASCB)
(address space
OS/390
содержится необходимая операционной системе
информация. В ее состав входят текущий приоритет, размер выделенной данно
му адресному пространству реальной и виртуальной памяти, количество готовых
к выполнению заданий в адресном пространстве, а также сведения о том, является
ли каждое из этих заданий выгруженным из памяти. В управляющем блоке задания
(task control
Ыосk
-
ТСВ) отражается выполнение пользовательской программы.
В нем содержится информация, необходимая для управления заданием в пределах
адресного пространства, включая информацию о статусе процессора, указатели на
входящие в состав задания программы и состояние выполнения задания. Блоки
ASCB
являются глобальными структурами, поддерживаемыми в системной памя
ти, а блоки ТСВ
-
локальными структурами, каждая из которых поддерживается в
своем адресном пространстве. В чем состоит преимущество разделения управляю
щей информации на глобальную и локальную части?
4.7.
Спецификации многих современных языков, таких как С и С++, являются недо
статочными для многопоточных программ. Это может влиять на компиляторы и
корректность кода, как показано ниже. Рассмотрим следующие объявления и опре
деление функции:
int global_positives
typedef struct list
=
{
struct list* next;
val;
}* list;
douЫe
О;
262
ГЛАВА 4. Потоки
void count_positives(list 1)
(
list р;
for (р
l; р; р = р -> next)
if (р -> val > О.О)
++global_positives;
Теперь рассмотрим ситуацию, когда в потоке А выполняется код
count_positives();
в то время как в потоке В
-
код
++global_positives;
а.
Что будет выполнять такая функция?
б.
Язык С предназначен для однопоточноrо выполнения. Не приведет ли ис
пользование двух параллельных потоков к проблемам (или к потенциальным
проблемам)?
4.8.
Некоторые оптимизирующие компиляторы (включая относительно консервативный
gcc)
будут "оптимизировать"
count_positives
в код наподобие
void count_positives(list 1)
(
list р;
register int r;
r = global_positives;
for (р = l; р; р = р -> next)
if (р -> val >О.О) ++r;
global_positives = r;
К каким проблемам (или к потенциальным проблемам) приведет эта версия кода
при параллельном выполнении потоков А и В?
4.9.
Рассмотрим следующий код, использующий
thread2.c:
#include
#include
#include
#include
int myglobal;
void* thread_function(void* arg)
int i, J;
for (i = О; i < 20; i++)
j
j
рая имеет тип pthread _ t. Это, по существу, идентификатор потока. Дi~лее, инс
трукция
if
создает поток, связанный с
mythread.
Вызов
возвращает нуль в случае успеха и ненулевое значение
им аргументом
pthread crea te ()
-
pthread create ()
в случае ошибки. Треть
является имя функции, которую новый поток
будет выполнять при запуске. При выходе из
thread_ funct ion ()
поток заверша
ется. Тем временем основная программа сама представляет собой поток, так что
имеется два потока выполнения. Функция
pthread_j oin ()
позволяет основному
потоку ждать до тех пор, пока не завершится новый поток.
а.
Что делает приведенная программа?
Вот вывод данной программы:
$ ./thread2
.. о . о . о . о . 00 . о . о . о . о . о . о . о . о . о .. о . о . о . о . о
myglobal equals 21
Это тот вывод, который вы ожидали? Если нет, что именно получилось не так?
4.10.
В описании состояний потоков на пользовательском уровне в операционной систе
ме
Solaris
говорилось о том, что поток пользовательского уровня может уступить
управление другому потоку с таким же приоритетом. Возможна ли ситуация, когда
в системе находится готовый к выполнению поток с более высоким приоритетом, и
следовательно, выполняющийся поток уступит управление потоку с таким же или
более высоким приоритетом?
264
4.11.
ГЛАВА 4. П от оки
В Solaris 9 и Solaris 10 имеется взаимно
LWP. В Solaris 8 один LWP поддерживает
а.
в.
ULT
и
В чем состоит возможная выгода разрешения взаимно однозначного отобра
жения между
б.
однозначное отображение между
один или несколько ULТ.
ULT
и
LWP?
В Solaris 8 состояние выполнения потока ULT отличается от такового у его
LWP. Поясните, почему.
На рис. 4.18 приведена диаграмма переходов состояний для U LT и связанно
го с ним LWP в Solaris 8 и 9. Поясните показанные на диаграммах операции
и их взаимоотношения.
4. 12. Объясните
причины наличия состояния " Непрерываемый" (UninterruptiЫe) в
5.1. Взаимоисключения: программный подход
Алгоритм Деккера
Первая попытка
Вторая попытка
Третья попытка
Четвертая попытка
Правильное решение
Алгоритм Петерсона
5.2. Принципы параллельных вычислений
Простой пример
Состояние гонки
Участие операционной системы
Взаимодействие процессов
Конкуренция процессов в борьбе за ресурсы
Сотрудничество процессов с применением совместного использования
Сотрудничество с использованием связи
Требования к.взаимным исключениям
5.3. Взаимоисключения: аппаратная поддержка
Отключение прерываний
Специальные машинные команды
Команда сравнения и присваивания
Команда обмена
Свойства подхода, основанного на использовании машинных инструкций
266
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
5.4. Семафоры
Задача производителя/потребителя
Реализация семафоров
5.5. Мониторы
Мониторы с сигналами
Мониторы с оповещением и широковещанием
5.6. Передача сообщений
Синхронизация
Адресация
Формат сообщения
Принцип работы очереди
Взаимные исключения
5. 7. Задача читатеnей/писателей
Приоритетное чтение
Приоритетная запись
5.8.
5.9.
Резюме
Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
267
УЧЕБНЫЕ ЦЕЛИ
Понимать базовые концепции параллельных вычислений, такие как состояния гон-
•
ки, взаимные исключения и др.
•
Разбираться в аппаратных подходах к поддержке взаимоисключений.
•
Понимать семафоры и работать с ними.
•
Понимать мониторы и работать с ними.
•
Уметь разъяснить задачу читателей/писателей.
Основные вопросы, на которых сосредоточивается внимание разработчиков опера
ционных систем, связаны с управлением
•
•
процессами и потоками.
Многозадачность: управление множеством процессов в однопроцессорной системе.
Многопроцессорность: управление множеством процессов в многопроцессорной
системе.
•
Распределенные вычисления: управление множеством процессов, выполняемых
в распределенной вычислительной системе с множеством компьютеров. Основным
примером таких
систем
являются широко распространенные
в
последнее
время
кластеры.
Фундаментальной концепцией этой области, да и разработки операционных систем в
целом, является концепция параллельных вычислений
(concurrency).
Параллельность
охватывает множество вопросов разработки, включая вопросы обмена информацией меж
ду процессами, разделения ресурсов (таких, как память, файлы, система ввода-вывода),
синхронизацию работы процессов и распределение процессорного времени между раз
личными процессами. Вы увидите, что эти вопросы возникают не только в многопроцес
сорной или распределенной вычислительной среде, но и в случае многозадачных систем
на базе одного процессора.
Параллельность проявляется в трех различных контекстах.
1.
Множественные приложения. Многозадачность разработана для того, чтобы
позволить динамически
разделять
процессорное
время
между рядом
активных
приложений.
2.
Структурность приложений. В качестве развития парадигмы модульной разра
ботки и структурного программирования некоторые приложения могут быть раз
работаны как множество параллельно работающих процессов.
3.
Струкrура операционной системы. Преимущества структурного программиро
вания доступны
не только прикладным,
но и системным
программистам,
и,
как
вы знаете, операционные системы также зачастую реализуются в виде набора
процессов или потоков.
В силу важности данного вопроса ему посвящены четыре главы данной книги. В на
стоящей и следующей главах рассматривается параллельность в контексте многопро
цессорности и многозадачности; в главах
рационные системы Интернета вещей", и
16, "Облачные операционные системы и опе
18, "Распределенная обработка, вычисления
268
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
«клиент/сервер» и кластеры'', изложены вопросы параллельных вычислений в контексте
распределенных вычислений.
Данная глава начинается с введения в концепции параллельных вычислений и парал
лельного выполнения нескольких процессов 1• Вы узнаете, что основным требованием
поддержки параллельных процессов является возможность обеспечения взаимоисключе
ний, т.е. возможность обеспечить работу только одного процесса с остановкой выполне
ния всех остальных. В следующем далее разделе будут рассмотрены различные подходы
к обеспечению взаимоисключений. Все они являются программными решениями и тре
буют использования технологии, известной как пережидание занятости
(busy waiting).
Затем мы остановимся на некоторых аппаратных механизмах, способных обеспечить
поддержку взаимоисключений, а также на решениях, которые не используют пережида
ние занятости и могут поддерживаться операционной системой или компиляторами. Мы
рассмотрим три подхода: семафоры, мониторы и передачу сообщений.
Для иллюстрации концепций и сравнения представленных в этой главе подходов ис
пользуются две классические задачи. Сначала мы познакомимся с задачей производите
лей/потребителей, а затем
-
с задачей читателей/писателей.
Наше изучение параллельных вычислений продолжится в главе
6,
"Параллельные
вычисления: взаимоблокировка и голодание'', и обсуждение механизмов параллельности
рассматриваемых нами операционных систем мы отложим до ее конца.
В приложении А, "Вопросы параллельности", охвачены дополнительные темы, свя
занные с параллельными вычислениями. В табл.
5.1
перечислены некоторые ключевые
термины, связанные с параллельными вычислениями. Набор анимаций, иллюстрирую
щих концепции этой главы, доступен на веб-сайте данной книги.
ТАБЛИЦА
5.1.
КЛЮЧЕВЫЕ ТЕРМИНЫ, СВЯЗАННЫЕ С ПАРАЛЛЕЛЬНЫМИ ВЫЧИСЛЕНИЯМИ
Атомарная операция
Функция или действие, реализованное как последователь
ность из одной или нескольких инструкций, представляю
щихся неделимыми; т.е. никакой другой процесс не может
увидеть промежуточное состояние или прервать выполняю
щуюся операцию. Гарантируется выполнение последователь
ности инструкций как единой группы (либо не выполнение ни
одной из них, без влияния на видимое состояние системы).
Атомарность гарантирует изоляцию от параллельно выполня
ющихся процессов
Критический участок
Участок кода в рамках процесса, который требует доступа к
общим ресурсам и который не должен выполняться в то вре
мя, когда в этом участке кода находится другой процесс
Взаимоблокировка (кпинч)
Ситуация, когда два и более процессов не в состоянии работать, поскольку каждый из процессов ожидает выполнения
некоторого действия другим процессом
Динамическая
Ситуация, когда два и более процессов постоянно изменяют
взаимоблокировка
свои состояния в ответ на изменения в других процессах без
выполнения полезной работы
1
Для простоты мы говорим о параллельном выполнении процессов; в действительности в ряде
систем фундаментальной единицей параллельности является не процесс, а поток.
5.1. ВЗАИМОИСКЛЮЧЕНИЯ: ПРОГРАММНЫЙ ПОДХОД
269
Окончание табл.
Взаимоисключение
5. 1
Требование, чтобы, когда один процесс находится в критичес
ком участке, который получает доступ к общим ресурсам, ни
какой другой процесс не мог находиться в критическом участ
ке, который обращается к любому из этих общих ресурсов
Состояние гонки
Ситуация, когда несколько потоков или процессов читают и
записывают элемент общих данных и конечный результат за
висит от относительного времени выполнения этих потоков
Ситуация, когда запуск процесса пропускается планировщи
Голодание
ком бесконечное количество раз; хотя процесс готов рабо
тать, он никогда не выбирается
5.1.
ВЗАИМОИСКЛЮЧЕНИЯ:
ПРОГРАММНЫЙ ПОДХОД
Программный подход может быть реализован для параллельных процессов, которые
выполняются как в однопроцессорной, так и в многопроцессорной системе с общей ос
новной памятью. Обычно такие подходы предполагают элементарные взаимоисключе
ния на уровне доступа к памяти
([140],
см. также задачу
5.3).
То есть одновременный
доступ (чтение и/или запись) к одной и той же ячейке основной памяти упорядочивает
ся при помощи некоторого механизма (хотя при этом порядок предоставления доступа
не определяется порядком обращения процессов за доступом к памяти). Никакой иной
поддержки со стороны аппаратного обеспечения, операционной системы или языка про
граммирования не предполагается.
Алгоритм Деккера
Дейкстра в
[66]
сообщил об алгоритме для взаимных исключений для двух процес
разработаем этот алгоритм поэтапно. Главное преимущество такого подхода
-
в де
монстрации множества узких мест и возможных ошибок при создании параллельно ра
ботающих программ.
Первая попытка
Как упоминалось ранее, любая попытка взаимного исключения должна опираться на
некий фундаментальный механизм исклю4ений аппаратного обеспечения. Наиболее об
щим механизмом может служить ограничение, согласно которому к некоторой ячейке
памяти в определенный момент времени может осуществляться только одно обращение.
Воспользовавшись этим ограни4ением, зарезервируем глобальную я4ейку памяти, кото
рую назовем
turn. Процесс (РО или
Pl),
который намерен выполнить крити4еский учас
ток, сна4ала проверяет содержимое я4ейки памяти
turn. Если значение turn равно но
меру процесса, то процесс может войти в критический участок; в противном слу4ае он
должен ждать, постоянно опрашивая значение
turn
до тех пор, пока оно не позволит
процессу войти в критический у4асток. Такая процедура известна как пережидание заня
тости
(busy waiting),
поскольку процесс вынужден, по сути, не делать ничего полезного до
270
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
тех пор, пока не получит разрешение на вход в критический участок. Более того, он посто
янно опрашивает значение переменной и тем самым потребляет процессорное время.
После того как процесс, получивший право на вход в критический участок кода, вы
ходит из него по завершении работы, он должен обновить значение
turn,
присвоив ему
номер другого процесса.
Говоря формально, имеется глобальная переменная
int turn
На рис.
=
О;
5.1, а
показана программа для двух процессов. Это решение гарантирует кор
ректную работу взаимоисключения, однако имеет два недостатка. Во-первых, при входе в
критический участок процессы должны строго чередоваться; тем самым скорость работы
диктуется более медленным из двух процессов. Если процессу РО вход в критический
участок требуется раз в час, а процессору Р 1 -
1ООО
раз в час, то темп работы Р 1 будет
таким же, как и у процесса РО. Во-вторых, гораздо более серьезная ситуация возникает в
случае сбоя одного из процессов
при этом второй процесс оказывается заблокирован
-
ным (при этом не важно, происходит сбой процесса в критическом участке или нет).
Описанная конструкция представляет собой сопрограмму
(coroutine).
Сопрограммы
разрабатываются таким образом, чтобы быть способными передавать управление друг
другу (см. задачу
5.5).
Однако хотя эта технология структурирования и весьма полезна для
отдельно взятого процесса, для поддержки параллельных вычислений она не подходит.
Вторая попытка
Проблема при первой попытке заключается в том, что в ней хранилось имя процесса,
который имел право входа в критический участок, в то время как в действительности
нам требуется информация об обоих процессах. По сути, каждый процесс должен иметь
собственный ключ к критическому участку, так что если даже произойдет сбой одного
процесса, второй все равно сможет получить доступ к критическому участку. Дпя удов
летворения этого условия определен логический вектор
ветствует процессу РО, а
flag [ 1 J -
процессу
Pl.
flag,
в котором
flag
[О] соот
Каждый процесс может ознакомиться
с флагом другого процесса, но не может его изменить. Когда процессу требуется войти в
критический участок, он периодически проверяет состояние флага другого процесса до
тех пор, пока тот не примет значение
false,
указывающее, что другой процесс покинул
критический участок. Процесс немедленно устанавливает значение собственного флага
равным
true
и входит в критический участок. После выхода из критического участка
процесс сбрасывает свой флаг, присваивая ему значение f а 1 s е.
Теперь общие переменные 2 выглядят следующим образом:
enum
boolean
boolean flag[2] =
{
{ false = О, true
false, false };
Этот алгоритм показан на рис.
5.1, 6.
=
1; } ;
Теперь, если произойдет сбой одного из процес
сов вне критического участка (включая код установки значения флага), второй процесс
заблокирован не будет. Этот второй процесс в таком случае сможет входить в критичес
кий участок всякий раз, как только это потребуется, поскольку флаг другого процесса
всегда будет иметь значение
false.
Однако если сбой произойдет в критическом учас
тке (или перед входом в него, но после установки значения флага равным
true),
то
другой процесс окажется заблокированным навсегда.
2 Здесь
объявление перечисления enum использовано для объявления типа данных (boolean) и
его значений.
5.1. ВЗАИМОИСКЛЮЧЕНИЯ: ПРОГРАММНЫЙ ПОДХОД
/*
Процесс О
*/
/*
while (turn != 0)
/*
Ничего не делаем
/* Критический
turn = 1;
*/;
участок*/;
Процесс
1 */
while (turn != 1)
/* Ничего не делаем*/;
/* Критический участок */;
while (flag[l])
/* Ничего не делаем*/;
/* Критический участок*/;
while (flag [О])
/* Ничего не делаем*/;
/* Критический участок */;
flag[O]
flag[l]
=
false;
=
false;
в) Третья попытка
/*
flag[OJ
=
Процесс О
*/
/*
Процесс
flag[l] = true;
true;
while (flag[l])
while ( flag
(
{
/*Критический участок
=
[О])
flag[l] = false;
/* Задержка */
flag[l] = true;
flag[O] = false;
/* Задержка */
flag[OJ = true;
flag[O]
1 */
*/;
false;
/*
Критический участок
flag[l]
=
false;
г) Четвертая попытка
Рис.
5.1.
Попытки взаимных исключений
*/;
271
272
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
Описанное решение, по сути, оказывается еще хуже предложенного ранее, посколь
ку даже не гарантирует взаимного исключения. Рассмотрим такую последовательность
действий:
РО выполняет инструкцию
Pl
выполняет инструкцию
while
и находит, что значение
flag [1]
равно
false;
while
и находит, что значение
flag [0]
равно
false;
РО устанавливает значение
f lag [О]
равным
t rue
и входит в критический участок;
устанавливает значение
flag [ 1]
равным
true
и входит в критический участок.
Pl
Поскольку после этого оба процесса одновременно оказываются в критическом учас
тке, программа некорректна. Проблема заключается в том, что предложенное решение не
является независимым от относительной скорости выполнения процессов.
Третья попытка
Поскольку процесс может изменить свое состояние после того, как другой процесс
ознакомится с ним, но до того, как этот другой процесс войдет в критический участок,
вторая попытка также оказалась неудачной. Возможно, нам удастся выправить ситуацию
путем внесения в код небольшого изменения, показанного на рис. 5.1,в.
Как и ранее, если происходит сбой одного процесса в критическом участке, включая
код установки значения флага, то второй процесс окажется заблокированным (и соот
ветственно, если сбой произойдет вне критического участка, то второй процесс блоки
рован не будет).
Далее проверим гарантированность взаимоисключения, проследив за происходя
щим с точки зрения процесса РО. После того как процесс РО установит
true, Pl
flag
[О] равным
не сможет войти в критический участок до тех пор, пока туда не войдет и
затем не покинет его процесс РО. Может оказаться так, что процесс
Pl
уже находится
в критическом участке в тот момент, когдаРО устанавливает свой флаг. В этом случае
процесс РО будет заблокирован инструкцией
while
до тех пор, пока
Pl
не покинет кри
тический участок. Аналогичные действия происходят при рассмотрении происходящего
с точки зрения процесса
Pl.
Тем самым взаимное исключение гарантируется; однако третья попытка порожда
ет еще одну проблему. Если оба процесса установят значения флагов равными
до того, как один из них выполнит инструкцию
while,
true
то каждый из процессов будет
считать, что другой находится в критическом участке, и тем самым осуществится взаи
моблокировка.
Четвертая попытка
В третьей попытке установка процессом флага состояния выполнялась без учета ин
формации о состоянии другого процесса. Взаимоблокировка возникала по той причине,
что каждый процесс мог добиваться своих прав на вход в критический участок и не бьmо
никакой возможности отступить назад из имеющегося положения. Можно попытаться ис
править ситуацию, делая процессы более "уступчивыми": каждый процесс, устанавливая
свой флаг равным
true,
указывает о своем желании войти в критический участок, но
готов отложить свой вход, уступая другому процессу, как показано на рис. 5.1,г.
Это уже совсем близко к корректному решению, хотя все еще и неверно. Взаимоис
ключение гарантируется (в чем можно убедиться, применяя те же рассуждения, что и
при третьей попытке), однако рассмотрим следующую возможную последовательность
событий:
5.1. ВЗАИМОИСКЛЮЧЕНИЯ: ПРОГРАММНЫЙ ПОДХОД
РО устанавливает значение
PI
устанавливает значение
РО проверяет
PI
проверяет
равным
flag[O]
flag [ 1]
flag [О]
flag [ 1]
равным
равным
true;
true;
flag [ 1];
flag [О] ;
РО устанавливает значение
Р\ устанавливает значение
РО устанавливает значение
PI
flag [О]
flag [ 1]
273
устанавливает значение
Э1)' последовательность можно продолжать до
false;
равным false;
равным true;
равным true.
бесконечности - и
ни один из процессов
до бесконечности так и не сможет войти в критический участок. Строго говоря, это не вза
имоблокировка, так как любое изменение относительной скорости двух процессов разорвет
замкнутый круг и позволит одному из процессов войти в критический участок. Назовем
такую ситуацию динамической взаимоблокировкой
(\ivelock).
Вспомним, что обычная
взаимоблокировка осуществляется, когда несколько процессов желают войти в критический
раздел, но ни одному из них это не удается. В случае неустойчивой взаимоблокировки су
ществует приводящая к успеху последовательность действий, но вместе с тем возможна и
такая (такие), при которой ни один из процессов не сможет войти в критический участок.
Хотя описанный сценарий маловероятен и вряд ли такая последовательность про
длится сколь-нибудь долго, теоретически такая возможность имеется. Поэтому мы вы
нуждены отвергнуть как неудачную и четвертую попытку.
Правильное решение
У нас должна быть возможность следить за состоянием обоих процессов, что обес
печивается массивом
flag.
Но, как показала четвертая попытка, этого недостаточно. Мы
должны навязать определенный порядок действий двум процессам, чтобы избежать про
блемы "взаимной вежливости", с которой только что столкнулись. С этой целью можно
использовать переменную
t urn
из первой попытки. В нашем случае эта переменная
указывает, какой из процессов имеет право на вход в критический участок.
Мы можем описать это решение (известное как алгоритм Деккера) следующим обра
зом. Когда процесс РО намерен войти в критический участок, он устанавливает свой флаг
равным
true,
а затем проверяет состояние флага процесса
PI.
Если он равен
false,
РО
может немедленно входить в критический участок; в противном случае РО обращается
к переменной
turn.
Если
turn=O,
это означает, что сейчас
-
очередь процесса РО на
вход в критический участок, и РО периодически проверяет состояние флага процесса
PI.
Этот процесс, в свою очередь, в некоторый момент времени обнаруживает, что сейчас не
его очередь для входа в критический участок, и устанавливает свой флаг равным f а l
s е,
давая возможность войти в критический участок процессу РО. После того как РО выйдет
из критического участка, он установит свой флаг равным f а l
тического участка и присвоит переменной
turn
значение
sе
1 для
для освобождения кри
передачи прав на вход в
критический участок процессу Р 1.
Алгоритм Деккера приведен на рис.
5.2.
Конструкция
parbegin(P 1,P 2,""P)
означает
следующее: приостановка выполнения основной программы; инициализация параллель
ного выполнения процедур Р 1 ,Р 2 ,""Рп; по окончании работы процедур Р 1 ,Р 2 ,""Рп
-
во
зобновление выполнения основной программы. Доказательство корректности алгоритма
Деккера оставляется читателю в качестве упражнения (см. задачу
5.1 ).
274
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
boolean flag[2];
int turn;
void РО ()
{
while(true)
{
flag[OJ = true;
while (flag[l))
if (turn == 1)
flag[OJ = false;
while(turn == 1)
flag[OJ = true;
false;
flag [0]
false;
flag [1]
turn = 1;
parbegin(PO,Pl);
Рис.
5.2. Алгоритм Деккера
*/;
5.1. ВЗАИМОИСКЛЮЧЕНИЯ: ПРОГРАММНЫЙ ПОДХОД
275
Алгоритм Петерсона
Алгоритм Деккера решает задачу взаимных исключений, но достаточно сложным пу
тем, корректность которого не так легко доказать. Петерсон
стое и элегантное решение
[190].
(Peterson) предложил про
flag указывает по
Как и ранее, глобальная переменная
ложение каждого процесса по отношению к взаимоисключению, а глобальная перемен
ная
turn
разрешает конфликты одновременности. Алгоритм представлен на рис.
5.3.
boolean flag [2];
int turn;
void РО ()
{
while (true)
flag [0] = true;
turn = 1;
while (flag [1] && turn == 1) /*
/* Критический раздел */;
flag [0] = false;
/* Остальной код*/;
Ничего не делать
*/;
Ничего не делать
*/;
void Pl ()
{
while (true)
flag [1] = true;
turn = О;
while (flag [О] && turn == 0) /*
/* Критический раздел */;
flag [1] = false;
/* Остальной код */
void main ()
{
flag [О] = false;
flag [1] = false;
parbegin(PO, Pl);
Рис.
5.3.
Алгоритм Петерсона для двух процессов
Выполнение условий взаимоисключения легко показать. Рассмотрим процесс РО.
После того как
flag [О] установлен им равным true, PI войти в критический участок
PI уже находится в критическом участке, то flag [ 1] = true и для
не может. Если же
РО вход в критический участок заблокирован. Однако взаимная блокировка в данном
алгоритме предотвращена. Предположим, что РО заблокирован в своем цикле
Это означает, что
flag[l]
равен
true,
а
turn=l.
while.
РО может войти в критический
276
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
участок, когда либо
flag [ 1]
становится равным
false,
либо
turn
становится рав
ным О. Рассмотрим три исчерпывающих случая.
1.
Р 1 не намерен входить в критический участок. Такой случай невозможен, по
скольку при этом выполнялось бы условие
ожидает входа в критический участок. Такой случай также невозможен, по
2. Pl
скольку если
3. Pl
flag [ 1] = false.
turn = 1,
то
Pl
способен войти в критический участок.
циклически использует критический участок, монополизировав доступ к нему.
Этого не может произойти, поскольку
Pl
вынужден перед каждой попыткой входа
в критический участок дать возможность входа процессу РО, устанавливая значе
ние
turn
равным О.
Таким образом, у нас имеется простое решение проблемы взаимных исключений для
двух процессов. Впрочем, алгоритм Петерсона легко обобщается на случай п процессов.
5.2.
ПРИНЦИПЫ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ
В однопроцессорной многозадачной системе процессы чередуются для создания ил
люзии одновременного выполнения (см. рис.
2.12, а).
Несмотря на то что при этом не
достигается реальная параллельная работа процессов и, более того, имеются определен
ные накладные расходы, связанные с переключением между процессами, такое чере
дующееся выполнение обеспечивает немалые выгоды с точки зрения эффективности и
структуризации программ. В многопроцессорных системах возможно не только чередо
вание процессов, но и их перекрытие (см. рис.
2.12, 6).
На первый взгляд может показаться, что чередование и перекрытие представляют
собой принципиально различающиеся режимы работы и, соответственно, при этом воз
никают различные проблемы. Однако в действительности обе технологии, которые мож
но рассматривать как примеры параллельных вычислений, порождают одинаковые про
блемы. В однопроцессорных системах проблемы вытекают из основных характеристик
многозадачных систем:
невозможно предсказать относительную скорость выполнения
процессов. Она зависит от других процессов, способа обработки прерываний операци
онной системой и стратегий планирования операционной системы. При этом возникают
следующие трудности.
1.
Совместное использование глобальных ресурсов чревато опасностями. Например,
если два процесса используют одну глобальную переменную и оба выполняют
чтение и запись этой переменной, то критическим оказывается порядок чтения и
записи этой переменной разными процессами. Пример такой проблемы приведен
в следующем подразделе.
2.
Операционной системе трудно управлять распределением ресурсов оптимальным
образом. Например, процесс А может затребовать и получить контроль над неко
торым каналом ввода-вывода, после чего временно приостановить работу. Неже
лательно, чтобы операционная система при этом блокировала канал и не давала
другим процессам возможности использовать его,
-
такая политика может при
вести к возникновению условий взаимоблокировки, описываемых в главе
раллельные вычисления: взаимоблокировка и голодание".
6,
"Па
5.2. ПРИНЦИПЫ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ
3.
277
Становится очень трудно обнаружить программную ошибку, поскольку обычно
результат работы программы перестает быть детерминированным и воспроизво
димым (см" например,
[146, 39, 225]).
Все описанные трудности имеются в наличии и в многопроцессорной системе, пос
кольку и в этом случае относительная скорость выполнения процессов непредсказуема.
Многопроцессорная система, кроме того, должна быть в состоянии разрешить пробле
мы, возникающие вследствие одновременного выполнения нескольких процессов. Одна
ко в основе своей эти проблемы те же, что и в однопроцессорной системе. Окончательно
ясно это станет в процессе работы с материалом данной главы.
Простой пример
Рассмотрим следующую процедуру:
void echo ()
{
chin = getchar();
chout = chiп;
putchar(chout);
Она демонстрирует основные элементы отображения вводимых символов. Входной
символ, получаемый с клавиатуры, сохраняется в переменной
чение переменной
chin
присваивается переменной
chout
chin;
после этого зна
и выводится на экран. Дан
ная процедура может неоднократно вызываться любым процессом для получения ввода
пользователя и отображения его на экране.
Теперь представим, что у нас имеется однопроцессорная многозадачная система,
поддерживающая единственного пользователя. Пользователь может переходить от од
ного приложения к другому; при этом все приложения используют одну
и ту же кла
виатуру и экран. Поскольку рассматриваемая нами процедура нужна всем приложени
ям, имеет смысл сделать ее совместно используемой процедурой, загружаемой в часть
памяти, глобальную для всех приложений (таким образом, имеется только одна копия
процедуры, и тем самым экономится память).
Совместное использование основной памяти процессами способствует эффективному
и тесному взаимодействию процессов. Однако такое совместное использование может
привести к проблемам. Рассмотрим приведенную ниже последовательность событий.
1.
PI вызывает процедуру echo и прерывается немедленно по выполнении
getchar. В этот момент последний введенный символ х сохранен в
переменной chin.
Процесс
функции
2.
Активируется процесс Р2, который вызывает процедуру
полняется до конца;
при этом считывается
echo.
с клавиатуры
и
Эта процедура вы
выводится
на экран
очередной символ у.
3.
Продолжается выполнение процесса Р 1. Однако к этому моменту значение х в
переменной
chin
перезаписано
-
которое присваивается переменной
теперь эта переменная содержит значение у,
chout
и выводится на экран.
Таким образом, первый введенный символ благополучно теряется, зато второй оказы
вается выведенным на экран дважды. Проблема заключается в совместно используемой
278
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
глобальной переменной
chin,
к которой обращаются несколько процессов; если один
процесс изменяет глобальную переменную и затем прерывается, другой может успеть
изменить ее значение, перед тем как первый процесс им воспользуется. Предположим
теперь, что выполнять процедуру одновременно процессы не могут. В таком случае опи
санная ранее последовательность действий выглядит иначе.
1.
Процесс
Pl вызывает процедуру echo и прерывается немедленно по выполнении
getchar. В этот момент последний введенный символ х сохраняется в
переменной chin.
функции
2.
Активируется процесс Р2, который вызывает процедуру
приостановленный процесс
PI
находится в процедуре
echo.
echo,
Однако, поскольку
Р2 блокируется от
входа в данную процедуру. Следовательно, выполнение Р2 приостанавливается до
тех пор, пока процедура
3.
echo
не окажется свободной.
В некоторый более поздний момент продолжается выполнение процесса
завершает выполнение процедуры
4.
После того как
Pl
покидает
echo,
echo,
Pl,
-
который
выводя на экран верный символ
х.
блокировка Р2 удаляется и позже, при возоб
новлении работы процесса Р2, им успешно выполняется процедура
echo.
Урок, который следует извлечь из данного примера, заключается в том, что совмес
тно используемые глобальные переменные (как и другие совместно используемые гло
бальные ресурсы) нуждаются в защите, и единственный способ обеспечить ее состоит
в управлении кодом, осуществляющим доступ к этим переменным. Если мы добьемся
того, что в определенный момент времени только один процесс сможет входить в про
цедуру
echo
и она обязательно будет полностью выполнена вошедшим в нее процессом
до того, как станет возможным ее выполнение другим процессом, то мы будем застра
хованы от возникновения рассматриваемой ошибки. Каким образом этого добиться
-
основной вопрос данной главы.
Мы предполагали, что имеем дело с однопроцессорной многозадачной операцион
ной системой. Пример продемонстрировал, что проблема может возникнуть даже в этом
случае. В многопроцессорной системе возникает та же проблема защиты совместно ис
пользуемых ресурсов, которая имеет аналогичное решение. Сначала предположим, что
механизм управления доступом к разделяемой глобальной переменной отсутствует.
1.
Одновременно выполняются процессы Р 1 и Р2
Оба процесса вызывают процедуру
2.
-
каждый на своем процессоре.
echo.
Происходят следующие события (события в одной строке происходят параллельно).
Процесс
chin
=
Pl
getchar();
chout = chin;
putchar(chout);
В результате символ, введенный в процессе
Процесс Р2
chin = getchar();
chout = chin;
putchar(chout);
Pl,
теряется до того, как будет выведен
на экран, и обоими процессами выводится символ, считанный процессом Р2. Теперь
добавим в систему механизм, гарантирующий, что в процедуре
echo
в любой момент
времени может находиться только один процесс. В этом случае последовательность со
бытий становится такой.
5.2. ПРИНЦИПЫ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ
1.
Одновременно выполняются процессы
Процесс
2.
Pl
вызывает процедуру
В то время как процесс
Pl
Pl
и Р2
-
279
каждый на своем процессоре.
echo.
echo, эту же процедуру вы
Pl находится в процедуре echo
процесс Pl или приостановлен), Р2 бло
находится в процедуре
зывает процесс Р2. Однако, поскольку процесс
(не важно, выполняется ли в этот момент
кируется от входа в данную процедуру. Следовательно, выполнение Р2 приоста
навливается до тех пор, пока процедура
3.
echo
не окажется свободной.
В некоторый более поздний момент времени выполнение процессом
ры
echo
Pl
процеду
завершается, после чего немедленно продолжается выполнение процес
са Р2 и им успешно выполняется процедура
echo.
В однопроцессорной системе причина возникновения проблемы заключается в том,
что прерывание может остановить выполнение процесса в произвольном месте. В мно
гопроцессорной системе условия работы те же, но проблема может возникнуть и из-за
того,
что два выполняющихся
одновременно процесса могут в один момент времени
обратиться к одной и той же глобальной переменной. Однако решение проблем обоих
типов одинаково: управление доступом к совместно используемым ресурсам.
Состояние гонки
Состояние гонки возникает, когда несколько процессов или потоков читают и запи
сывают элементы данных так, что конечный результат зависит от порядка выполнения
инструкций в нескольких процессах. Давайте рассмотрим два простых примера.
В качестве первого примера предположим, что два процесса,
Pl
и Р2, совместно ис
пользуют глобальную переменную а. В какой-то момент своего времени выполнения
Р\ обновляет значение а, делая его равным
\,
а процесс Р2 в некоторый момент свое
го выполнения обновляет значение а, делая его равным
2.
Таким образом, две задачи
находятся в "гонке", призом которой является запись переменной. В данном примере
"проигравший" гонку процесс (который обновляет переменную последним) определяет
конечное значение переменной а.
В качестве второго примера рассмотрим два процесса, РЗ и Р4, которые совмест
но используют глобальные переменные Ь и с, с начальными значениями Ь
В какой-то момент времени выполнения РЗ выполняет присваивание Ь = Ь
= 1 и с= 2.
+ с, а процесс
Р4 в некоторый момент своего выполнения выполняет присваивание с= Ь +с. Обратите
внимание, что эти два процесса обновляют разные переменные. Однако их конечные
значения зависят от порядка,
в котором данные
процессы
выполняют
присваивания.
Если первым выполнит присваивание процесс РЗ, конечными значениями переменных
будут Ь
=3
и с=
5.
Если же первым выполнит присваивание процесс Р4, то конечными
значениями переменных будут Ь =
4
и с=
3.
В приложении А, "Вопросы параллельности", в качестве примера рассматриваются
вопросы состояния гонки с использованием семафоров.
Участие операционной системы
Можно перечислить следующие вопросы конструирования и управления операцион
ных систем, возникающие из-за наличия параллельных вычислений.
280
1.
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
Операционная система должна быть способна отслеживать различные процессы.
Это осуществляется при помощи управляющих блоков процессов, как описано в
главе
2.
4,
"Потоки".
Операционная система должна распределять и освобождать различные ресурсы
для каждого активного процесса, в том числе следующие.
•
Процессорное время. Это функция планирования, рассматриваемая в час
ти
IV,
"Планирование".
•
Память. Большинство операционных систем используют схему виртуальной
•
Файлы. Обсуждаются в главе
•
Устройства ввода-вывода. Обсуждаются в главе
памяти. Этот вопрос рассматривается в части
12,
111,
"Память".
"Управление файлами".
11,
"Управление вводом-вы
водом и планирование дисковых операций".
3.
Операционная система должна защищать данные и физические ресурсы каждого
процесса от непреднамеренного воздействия других процессов, что включает ис
пользование технологий, применяющихся для работы с памятью, файлами и уст
ройствами ввода-вывода.
4.
Функционирование процесса и результат его работы не должны зависеть от ско
рости
его выполнения
по отношению
к другим
параллельно
выполняющимся
процессам. Этому вопросу посвящена данная глава.
Чтобы лучше понять вопросы независимости работы процессов от относительной
скорости выполнения, рассмотрим сначала способы взаимодействия процессов.
Взаимодействие процессов
Способы взаимодействия процессов можно классифицировать по степени осведом
ленности одного процесса о существовании другого. В табл.
5.2
перечислены три воз
можные степени осведомленности.
•
Процессы не осведомлены о наличии друг друга. Это независимые процессы,
не предназначенные для совместной работы. Наилучшим примером такой ситу
ации может служить многозадачность множества независимых процессов. Это
могут быть пакетные задания, интерактивные сессии или комбинация тех и дру
гих. Хотя эти процессы и не работают совместно, операционная система должна
решать вопросы конкурентного использования ресурсов. Например, два незави
симых приложения могут затребовать доступ к одному и тому же диску или к при
нтеру. Операционная система должна регулировать такие обращения.
•
Процессы косвенно осведомлены о наличии друг друга. Эти процессы не обя
зательно должны быть осведомлены о наличии друг друга с точностью до иденти
фикатора процесса, однако они совместно обращаются к некоторому объекту, на
пример к буферу ввода-вывода. Такие процессы демонстрируют сотрудничество
при совместном использовании общего объекта.
•
Процессы непосредственно осведомлены о наличии друг друга. Такие процес
сы способны общаться один с другим с использованием идентификаторов про
цессов и изначально созданы для совместной работы. Также они демонстрируют
сотрудничество при работе.
5.2. ПРИНЦИПЫ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ
281
Условия работы процессов не всегда можно определить так ясно и четко, как указано
в табл.
5.2;
более того, некоторые процессы одновременно проявляют способность и к
конкуренции, и к сотрудничеству. Тем не менее имеет смысл рассмотреть приведенный
список и определить участие операционной системы в перечисленных в нем ситуациях.
ТАБЛИЦА
5.2.
ВЗАИМОДЕЙСТВИЕ ПРОЦЕССОВ
Степень
осведомленности
Взаимосвязь
Влияние одного
Потенциальные
процесса на другой
проблемы
Результат работы одного
•
ведомлены один о
процесса не зависит от
действий других
•
другом
Процессы не ос
Конкуренция
•
•
работы другого
Взаимоблокировки
(возобновляемые
Возможно влияние од
ного процесса на время
Взаимоисключения
ресурсы)
•
Голодание
Процессы косвенно
Сотрудничество с
Результат работы одного
•
Взаимоисключения
осведомлены один
использованием
процесса может зависеть
общих ресурсов
от информации, получен-
•
Взаимоблокировки
о другом
•
(возобновляемые
ной от других процессов
•
Возможно влияние одного процесса на время
работы другого
•
Голодание
•
Связь данных
Взаимоблокировки
Процессы непос
Сотрудничество с
редственно осве
использованием
процесса может зависеть
(расходуемые
домлены один о
связи
от информации, получен-
ресурсы)
•
Результат работы одного
ресурсы)
ной от других
другом
•
•
•
Голодание
Возможно влияние одного процесса на время
работы другого
Конкуренция процессов в борьбе за ресурсы
При необходимости использовать один и тот же ресурс параллельные процессы всту
пают в конфликт друг с другом. В чистом виде ситуацию можно описать следующим об
разом. В процессе работы два или более процессов нуждаются в доступе к некоторому
ресурсу. Каждый из процессов не подозревает о наличии остальных и не подвергается
никакому воздействию с их стороны. Отсюда следует, что каждый процесс не должен
изменять состояние любого ресурса, с которым он работает. Примерами таких ресурсов
могут быть устройства ввода-вывода, память, процессорное время и часы.
Между конкурирующими процессами не происходит никакого обмена информаци
ей. Однако выполнение одного процесса может повлиять на поведение конкурирующего
процесса. В частности, если два процесса желают получить доступ к одному ресурсу, то
операционная система выделит этот ресурс одному из процессов, в то время как второй
процесс вынужден будет ожидать завершения работы с ресурсом первого. Таким обра
зом, скорость работы процесса, которому отказано в немедленном доступе к ресурсу,
уменьшается. В предельном случае блокированный процесс может никогда не получить
доступ к ресурсу и, следовательно, никогда не сможет успешно завершиться.
282
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
В случае конкуренции процессов мы сталкиваемся с тремя проблемами. Первая их
них
-
необходимость взаимных исключений
(mutual exclusion).
Предположим, что два
или больше процессов требуют доступа к одному неразделимому ресурсу, такому как
принтер. При выполнении каждый процесс посылает команды в устройство ввода-выво
да, получает информацию о его состоянии, посылает и/или получает данные. Мы будем
говорить о таком ресурсе как о крuтическаw ресурсе, а о части программы, которая его
использует,
-
как о критическом участке
(critical section)
программы. Крайне важно,
чтобы в критическом участке в любой момент времени могла находиться только одна
программа. Мы не можем полагаться на то, что операционная система распознает ситу
ацию и выполнит это условие, поскольку полные требования к ресурсу могут оказаться
не очевидными. Например, во время печати файла требуется, чтобы отдельный процесс
имел полный контроль над принтером, иначе на бумаге можно получить чередование
строк двух файлов.
Осуществление взаимных исключений создает две дополнительные проблемы. Одна
из них
-
взаимная блокировка
и Р2) и два ресурса
и
(RI
R2).
(dead\ock).
Рассмотрим, например, два процесса
(PI
Предположим, что каждому процессу для выполнения
части своих функций требуется доступ к обоим ресурсам. Тогда возможно возникно
вение следующей ситуации: операционная система выделяет ресурс
ресурс
R2 -
процессу
PI.
R 1 процессу
Р2, а
В результате каждый процесс ожидает получения одного из
двух ресурсов; при этом ни один из них не освобождает уже имеющийся у него ресурс,
ожидая получения второго ресурса для выполнения функций, требующих наличия двух
ресурсов. В результате процессы оказываются взаимно заблокированными.
Последняя проблема
-
голодание
(starvation).
Предположим, что у нас имеются три
процесса (Р\, Р2, РЗ), каждому из которых периодически требуется доступ к ресурсу
R.
Представим ситуацию, в которой
PI
обладает ресурсом, а Р2 и РЗ приостановлены
в ожидании освобождения ресурса. После выхода Р\ из критического раздела доступ к
ресурсу будет получен одним из процессов Р2 и РЗ. Пусть операционная система предо
ставила доступ к ресурсу
R
процессу РЗ. Пока он работает с ресурсом, доступ к ресур
су вновь требуется процессу
PI.
В результате после освобождения ресурса процессом
РЗ может оказаться, что операционная система вновь предоставила доступ к ресурсу
процессу Р 1; тем временем процессу РЗ вновь требуется доступ к ресурсу
R.
Таким
образом, теоретически возможна ситуация, в которой процесс Р2 никогда не получит
доступа к требуемому ему ресурсу, несмотря на то что никакой взаимной блокировки в
этом случае нет.
Управление конкуренцией неизбежно приводит к участию операционной системы в
этом процессе, поскольку именно она распределяет ресурсы. Кроме того, процессам не
обходима возможность запрашивать взаимоисключение, такое как блокировка ресурса
перед его использованием. Любое решение этого вопроса требует поддержки операци
онной системы, например такой, как обеспечение возможности блокировки. На рис.
5.4
показан абстрактный механизм взаимоисключений. Здесь параллельно выполняются
п процессов. Каждый процесс включает
торым ресурсом
Ra,
и
2)
1)
критический участок, работающий с неко
остальную часть процедуры, в которой нет обращения к ре
сурсу. Дпя обеспечения взаимоисключения имеются две функции:
exi tcri tical.
entercritical
и
Каждая из них принимает в качестве аргумента имя ресурса, являюще
гося предметом конкуренции. Любой процесс, который пытается войти в критический
участок в то время, как в нем находится другой процесс, будет приостановлен.
5.2. ПРИНЦИПЫ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ
283
Нам остается только рассмотреть механизм, обеспечивающий работу функций
entercritical
и
exitcritical.
Однако пока что мы отложим этот вопрос и при
ступим к рассмотрению других случаев взаимодействия процессов.
while (true) {
/* Предшествующий
код */;
entercritical(Ra);
/* Критический
участок */;
exitcritical(Ra);
/* Последующий
код */;
while (true) {
/* Предшествующий
КОД */;
entercritical(Ra);
/* Критический
участок*/;
участок*/;
exitcritical(Ra);
/* Последующий
код */;
exitcritical(Ra);
/* Последующий
код*/;
-::-;---·l
...
-----·-·---·-------------"'-----------~-
Рис.
5.4.
Иллюстрация взаимоисключений
Сотрудничество процессов с применением совместного использования
Случай сотрудничества процессов с применением совместного использования охва
тывает процессы, взаимодействующие с другими процессами без наличия явной инфор
мации о них. Например, несколько процессов могут обращаться к совместно используе
мым переменным или к совместно используемым файлам или базам данных. Процессы
могут использовать и обновлять общие данные без обращения к другим процессам, но
с учетом того, что последние также могут обращаться к тем же данным. Таким образом,
процессы должны сотрудничать, для того чтобы гарантировать корректную работу с сов
местно используемыми данными. Механизм управления доступом должен гарантировать
целостность общих данных.
Поскольку данные хранятся в ресурсах (устройствах, памяти), в этом случае также на
личествуют проблемы взаимоблокировок, взаимоисключения и голодания. Единственное
отличие заключается в том, что доступ к данным может осуществляться в двух режи
мах
-
чтения и записи, и взаимоисключающими должны быть только операции записи.
Однако в данном случае вносится новое требование
-
согласованности данных.
В качестве простейшего примера рассмотрим бухгалтерское приложение, в котором
могут обновляться различные данные. Предположим, что два элемента данных, а и Ь,
должны быть связаны соотношением а
=
Ь, так что любая программа, изменяющая одно
зна•1ение, обязана изменить и другое, с тем чтобы это соотношение продолжало выпол
няться. Теперь рассмотрим следующие два процесса:
Pl:
а
= а + 1;
ь
=
ь
+ 1;
Р2:
Ь
а =
2 *
2 *
Ь;
а;
284
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
Если изначально состояние данных согласованное, то каждый процесс в отдельности
не нарушает согласованности данных. Но что если при параллельном вычислении будет
выполнена такая последовательность действий, которая соблюдает условия взаимоис
ключений при работе с каждым элементом данных (а и Ь)?
+ 1;
а =
а
Ь =
2 *
ь =
ь
а =
2 *
Ь;
+ 1;
а;
После выполнения этой последовательности действий условие а = Ь становится не
верным. Например, если изначально а = Ь =
Ь =
3.
1,
то по завершении вычислений а =
4
и
Проблема решается путем объявления критическим участком каждой из последо
вательностей инструкций.
Таким образом, значение концепции критических участков не уменьшается и в случае
сотрудничества с применением совместного использования. Здесь также могут использо
ваться рассмотренные нами ранее (см. рис.
и
exitcritical.
5.4)
абстрактные функции
entercri tical
В данном случае аргументами этих функций могут быть перемен
ные, файлы или любые другие общие объекты. Более того, если критические участки
используются для обеспечения целостности данных, то выступающего в роли аргумента
функции определенного ресурса или определенной переменной может и не существо
вать. В таком случае мы можем рассматривать аргумент как идентификатор, совместно
используемый параллельными процессами и определяющий критический участок кода,
который должен быть защищен взаимным исключением.
Сотрудничество с использованием связи
В рассмотренных нами случаях каждый процесс имел собственное изолированное
окружение, не включающее в себя другие процессы. Взаимодействие между процесса
ми было сугубо косвенным, и в обоих случаях наблюдалось совместное использование.
В случае конкуренции процессы совместно использовали ресурсы, не имея информации
о существовании друг друга; в случае сотрудничества процессы, не будучи осведомлен
ными явно о наличии других процессов, тем не менее принимают меры к поддержанию
целостности данных. При сотрудничестве с использованием связи различные процессы
принимают участие в общей работе, которая и объединяет их. Связь обеспечивает воз
можность синхронизации, или координации, различных действий процессов.
Обычно можно считать, что связь состоит из сообщений определенного вида. При
митивы для отправки и получения сообщений могут быть предоставлены языком про
граммирования или ядром операционной системы.
Поскольку в процессе передачи сообщений не происходит какого-либо совместного
использования ресурсов, в этом случае сотрудничества взаимоисключения не требуют
ся (хотя проблемы взаимоблокировок и голодания остаются актуальными). В качестве
примера взаимоблокировки можно привести ситуацию, при которой каждый из двух
процессов заблокирован ожиданием сообщения от другого процесса. Голодание мож
но проиллюстрировать следующим примером. Рассмотрим три процесса:
Процесс
PI
PI,
Р2 и РЗ.
многократно пытается связаться с процессами Р2 и РЗ, а те, в свою очередь,
пытаются связаться с процессом Р 1. Может возникнуть ситуация, когда процессы
PI
и Р2 постоянно связываются друг с другом, а процесс РЗ остается заблокированным,
ожидая связи с процессом
остается активными.
PI.
Это не взаимоблокировка, поскольку процесс
PI
при этом
5.3. ВЗАИМОИСКЛЮЧЕНИЯ: АППАРАТНАЯ ПОДДЕРЖКА
285
Требования к взаимным исключениям
Любая возможность обеспечения поддержки взаимных исключений должна соответ
ствовать следующим требованиям.
1.
Взаимоисключения должны осуществляться в принудительном порядке. В любой
момент времени из всех процессов, имеющих критический участок для одного и
того же ресурса или общего объекта, в этом участке может находиться лишь толь
ко один процесс.
2.
Процесс, завершающий работу в некритическом участке, не должен влиять на
другие процессы.
3.
Не должна возникать ситуация бесконечного ожидания доступа к критическому
участку (т.е. не должны появляться взаимоблокировки и голодание).
4.
Когда в критическом участке нет ни одного процесса, любой процесс, запросив
ший возможность входа в него, должен немедленно ее получить.
5.
Не делается никаких предположений о количестве процессов или их относитель
6.
Процесс остается в критическом участке только в течение ограниченного времени.
ных скоростях работы.
Имеется ряд способов удовлетворения перечисленных условий. Одним из них явля
ется передача ответственности за соответствие требованиям самому процессу, который
должен выполняться параллельно. Таким образом, процесс, независимо от того, явля
ется ли он системной программой или приложением, должен координировать свои дей
ствия с другими процессами для работы взаимоисключений без поддержки со стороны
языка программирования или операционной системы. Мы можем говорить о таком под
ходе как о программном. Хотя этот подход чреват большими накладными расходами и
возможными ошибками, чрезвычайно полезно рассмотреть его для лучшего понимания
сложностей, связанных с параллельными вычислениями. Этот вопрос был рассмотрен
в предыдущем разделе. Другой подход, рассматриваемый в разделе
5.3,
включает ис
пользование машинных команд специального назначения. Преимущество этого подхода
заключается в снижении накладных расходов, но такой подход в общем случае пробле
му не решает. Еще один подход заключается в предоставлении определенного уровня
поддержки со стороны операционной системы или языка программирования. Наиболее
важные варианты такого подхода к решению проблемы взаимоисключений рассматрива
ются в разделах
5.3.
5.4-5.6.
ВЗАИМОИСКЛЮЧЕНИЯ:
АППАРАТНАЯ ПОДДЕРЖКА
В этом разделе мы рассмотрим несколько интересных аппаратных подходов к реше
нию вопроса взаимоисключений.
Отключение прерываний
Когда в машине имеется лишь один процессор, параллельные процессы не могут пе
рекрываться, они способны только чередоваться. Кроме того, процесс будет продолжать
ся до тех пор, пока не будет вызвана служба операционной системы или пока процесс
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
286
не будет прерван. Следовательно, для того чтобы гарантировать взаимное исключение,
достаточно защитить процесс от прерывания. Эта возможность может быть обеспечена
в форме примитивов, определенных ядром операционной системы для запрета и разре
шения прерываний. Процесс в таком случае может обеспечить взаимоисключение сле
дующим образом (сравните с рис.
5.4):
while ( true}
{
/*
/*
/*
/*
Запрет прерываний*/;
Критический участок*/;
Разрешение прерываний
Остальной код
*/;
*/;
Поскольку критический раздел не может быть прерван, выполнение взаимоисклю
чения гарантируется. Однако цена такого подхода высока. Эффективность работы мо
жет заметно снизиться, поскольку при этом ограничена возможность процессора по че
редованию программ. Другая проблема заключается в том, что такой подход не будет
работать в многопроцессорной архитектуре. Если вычислительная система включает
несколько процессоров, то вполне возможно (и обычно так и бывает), что несколько
процессов выполняются одновременно. В этом случае запрет прерываний не гарантиру
ет взаимоисключение.
Специальные машинные команды
В многопроцессорной конфигурации несколько процессоров разделяют доступ к об
щей основной памяти. В этом случае отсутствует отношение "ведущий/ведомый"
ter/slave) -
(mas-
процессоры работают независимо, "на равных", и не существует механизма
прерывания, на котором могли бы основываться взаимоисключения.
На уровне аппаратного обеспечения, как уже упоминалось, обращение к ячейке памя
ти исключает любые другие обращения к той же ячейке. Основываясь на этом принци
пе, разработчики процессоров предлагают ряд машинных команд, которые за один цикл
выборки команды атомарно 3 выполняют над ячейкой памяти два действия, такие как
чтение и запись или чтение и проверка значения. Поскольку эти действия выполняются
в одном цикле выборки, на них не в состоянии повлиять никакие другие инструкции.
В этом разделе мы рассмотрим две из наиболее часто реализуемых инструкций
(с остальными инструкциями вы можете познакомиться в
[ 198]).
Команда сравнения и присваивания
Команда сравнения и присваивания,
ющим образом
compare&swap,
может быть определена следу
[104]:
int compare_and_swap(int* word, int testval, int newval}
{
int oldval;
oldval = *word;
if (oldval == testval) *word
return oldval;
3 Термин
=
newval;
атомарно (atomic) означает, что команда рассматривается как единое действие, которое
не может бьrrь прервано.
5.3. ВЗАИМОИСКЛЮЧЕНИЯ: АППАРАТНАЯ ПОДДЕРЖКА
Данная версия команды проверяет ячейку памяти
(*word},
287
сравнивая ее значение с
тестовым
текущее значение ячейки памяти равно
няется
в противном случае значение ячейки памяти остается неиз
(testval}. Если
значением newval;
testval,
оно заме
менным. Всегда возвращается старое значение ячейки памяти; таким образом, ячейка
памяти обновляется, если возвращаемоезначение совпадает с тестовым. Эта атомарная
команда состоит из двух частей (сравнение значений в ячейке памяти и тестового зна
чения}, и, если эти значения совпадают, выполняется присваивание. Вся функция вы
полняется атомарно, т.е. она не может быть прервана.
Другая версия данной команды возвращает логическое зна11ение:
ивание состоялось, и
false
true,
если присва
в противном случае. Та или иная версия команды доступна
практически на всех семействах процессоров (х86,
IA64, sparc,
IВМ
z series
и т.д.), и
большинство операционных систем использует эту команду для поддержки параллель
ности.
На рис.
5.5, а
показан протокол взаимного исключения, основанный на использова
нии описанной команды 4 .
Совместно используемая переменная
инициализируется значением О. Только
bol t
тот процесс, который обнаруживает, что значение
bol t
равно О, может войти в крити
ческий участок. Все другие процессы, пытающиеся войти в критический участок, пере
ходят в режим пережидания занятости.
/* program mutualexclusion */
const int n = /* Количество процессов */;
int bolt;
void P(int i)
/* program mutualexclusion */
int const n = /* Количество процессов */;
int bolt;
void Р (int i)
{
(
while (true)
while (true)
int keyi = 1;
do exchange(&keyi, &bolt)
while (keyi != 0);
/* Критический участок */;
bolt = О;
/* Остальной код*/;
{
while(compare_and_swap(&bolt, О, 1)
== 1)
/* Ничего не делать */;
/*Критический участок*/;
bolt
/*
= О;
Остальной код
*/;
void main ()
void main()
(
bolt = О;
parbegin(P(l),
{
bolt = О;
parbegin(P(l),
Р(2),
а) Команда сравнения и обмена
Рис.
5.5.
Р(2),
... , P(n));
" . , P(n));
б) Команда обмена
Аппаратная помержка взаимоисключений
4 Конструкция parbegin(P 1,P2, •• "Pn) означает следующее: 11риоста1ю11ка 11ы1юлнения основной
110 окончании работы
процедур P1.P 2"",Pn - возобновление выполнения основной прш·раммы.
программы; инициализация параллельного выполнения процедур Р 1 .Р 2 ,""Рп;
288
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
Термин пережидание занятости
(busy waiting, spin waiting)
относится к методике, в
соответствии с которой процесс до тех лор, пока не получит разрешение войти в крити
ческий участок, не может ничего делать, кроме как выполнять инструкции ло проверке
соответствующей переменной для получения разрешения на вход. Когда процесс поки
дает критический участок, он сбрасывает значение переменной Ьо 1 t в О; в этот момент
один и только один из ожидающих процессов получает доступ к критическому участку.
Выбор процесса зависит от того, какой процесс первым выполнит команду сравнения и
присваивания.
Команда обмена
Команда обмена может быть определена следующим образом:
void exchange(int* register, int* memory)
{
int temp;
temp = *memory;
*memory = *register;
*register = temp;
Эта команда обменивает содержимое регистра и ячейки памяти. Команда
ется как в архитектуре
На рис.
5.5, б
Intel IA-32 (Pentium),
так и в архитектуре
XCHG
IA-64 (ltanium).
показан протокол взаимного исключения, основанный на использова
нии этой команды. Совместно используемая переменная
bol t
инициализируется нуле
вым значением. У каждого процесса имеется локальная переменная
ванная значением
име
1.
key,
инициализиро
В критический участок может войти только один процесс, который
обнаруживает, что значение
bol t
равно О. Этот процесс запрещает вход в критический
участок всем другим процессам путем установки значения
bol t
равным
нии работы в критическом участке процесс вновь сбрасывает значение
1. По оконча
bol t в О, тем
самым позволяя другому процессу войти в критический участок.
Заметим, что при использовании рассмотренного алгоритма всегда выполняется сле
дующее соотношение:
bolt+ ~)еу, =n
Если
bol t
= О, то в критическом участке нет ни одного процесса. Если
bol t
то в критическом участке находится ровно один процесс, а именно тот, переменная
1,
key
=
которого имеет нулевое значение.
Свойства подхода, основанного на использовании машинных инструкций
Подход, основанный на использовании специальной машинной инструкции для осу
ществления взаимных исключений, имеет ряд преимуществ.
•
Применим к любому количеству процессов при наличии как одного, так и не
скольких процессоров, совместно использующих основную память.
•
Очень прост, а потому легко проверяем.
•
Может использоваться для поддержки множества критических участков; каждый
из них может быть определен при помощи собственной переменной.
289
5.4. СЕМАФОРЫ
Однако у такого подхода имеются и серьезные недостатки.
•
Используется пережидание занятости. Следовательно, в то время как процесс
находится в ожидании доступа к критическому участку, он продолжает потреблять
процессорное время.
•
Возможно голодание. Если процесс покидает критический участок, а входа в него
ожидают несколько других процессов, то выбор ожидающего процесса произво
лен. Следовательно, может оказаться, что какой-то из процессов будет ожидать
входа в критический участок бесконечно.
•
Возможна взаимоблокировка. Рассмотрим следующий сценарий в однопроцес
Pl выполняет специальную инструкцию (т.е. compare_
and_ swap или exchange) и входит в критический раздел. После этого процесс
Pl прерывается процессом Р2 с более высоким приоритетом. Если Р2 попытается
обратиться к тому же ресурсу, что и Р 1, ему будет отказано в доступе в соответс
сорной системе. Процесс
твии с механизмом взаимоисключений, и он войдет в цикл пережидания занятости.
Однако в силу того, что процесс
Pl
имеет более низкий приоритет, он не получит
возможности продолжить работу, так как в наличии имеется активный процесс с
высоким приоритетом.
Из-за наличия недостатков в случае использования как программных, так и аппаратных
решений нам следует рассмотреть и другие механизмы обеспечения взаимоблокировок.
5.4.
СЕМАФОРЫ
Теперь мы вернемся к механизмам операционных систем и языков программирова
ния, обеспечивающим параллельные вычисления. В табл.
5.3
представлены основные
широко распространенные механизмы. Этот раздел мы начнем с рассмотрения семафо
ров; следующие разделы будут посвящены мониторам и передаче сообщений. Прочие
механизмы в табл.
5.3
будут рассмотрены в главах
моблокировка и голодание'', и
ТА&ЛИЦА
5.3.
13,
6,
"Параллельные вычисления: взаи
"Встроенные операционные системы".
ОСНОВНЫЕ МЕХАНИЗМЫ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ
Семафор
Целочисленное значение, используемое для передачи сигна
(Semaphore)
лов между процессами. Над семафором могут быть выполнены
только три операции (все они являются атомарными): инициали
зация, уменьшение (декремент) и увеличение (инкремент) зна
чения. Операция уменьшения может привести к блокировке про
цесса, а операция увеличения
-
к разблокированию. Известен
также как семафор со счетчиком (couпting
щенный семафор
Бинарный семафор
semaphore)
или обоб
(general semaphore)
Семафор, который может принимать только два значения
-
О и
(Binary semaphore)
Мьютекс
Аналогичен бинарному семафору. Ключевым отличием является
(Mutex)
то, что процесс, блокирующий мьютекс (устанавливающий его
значение равным
0),
его значение равным
должен и разблокировать его (установить
1)
1
290
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
Окончание табл.
5.3
Условная переменная
Тип данных, используемый для блокировки процесса или потока
(Coпditioп variaЫe)
до тех пор, пока не станет истинным некоторое условие
Монитор
Конструкция языка программирования, инкапсулирующая пере
(Moпitor)
менные, процедуры доступа и код инициализации, в абстрактном
типе данных. Переменные монитора могут быть доступны только
через его процедуры доступа, и в любой момент времени только
один процесс может активно работать с монитором. Процедуры
доступа представляют собой критические участки. Монитор мо
жет иметь очередь процессов, ожидающих доступа к нему
Флаги собь1тий
Слово памяти, используемое как механизм синхронизации. Код
(Eveпt
приложения может связать с каждым битом флага свое событие.
flags)
Поток может ждать либо одного события, либо сочетания собы
тий путем проверки одного или нескольких битов в соответству
ющем флаге. Поток блокируется до тех пор, пока все необходи
мые биты не будут установлены (И) или пока не будет установлен
хотя бы ОДИН из битов (ИЛИ)
Почтовые ящики/
Средство обмена информацией между двумя процессами, кото
сообщения
рое может быть использовано для синхронизации
(Mailboxes/messages)
Спин-блокировки
Механизм взаимоисключения, в котором процесс выполняется в
(Spiпlocks)
бесконечном цикле, ожидая, когда значение блокирующей пере
менной укажет доступность критического участка
Первой большой работой, посвященной вопросам параллельных вычислений, стала
монография Дейкстры
[66],
который рассматривал разработку операционной системы
как построение множества сотрудничающих последовательных процессов и создание
эффективных и надежных механизмов поддержки этого сотрудничества. Эти же меха
низмы легко применяются и пользовательскими процессами
-
если процессор и опера
ционная система делают их общедоступными.
Фундаментальный принцип заключается в том, что два или более процессов моrут
сотрудничать посредством
простых сигналов, так что в определенном месте процесс
может приостановить работу до тех пор, пока не дождется соответствующего сигнала.
Требования кооперации любой степени сложности моrут быть удовлетворены соответс
твующей структурой сигналов. Для сигнализации используются специальные перемен
ные, называемые семафорами. Для передачи сигнала через семафор
ет примитив
s emS i gna l ( s) ,
а для его получения
-
примитив
s процесс выполня
s emWa i t ( s) . В пос
леднем случае процесс приостанавливается до тех пор, пока не осуществится передача
соответствующего сигнала. 5
Для достижения желаемого эффекта мы можем рассматривать семафор как перемен
ную, имеющую целое значение, над которой определены три операции.
В статье Дейкстры и во многих других источниках вместо wai t используется буква Р. а вмес
signal - V; это первые буквы голландских слов проверка (proberen) и увеличение (verhogen).
В других источниках встречаются термины wai t и signal. В этой книге для ясности и во избежание
коллизии с аналогичными операциями мониторов использованы термины sernWai t и sernSignal.
5
то
5.4. СЕМАФОРЫ
1.
291
Семафор может быть инициапизирован неотрицательным целочисленным значе
нием.
2.
Операция
semWai t
уменьшает значение семафора. Если это значение становится
отрицательным, процесс, выполняющий операцию
3.
Операция
semSignal
semWai t,
блокируется.
увеличивает значение семафора. Если это значение мень
ше или равно нулю, заблокированный операцией
semWai t
процесс (если таковой
имеется) деблокируется.
Не имеется никаких иных способов получения информации о значении семафора или
изменения его значения, кроме перечисленных.
Объяснить эти операции можно следующим образом. В начапе работы семафор име
ет значение нуль или некоторое положительное значение. Если значение положительное,
то оно равно количеству процессов, которые могут вызвать операцию получения сигнапа
и немедленно продолжить выполнение. Если же значение равно нулю (полученное либо
при инициапизации, либо потому, что количество процессов, равное первоначапьному
значению семафора, вызвапо операцию ожидания), очередной ожидающий процесс бло
кируется, а значение семафора становится отрицательным. Каждое последующее ожи
дание уменьшает значение семафора, так что оно имеет отрицательное значение, по мо
дулю равное числу процессов, ожидающих разблокирования. Когда значение семафора
отрицательное, каждый сигнап разблокирует один из ожидающих процессов.
Есть три интересных следствия определения семафора.
1.
В общем случае до выполнения операции декремента нет никакого способа уз
нать, будет ли процесс заблокирован.
2.
После того как один процесс увеличивает значение семафора, а другой процесс
активируется, оба процесса продолжают выполняться одновременно. Нет никако
го способа узнать, какой процесс (если таковой имеется) будет немедленно про
должать выполнение в однопроцессорной системе.
3.
При передаче сигнапа семафору вам не обязательно знать, находится ли другой
процесс в состоянии ожидания, поэтому количество разблокированных процессов
может быть равно нулю или одному.
На рис.
5.6
приведено более формапьное определение примитивов семафоров.
Предполагается, что примитивы
semWai t
и
setSignal
атомарны, т.е. не могут быть
прерваны. Более ограниченная версия семафора, известная как бинарный семафор,
представлена на рис.
5.7.
Бинарный семафор может принимать только значения О или
1
и может быть определен с помощью следующих трех операций.
1.
Бинарный семафор может быть инициапизирован значением О или
2.
Операция
semWai tB
1.
проверяет значение семафора. Если это значение нулевое,
процесс, выполняющий
semWaitB,
блокируется. Если значение равно
1,
оно из
меняется, становясь равным О, и выполнение процесса продолжается.
3.
Операция
semSignalB
проверяет, имеется ли процесс, блокированный этим се
мафором (значение семафора равно О). Если есть, то процесс, блокированный
операцией
semWai tв,
разблокируется. Если заблокированных процессов нет,
значение семафора устанавливается равным
1.
292
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
struct semaphore
(
int count;
queueType queue;
};
void semWait(semaphore s)
(
s.count--;
i f (s.count < 0)
{
s.queue */;
*/;
/*
Процесс помещается в
/*
Блокировка данного процесса
void semSignal(semaphore s}
{
s.count++;
if (s.count
О && !must_wait) /* Если есть иные ожидающие
15
semSignal(Ьlock);
/*и нет трех активных, разблоки16
/* рование ожидающего процесса
17 else semSignal(mutex);
/*В противном случае открываем
18
/* взаимоисключение */
19 /* Критический участок*/
20
21 semWait(mutex);
/* Вход во взаимоисключение
22 --active;
/* и обновление счетчика active
23 if(active == 0)
/* Покидает последний?
24
must_wait = false;
/* Настройка входа новых процессов
25 if(waiting ==О && !must_wait) /* Если есть иные ожидающие
26
semSignal(Ьlock);;
/*и нет трех активных, разблоки27
/* рование ожидающего процесса
28 else semSignal(mutex);
/*В противном случае открываем
29
/* взаимоисключение */
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
а.
Поясните, как работает эта программа и почему она правильная.
б.
Отличается ли это решение от предыдущего в плане количества процессов, ко
торые могут быть разблокированы одновременно? Поясните.
в.
Эта программа является примером общего проектного шаблона, который явля
ется стандартным средством реализации многих задач, связанных с параллель
ными вычислениями, с помощью семафоров. Он известен как шаблон Переда
ча эстафеты
5.19.
(Pass The Baton).
Опишите этот шаблон.
Бинарных семафоров должно быть достаточно для реализации обобщенных сема
форов. Мы можем использовать для этого операции
два бинарных семафора,
delay
void semWait(semaphore s)
{
semWaitB(mutex);
s--;
if (s < 0)
{
semSignalB(mutex);
semWaitB(delay);
и
mutex.
semWaitB
и
semSignalB
Рассмотрим следующий код.
и
336
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
else
semSignalB(mutex);
void semSignal(semaphore s)
semWaitB(mutex);
s++;
i f (s nap(int(random(lOOO*wander_time)))
P(car_avail); V(car_taken); P(car filled)
P(passenger_released)
od
end passenger
process car(j := 1 to num_cars)
do true -> V(car avail); P(car taken); V(car_filled)
nap(int(random(lOOO*ride_time)))
V(passenger_released)
od
end car
end Jurassic Park
5.22.
В комментариях к рис.
5.12
и табл.
5.4
говорится: "Простое перемещение проверки
в критический участок потребителя недопустимо, так как может привести к взаимо
блокировке". Продемонстрируйте это при помощи таблицы, аналогичной табл.
5.23.
5.4.
Рассмотрим решение задачи производителя/потребителя с бесконечным буфером,
приведенное на рис.
5.13.
Предположим, что скорости работы производителя и
потребителя примерно одинаковы (достаточно распространенная ситуация). Тогда
сценарий работы может выглядеть примерно следующим образом:
Производитель:
Производитель всегда ухитряется добавлять новый элемент в буфер и сигна
лизировать об этом в тот момент, когда потребитель изымает из буфера пре
дыдущий элемент. При этом производитель всегда добавляет новый элемент
в пустой буфер, а потребитель изымает из буфера единственный имеющийся
там элемент. Хотя потребитель никогда не блокируется семафором, к нему при
этом выполняется достаточно большое количество обращений, что приводит к
существенным накладным расходам.
338
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
Разработайте новую, более эффективно работающую в этих условиях программу.
Указание: позвольте п принимать значение
-1,
означающее, что буфер пуст и что
потребитель распознал это состояние буфера и заблокирован до тех пор, пока про
изводитель не добавит в буфер новые данные. Это решение не требует использо
вания локальной переменной т, которая имеется на рис.
5.24.
Рассмотрите рис.
5.16.
5.13.
Изменится ли смысл программы при взаимной замене при
веденных далее инструкций?
a.semWait(e)
semWait(s)
б. semSignal(s)
semSignal(n)
в. semWait(n)
semWait(s)
r. semSignal ( s)
semSignal(e)
5.25.
Приведенный далее псевдокод представляет собой корректную реализацию задачи
//Инициализирован значением О
//Инициализирован значением
1
339
5.9. КЛЮЧЕВЫЕ ТЕРМИНЫ, КОНТРОЛЬНЫЕ ВОПРОСЫ И ЗАДАЧИ
Метки
pl,
р2, рЗ и
el,
е2, еЗ относятся к строкам приведенного выше кода (р2 и
е2 охватывают по три строки кода). Семафоры
empty
и
full
представляют собой
линейные семафоры, которые могут принимать неограниченные отрицательные и
положительные значения. Имеется несколько процессов производителей, именуе
мых Ра, РЬ, Ре,"., и несколько процессов потребителей, именуемых Са, СЬ, Се,".
Каждый семафор поддерживает очередь
FIFO
("первым вошел
-
первым вышел")
заблокированных процессов. В диаграмме планирования, показанной ниже, каж
дая строка представляет состояние буфера и семафоров после запланированного
выполнения. Для простоты мы предполагаем, что планирование таково, что про
цессы никогда не будут прерваны во время выполнения части кода
pl,
р2,
".,
еЗ.
Ваша задача заключается в том, чтобы закончить приведенную ниже диаграмму.
Планируемый
war
Состояние
выполнения
и очереди
Инициализация
full
full
=О
Буфер
Состояние
и очереди
ООО
ernpty = +3
Са выполняет
el
full = -1
(Са)
ООО
ernpty = +3
сь выполняет
el
full = -2
(Са, СЬ)
ООО
ernpty = +3
Ра выполняет
pl
full = -2
(Са, СЬ)
ООО
ernpty = +2
Ра выполняет р2
full = -2
(Са, СЬ)
хоо
ernpty = +2
ernpty = +2
Ра выполняет р3
full = -1
(СЬ) Са
хоо
Са выполняет е2
full = -1
(СЬ)
ООО
ernpty = +2
(СЬ)
ООО
ernpty = +3
Са выполняет е3
full = -1
1
full =
ernpty =
pl
full =
ernpty =
Ра выполняет
full =
ernpty =
РЬ выполняет
full =
ernpty =
full =
ernpty =
full =
ernpty =
full =
ernpty =
Ре выполняет
full =
ernpty =
сь выполняет
full =
ernpty =
full =
ernpty =
full =
ernpty =
full =
ernpty =
РЬ выполняет р
Ра выполняет
РЬ выполняет
Ре выполняет
pl
сь выполняет
Ра выполняет
РЬ выполняет
pl-p3
Ре выполняет
Ра выполняет
pl
Pd выполняет pl
Са выполняет
el-e3
Ра выполняет
full =
ernpty =
full =
ernpty =
full =
ernpty =
full =
ernpty =
full =
ernpty =
Ра выполняет
full =
ernpty =
Се выполняет е3
full =
ernpty =
Pd
full =
ernpty =
Се выполняет
el-e2
выполняет р2-р3
empty
340
S.26.
ГЛАВА 5. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОИСКЛЮЧЕНИЯ И МНОГОЗАДАЧНОСТЬ
Эта задача демонстрирует использование семафоров для согласования процессов
трех типов. 7 Дед Мороз спит в своей избушке на Северном полюсе и может быть
разбужен только
2)
1) пятью
сестрами-Снегурочками, вернувшимися из отпуска, или
несколькими Снеговиками, у которых возникли проблемы при изготовлении иг
рушек. Чтобы дать Деду Морозу поспать, Снеговики будят его только в том слу
чае, когда проблемы возникают у троих из них. Когда трое Снеговиков решат свои
вопросы, все остальные Снеговики, желающие посетить Деда Мороза, должны
ждать, пока вернется побывавшая у него тройка. Если проснувшийся Дед Мороз
обнаруживает у дверей избушки и Снеговиков, и последнюю из Снегурочек, то он
просит Снеговиков обождать со своими проблемами до окончания празднования
Нового года, поскольку куда важнее ехать поздравлять малышей. (Снегурочки не
спешат вернуться из отпуска и остаются там до последнего момента.) Прибывшая
последней Снегурочка идет будить Деда Мороза, пока остальные занимаются ма
кияжем в своих комнатах. Решите эту задачу с помощью семафоров.
S.27.
Покажите, что система передачи сообщений и семафоры обладают эквивалентной
функциональностью, для чего выполните следующее.
а.
Реализуйте передачу сообщений с использованием семафоров. Указание: сде
лайте это с помощью совместно используемого буфера для хранения почтовых
ящиков, каждый из которых представляет собой массив слотов для сообщений.
б.
Реализуйте семафоры с использованием передачи сообщений. Указание: добавьте в систему синхронизирующий процесс.
5.28.
Объясните, в чем заключается проблема в этой реализации задачи с одним писате
лем и многими читателями?
/!Общая переменная,
int readcount;
Semaphore mutex, wrt;
11
//Общие семафоры,
11
Писатепь:
semWait(wrt);
/*
Выполнение записи
semSignal(wrt);
*/
инициализирована О
инициализированы
1;
Читатепи:
semWai t (mutex) ;
readcount := readcount + 1;
if readcount == 1 then semWait(wrt);
semSignal(mutex);
/*
Выполнение чтения
*/
semWait (mutex);
readcount := readcount - 1;
if readcount ==О then Up(wrt);
semSignal(mutex);
7
Я признателен Джону Троно (John Trono) из колледжа Св. Михаила в Вермонте за предо
ставление этой задачи.
·-"·--·
ГЛАВА® _
_____________________________
,
ПАРАЛЛЕЛЬНЫЕ
ВЫЧИСЛЕНИЯ:
ВЗАИМОБЛОКИРОВКА
И ГОЛОДАНИЕ
В ЭТОЙ ГЛАВЕ ...
6.1. Принципы взаимноrо бnокирования
Повторно используемые ресурсы
Расходуемые ресурсы
Графы распределения ресурсов
Условия возникновения взаимоблокировок
6.2. Предотвращение взаимобnокировок
Взаимоисключения
Удержание и ожидание
Отсутствие перераспределения
Циклическое ожидание
6.3. Устранение взаимобnокировок
Запрещение запуска процесса
Запрет выделения ресурса
6.4. Обнаружение взаимобnокировок
Алгоритм обнаружения взаимоблокировки
Восстановление
6.5. Интеrрированные стратеrии разрешения взаимобnокировок
6.6.
Задача об обедающих фиnософах
Решение с использованием семафоров
Решение с использованием монитора
342
ГЛАВА6. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОБЛОКИРОВКА И ГОЛОДАНИЕ
6.7.
Механизмы параллельных вычислений в UNIX
Каналы
Сообщения
Совместно используемая память
Семафоры
Сигналы
6.8.
Механизмы параллельных вычислений ядра Linux
Атомарные операции
Циклические блокировки
Базовые циклические блокировки
Циклические блокировки читателя/писателя
Семафоры
Бинарные семафоры и семафоры со счетчиками
Семафоры читателя/писателя
Барьеры
RCU (Read-Copy-Update)
6.9. Примитивы синхронизации потоков Solaris
Блокировки взаимоисключений
6.1 О. Механизмы параллельных вычислений в Windows
Функции ожидания
Объекты диспетчера
Критические участки
Гибкие блокировки читателя/писателя и условные переменные
Синхронизация без участия блокировок
6.11. Межпроцессное взаимодействие в Android
6.12. Резюме
6.13. Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
6.1. ПРИНЦИПЫ ВЗАИМНОГО БЛОКИРОВАНИЯ
343
УЧЕБНЫЕ ЦЕЛИ
Перечислить и пояснить условия взаимоблокировки .
•
Описать стратегии предотвращения взаимоблокировок, связанные с каждым из ус
•
ловий взаимоблокировки.
Объяснить разницу между предотвращением взаимоблокировки и устранением
•
взаимоблокировки.
•
Объяснить разницу между двумя подходами к устранению взаимоблокировки.
•
Объяснить фундаментальную разницу между обнаружением взаимоблокировок и
предотвращением и устранением взаимоблокировок .
•
Пояснить принципы разработки комплексных стратегий для взаимоблокировок.
•
Проанализировать задачу обедающих философов.
Пояснить методы параллельных вычислений и синхронизации, используемые в
•
UNIX, Linux, Solaris, Windows
и
Android.
В этой главе продолжается рассмотрение параллельных вычислений. Кроме того, она
посвящена двум проблемам, доставляющим основные неприятности при работе с парал
лельными вычислениями: взаимоблокировкам и голоданию. Глава начнется с изложения
основных принципов взаимоблокировок и связанной с ними проблемы голодания. Затем
мы узнаем о трех основных подходах к работе с взаимоблокировками: предотвращении,
обнаружении и устранении. Под конец мы рассмотрим еще одну классическую задачу,
иллюстрирующую вопросы синхронизации и взаимоблокировки, а именно
-
задачу об
обедающих философах.
Как и в главе
5,
"Параллельные вычисления: взаимоисключения и многозадачность",
здесь мы ограничимся рассмотрением проблем в единой системе; распределенным сис
темам посвящена глава
18,
"Распределенная обработка, вычисления «клиент/сервер» и
кластеры''. Анимации, иллюстрирующие взаимоблокировки, можно найти на сайте дан
ной книги.
6.1.
ПРИНЦИПЫ ВЗАИМНОГО БЛОКИРОВАНИЯ
Взаимное блокирование (deadlock 1) можно определить как перwанентное блокирова
ние множества процессов, которые либо конкурируют в борьбе за системные ресурсы,
либо сообщаются один с другим. Множество процессов оказывается взаимно блокиро
ванным, если каждый процесс множества заблокирован в ожидании события (обычно
-
освобождения некоторого запрашиваемого ресурса), которое может быть вызвано только
другим блокированным процессом множества. В отличие от других проблем, возника
ющих в процессе управления параллельными вычислениями, данная проблема в общем
случае эффективного решения не имеет.
1 Дословно
-
"мертвые объятия". В русскоЯ'Зычной литературе встречаются термины "туnик"' и
"клинч". однако наиболее nолно отражает суть происходящего именно термин "взаимоблокиров
ка··.
-
Пр~wеч. пер.
344
ГЛАВА 6. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОБЛОКИРОВКА И ГОЛОДАНИЕ
Все взаимоблокировки предполагают наличие конфликта в борьбе за ресурсы между
двумя или несколькими процессами. Наиболее ярким примером может служить транс
портная взаимоблокировка. На рис.
6.1
показана ситуация, когда четыре автомобиля
должны примерно одновременно пересечь перекресток. Четыре квадранта перекрестка
представляют собой ресурсы, которые требуются процессам. В частности, для успешно
го пересечения перекрестка всеми четырьмя автомобилями необходимые ресурсы выгля
дят следующим образом.
•
Автомобилю
1,
движущемуся на север, нужны квадранты а и
•
Автомобилю
2,
движущемуся на запад, нужны квадранты
•
Автомобилю
3,
движущемуся на юг, нужны квадранты в и г.
•
Автомобилю
4,
движущемуся на восток, нужны квадранты г и а.
в
б
г
а
а) Взаимоблокировка возможна
Рис.
6.1.
6
6.
и в.
б) Взаимоблокировка произошла
Пример взаимоблокировки
Обычное правило пересечения перекрестка состоит в том, что автомобиль должен
уступить дорогу движущемуся справа. Это правило работает, когда перекресток пере
секают два или три автомобиля. Например, если на перекрестке встретятся автомобили,
движущиеся на север и на запад, то автомобиль, движущийся на север, уступит дорогу
автомобилю, движущемуся на запад. Но если перекресток пересекают одновременно че
тыре автомобиля, каждый из которых согласно правилу воздержится от въезда на пере
кресток, возникнет взаимоблокировка.
Она возникнет и в том случае, если все четыре машины проигнорируют правило
и осторожно въедут на перекресток, поскольку при этом каждый автомобиль захватит
один ресурс (один квадрант) и останется на вечной стоянке в ожидании, когда другой
автомобиль освободит следующий требующийся для пересечения перекрестка квадрант.
Итак, мы опять получили взаимоблокировку.
Рассмотрим теперь картину взаимоблокировки с участием процессов и компьютер
ных ресурсов. На рис.
diagram) двух
6.2
показана диаграмма совместного выполнения (joiпt
progress
процессов, конкурирующих в борьбе за два ресурса. Каждый из процессов
345
6. 1. ПРИНЦИПЫ ВЗАИМНОГО БЛОКИРОВАНИЯ
требует исключительного владения обоими ресурсами на некоторое время. Процессы Р
и
Q
имеют общий вид:
Процесс
р
Процесс
•••
Получение А
Получение
•••
в
Получение А
•••
•••
Освобождение А
Освобождение в
•••
•••
Освобождение А
Освобождение в
•••
•••
На рис.
Q.
в
•••
Получение
цесса
Q
•••
6.2
ось х представляет выполнение процесса Р, а ось у
выполнение про
-
Таким образом, совместное выполнение двух процессов представлено путем,
идущим из начала координат в северо-восточном направлении.
Выполнение
Q
2
Требование
А
Получе
ние А
3
Требование
в
5
Получе
ние В
6
Выполнение
р
Получснис А
~ - И Р, и Q нужен ресурс А
~ - И Р, и Q нужен ресурс В
О
-
Получсние В
Освобождснис А
Освобождснис В
Требование
А
Область неизбежной взаимоблокировки
-
Освобождение
в
Возможный путь выполнения Р и Q.
Горизонтальная часть пути соответствует
выполнению Р и ожиданию Q.
Вертикальная часть пути соответствует
выполнению
Рис.
6.2.
Q и ожиданию Р.
Пример взаимоблокировки
346
ГЛАВА 6. ПАРАллельныЕ вычисления: взАимоБлокиРовкд и голодАНИЕ
В однопроцессорной системе в каждый момент времени может выполняться только
один процесс, так что путь состоит из чередующихся горизонтальных и вертикальных
отрезков, причем горизонтальные отрезки представляют работу процесса Р, а вертикаль
ные
-
процесса
Q.
На рисунке показаны области, в которых процессам Р и
ресурс А, процессам Р и
Q-
ресурс В, процессам Р и
Q-
Q
требуется
оба ресурса. Поскольку мы
предполагаем, что каждый процесс требует исключительного управления любым ресур
сом, все эти области
выполнения Р и
На рис.
6.2
-
запрещенные; никакой путь, представляющий ход совместного
не может входить в эти области.
Q,
показаны шесть различных путей выполнения процессов.
1. Q получает
ресурс В, затем
ресурс А, затем освобождает ресурсы В и А. Когда
-
процесс Р продолжает выполнение, он может получить оба ресурса.
2. Q получает
ресурс В, а затем
ресурс А. Процесс Р начинает работу и блоки
-
руется при запросе ресурса А.
Q
освобождает ресурсы В и А. Когда процесс Р
продолжает выполнение, он может получить оба ресурса.
3. Q получает
ресурс В, затем Р получает ресурс А. Взаимоблокировка неизбежна,
поскольку выполнение
процесса Р
4.
-
заблокируется при запросе ресурса А, а выполнение
Р получает ресурс А, затем
поскольку выполнение
процесса Р
5.
Q
при запросе ресурса В.
-
Q
Q получает
ресурс В. Взаимоблокировка неизбежна,
заблокируется при запросе ресурса А, а выполнение
при запросе ресурса В.
Р получает ресурс А, а затем
-
ресурс В. Процесс
Q начинает
работу и блоки
руется при запросе ресурса В. Р освобождает ресурсы А и В. Когда процесс
Q
продолжает выполнение, он может получить оба ресурса.
6.
Р получает ресурс А, затем
процесс
На рис.
6.2
Q
-
ресурс В, затем освобождает ресурсы А и В. Когда
продолжает выполнение, он может получить оба ресурса.
имеется область, которую можно назвать фатальной,
-
если путь выпол
нения входит в эту область, взаимоблокировка неизбежна. Обратите внимание, что су
ществование фатальной области зависит от логики этих двух процессов. Однако взаимо
блокировка неизбежна только когда совместное выполнение этих двух процессов создает
путь, который входит в фатальную область.
Произойдет взаимоблокировка или нет, зависит как от динамики выполнения про
цессов, так и от подробностей построения приложения. Предположим, например, что
процесс Р не требует получения обоих ресурсов одновременно и имеет следующий вид:
Процесс Р
•••
Получение А
•••
Освобождение А
•••
Получение В
•••
Освобождение в
•••
Процесс
Q
•••
Получение В
•••
Получение А
•••
Освобождение в
•••
Освобождение А
•••
6. 1. ПРИНЦИПЫ ВЗАИМНОГО БЛОКИРОВАНИЯ
Эта ситуация изображена на рис.
6.3.
347
Немного поразмыслив, вы можете убедиться,
что независимо от того, каким образом два процесса выполняются друг относительно
друга, взаимоблокировка невозможна.
Выполнение
____________.__ _ __,____ ___._ _ __,________ Выполнение
р
Освобождснис А
Получение А
Получение В
Освобождснис В
'----.,--------
'-----.г---'
~ - И Р, и Q нужен ресурс А
Требование
А
Требование
В
~ - И Р, и Q нужен ресурс В
-
Рис.
6.3.
Возможный путь выполнения Р и Q.
Горизонтальная часть пути соответствует
выполнению Р и ожиданию Q.
Вертикальная часть пути соответствует
выполнению Q и ожиданию Р.
Пример отсутствия взаимоблокировки
[15]
Как видите, диаграмма совместного выполнения может использоваться для записи
истории выполнения двух процессов, которые совместно используют ресурсы. В тех
случаях, когда более двух процессов могут конкурировать за один и тот же ресурс, тре
буется диаграмма более высокой размерности. Принципы же, касающиеся фатальных
областей и взаимоблокировок, остаются при этом теми же.
Повторно используемые ресурсы
Ресурсы можно разделить на две основные категории: повторно используемые
(reusaЫe) и расходуемые (consumaЬle). Повторно используемые ресурсы могут безопас
но использоваться одновременно только одним процессом и при этом не истощаться.
Процесс получает ресурс, который позже освобождается для повторного использования
другими процессами. Примерами повторно используемых ресурсов могут служить про
цессор, каналы ввода-вывода, основная и вторичная память, периферийные устройства,
а также структуры данных, такие как файлы, базы данных и семафоры.
348
ГЛАВА 6. ПАРА Л ЛЕЛЬ Н ЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМ О БЛ О К И РОВ К А И ГОЛОДАНИЕ
В качестве примера взаимоблокировки с повторно используемым ресурсом рассмот
рим два процесса, которые конкурируют за исключительный доступ к дисковому файлу
Dи
стримеру Т. Программа выполняет показанные на рис .
Процесс Р
Шаг
6.4
операции.
Процесс
Действие
Шаг
Q
Действие
Ро
Запрос(D)
Р1
Блокировка(D)
Р2
Запрос(Т)
qo
ql
q2
Рз
Блокировка(Т)
qз
Блокировка(D)
Р4
Выполнение функции
q4
q5
Выполнение функции
Деблокирование(Т)
qб
Деблокирование(D)
Ps
рб
Рис.
Деблокирование(D)
Деблокирование(Т)
6.4.
Запрос(Т)
Блокировка(Т)
Запрос(D)
Пример конкуренции двух процессов в борьбе за повторно
используемый ресурс
Взаимоблокировка осуществляется в том случае, когда каждый процесс захватывает
один ресурс и запрашивает другой. Например, взаимоблокировка произойдет при следу
ющем чередовании двух процессов:
Может показаться, что это ошибка программиста, не имеющая отношения к разра
ботчику операционной системы . Однако, как мы знаем, разработка программ мя парал
лельных вычислений
-
весьма сложная задача, и выявление источника взаимоблоки
ровки в сложной программе
-
дело очень непростое . Одна из стратегий при работе с
такими взаимоблокировками состоит в наложении системных ограничений на порядок
запроса ресурсов .
Другим примером взаимоблокировки с повторно используемыми ресурсами мо
гут быть запросы к основной памяти. Предположим, что для распределения доступно
200
Кбайт памяти и выполняется такая последовательность запросов.
Запрос
Pl
Р2
•••
•••
80
Кбайт ;
Запрос
•••
Запрос
60
70
Кбайт ;
•••
Кбайт ;
Запрос
80
Кбайт ;
Если оба процесса дойдут до своего второго запроса, возникнет взаимоблокировка.
Если количество требуемой памяти заранее неизвестно, работать с таким типом взаимо
блокировок на уровне системных ограничений (в том числе и операционной системы)
очень сложно. Наилучший способ справиться с этой конкретной проблемой заключается
в использовании виртуальной памяти, о которой рассказывается в главе
память".
8,
"Виртуальная
6.1. ПРИНЦИПЫ ВЗАИМНОГО БЛОКИРОВАНИЯ
349
Расходуемые ресурсы
Расходуемыми являются те ресурсы, которые могут быть созданы (произведены) и
уничтожены (потреблены). Обычно ограничений на количество расходуемых ресурсов
определенного типа нет. Незаблокированный процесс-производитель может выпустить
любое количество таких ресурсов; когда процесс запрашивает некоторый ресурс, пос
ледний прекращает свое существование. Примерами расходуемых ресурсов могут слу
жить прерывания, сигналы, сообщения и информация в буферах ввода-вывода.
В качестве примера взаимоблокировки с расходуемыми ресурсами рассмотрим сле
дующую пару процессов, каждый из процессов которой пытается получить сообщение
от другого процесса, а затем отправить сообщение своему визави.
Pl
Р2
•••
•••
Receive(P2) ;
Receive(Pl) ;
•••
Send(P2 , Ml) ;
•••
Send(Pl ,
Взаимоблокировка осуществляется, если операция
Rece i ve
М2) ;
является блокирующей
(т.е. получающий процесс блокируется до тех пор, пока сообщение не будет получено).
И вновь причиной взаимоблокировки является ошибка при разработке программы. Такие
ошибки обычно довольно таинственны и трудноуловимы. Кроме того, может оказаться,
что взаимоблокировку вызывает только достаточно редкая комбинация событий, и тогда
до того, как ошибка проявит себя, программа может быть в эксплуатации многие годы.
Единой эффективной стратегии для работы со всеми типами взаимоблокировок нет.
Основные подходы к решению этой проблемы следующие.
•
Предотвращение взаимоблокировок. Не позволять осуществиться одному из
трех необходимых условий возникновения взаимоблокировки или предотвратить
возникновение условия циклического ожидания.
•
Устранение взаимоблокировок. Не выполнять запрос ресурса, если его выделе
ние может привести к взаимоблокировке.
•
Обнаружение взаимоблокировок. По возможности выполнять запросы ресурсов,
но периодически проверять наличие взаимоблокировки и принимать меры для
восстановления.
Мы изучим все перечисленные подходы к решению проблемы, но сначала рассмот
рим условия возникновения взаимоблокировок.
Графы распределения ресурсов
Полезным инструментом для характеристики распределения ресурсов между процес
сами является граф распределении ресурсов, предложенный Холтом
(Holt) [ 109].
Граф
распределения ресурсов представляет собой ориентированный граф, который изобража
ет состояние системы ресурсов и процессов, в котором каждый процесс и каждый ре
сурс представлены узлами. Дуги графа, направленные от процесса к ресурсу, указывают
ресурс, запрошенный процессом, но еще не предоставленный ему (рис.
6.5,
а).
350
ГЛАВА 6. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОБЛОКИРОВКА И ГОЛОДАНИЕ
В узле ресурса каждый экземпляр ресурса указан точкой. Примерами типовресур
сов, которые могут иметь несколько экземпляров, являются устройства ввода-вывода,
которые выделяются модулем управления ресурсами в операционной системе. Дуга гра
фа, направленная из узла повторно используемого ресурса к процессу, указывает запрос,
который был выполнен (рис.
6.5,
б), т.е. этому процессу была назначена одна единица
ресурса. Дуга графа, направленная из узла расходного ресурса к процессу, указывает,
что процесс является производителем данного ресурса.
На рис.
6.5, в показан пример взаимоблокировки. Имеется только по одной единице
Ra и Rb. Процесс Р 1 удерживает Rb и запрашивает Ra, а Р2 удерживает Ra и
запрашивает Rb. Граф на рис. 6.5, г имеет ту же топологию, что и на рис. 6.5, в, но здесь
нет взаимоблокировки, потому что доступно несколько единиц каждого ресурса .
ресурсов
-+
_зап_раши_вает
.
Rй
Pl
j
Ra
б) Ресурс удерживается
а) Ресурс запрошен
Ra
Ra
Rb
Rb
в) Циклическое ожидание
г) Огсутствие взаимоблокировки
Рис.
6.5.
Примеры графов распределения ресурсов
Граф распределения ресурсов на рис.
рис.
Удерживает
6.1, б.
6.6
соответствует взаимоблокировке на
Обратите внимание, что в этом случае у нас нет простой ситуации, в которой
каждый из двух процессов удерживает ресурс, необходимый другому процессу. В этом
случае скорее имеется круговая цель процессов и ресурсов, приводящая к взаимоблоки
ровке.
6.1. ПРИНЦИПЫ ВЗАИМНОГО БЛОКИРОВАНИЯ
Ra
Rc
Rb
351
Rd
Рис. б.б. Граф распределения ресурсов для рис. 6. 1, б
Условия возникновения взаимоблокировок
Для того чтобы взаимоблокировка стала возможной, требуются три условия.
1.
Взаимные исключения. Одновременно использовать ресурс может только один
процесс.
2.
Удержание и ожидание. Процесс может удерживать выделенные ресурсы во вре
мя ожидания других ресурсов.
3.
Отсутствие перераспределения. Ресурс не может быть принудительно отобран у
удерживающего его процесса.
Эти условия выполняются довольно часто. Например, взаимоисключения необходи
мы для гарантии согласованности результатов и целостности базы данных. Аналогично
невозможно произвольное применение перераспределения, в особенности при работе с
данными, когда требуется обеспечить механизм отката.
Кроме перечисленных трех условий, необходимых, но не достаточных, для реального
осуществления взаимоблокировки, требуется выполнение четвертого условия.
4.
Циклическое ожидание. Существует замкнутая цепь процессов, каждый из кото
рых удерживает как минимум один ресурс, необходимый процессу, следующему в
цепи после данного (см. рис.
6.5,
в и
6.6).
Четвертое условие в действительности представляет собой потенциальное следствие
первых трех, т.е. при наличии первых трех условий может осуществиться такая последо
вательность событий, которая приведет к неразрешимому циклическому ожиданию (что,
по сути, и является определением взаимоблокировки) . Неразрешимость циклического
ожидания из условия
4
обеспечивается выполнением предыдущих трех условий. Таким
образом, совокупность четырех перечисленных выше условий является необходимым и
достаточным условием взаимоблокировки. 2
2 Обычно в литературе все четыре условия перечисляются как 11собходимь1с дня осуществления
взаимоблокировки, однако такое изложение скрывает некоторые тонкости 1!а111юго 1ю11роса. Усно
вие циклического ожидания кардинально отничается от оста;1ь11ых трех ус;ю1.1ий.
ловия представляют собой, по сути, незыблемые правила.,
n то
время как усJювис
1lсрвые три ус
4 11релставляет
собой ситуацию, которая может осуществиться при опреде;1е111юй 1юслсдовате11ыюсти запросов и
освобождений ресурсов про11ессом. Объединение всех четырех усновий в сли11ый блок мето;ю;юги
чески приводит к стиранию различий между предотвращением и устранением нзаимоблокировок.
Подробное обсужде11ие этих вопросов приведено в
[229]
и
[230] .
352
ГЛАВА 6. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОБЛОКИРОВКА И ГОЛОДАНИЕ
Чтобы понять это, полезно вернуться к концепции диаграммы совместного выпол
нения, показанной на рис.
6.2.
Напомним, что мы определили фатальную область как
область, обладающую тем свойством, что вошедшие в нее процессы будут обязательно
взаимно блокированы. Фатальная область существует, только если соблюдены все три
первые перечисленные выше условия. Если одно или несколько из этих условий не вы
полняются, фатальной области не существует, и взаимоблокировка невозможна. Таким
образом, эти условия являются необходимыми для существования взаимоблокировки.
Но чтобы она произошла реально, должна иметься не только фатальная область, но и
такая последовательность запросов ресурсов, которая приведет в эту область. Если воз
никает условие циклического ожидания, значит, произошел вход в фатальную область.
Таким образом, всех четырех перечисленных выше условий достаточно для взаимобло
кировки.
Взаимоблокировка возможна
Взаимоблокировка имеет место
1. Взаимное
1.
Взаимное исключение
2.
Нет перераспределения
3.
Удержание и ожидание
4.
Циклическое ожидание
2. Нет
исключение
перераспределения
3. Удержание
и ожидание
Для решения проблем взаимоблокировки имеется три основных подхода. Во-первых,
взаимоблокировки можно предотвратить путем принятия стратегии, которая устраняет
одно из условий (условий
1-4).
Во-вторых, можно устранить взаимоблокировку, сделав
соответствующие динамические выборы на основе текущего состояния распределения
ресурсов. В-третьих, можно попытаться обнаружить взаимоблокировку (условия
1-4)
и принять меры для восстановления работоспособности. Мы обсудим каждый из этих
ПОДХОДОВ ниже.
6.2.
ПРЕДОТВРАЩЕНИЕ ВЗАИМОБЛОКИРОВОК
Стратегия предотвращения, по сути, представляет собой такую разработку системы,
которая позволит исключить саму возможность взаимоблокировок. Методы предотвра
щения взаимоблокировок можно разбить на два класса. Косвенный метод состоит в пре
дотвращении одного из первых трех условий возникновения взаимоблокировки; прямой
метод предотвращает циклическое ожидание (условие
4).
Рассмотрим приемы, связан
ные с каждым из условий, в отдельности.
Взаимоисключения
В общем случае избежать использования взаимоисключений невозможно. Если до
ступ к ресурсу должен быть исключительным, то операционная система обязана поддер
живать взаимоисключения. Некоторые ресурсы, такие как файлы, могут позволять мно
жественный доступ для чтения и исключительный доступ для записи. Но даже в этом
случае возможно возникновение взаимоблокировки, если право записи в файл требуется
нескольким процессам одновременно.
6.2. ПРЕДОТВРАЩЕНИЕ ВЗАИМОБЛОКИРОВОК
353
Удержание и ожидание
Этого условия можно избежать, потребовав, чтобы процесс запрашивал все необхо
димые ресурсы одновременно, и блокировать процесс до тех пор, пока такой запрос
не сможет быть выполнен полностью в один и тот же момент времени. Такой подход
неэффективен по двум причинам. Во-первых, процесс может длительное время ожидать
одновременной доступности всех затребованных ресурсов, в то время как реально он
мог бы работать и только с частью из них. Во-вторых, затребованные процессом ре
сурсы могут оставаться неиспользуемыми значительное время, в течение которого они
оказываются недоступными другим процессам. Еще одна проблема состоит в том, что
процессу может не быть известно заранее, какие именно ресурсы ему потребуются.
Имеется также практическая проблема, возникающая при использовании парадигмы
модульности или многопоточности в программировании приложения. Использующее
описанную технологию приложение для одновременного запроса должно знать обо всех
необходимых ресурсах на всех уровнях или во всех модулях, что противоречит упомя
нутой парадигме.
Отсутствие перераспределения
Этого условия можно избежать несколькими путями. Например, можно поступить
следующим образом: если процесс удерживает некоторые ресурсы и ему отказано в
очередном запросе, то он должен освободить захваченные ресурсы и при необходи
мости запросить их вновь вместе с тем ресурсом, в доступе к которому ему было
отказано. С другой стороны, если процесс затребовал некий ресурс, в настоящий мо
мент захваченный другим процессом, то операционная система может вытеснить этот
процесс и потребовать от него освободить захваченные им ресурсы. Этот метод может
предотвратить взаимоблокировку лишь в том случае, когда все процессы имеют раз
ные приоритеты.
Такой подход на практике применим только к тем ресурсам, состояние которых мож
но легко сохранить, а позже восстановить, как, например, в случае, когда ресурс пред
ставляет собой процессор.
Циклическое ожидание
Условия циклического ожидания можно избежать путем упорядочения типов ресур
сов. При этом, если процесс запросил ресурс типа
R,
далее он может запросить только
ресурсы, следующие согласно указанному упорядочению за
R.
Чтобы убедиться в эффективности данной стратегии, свяжем с каждым типом ресур
са свой индекс. Тогда ресурс
R;
предшествует ресурсу
RJ'
если
i ;
/*Клиент освобождает две вилки через монитор*/
release_forks(k);
Рис.
6. 18.
Еще одно решение задачи об обедающих философах
с применением мониторов
396
6.22.
ГЛАВА 6. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ: ВЗАИМОБЛОКИРОВКА И ГОЛОДАНИЕ
Две переменные, а и Ь, имеют начальные значения соответственно
денный далее код работает в
Поток
а
1
Поток
= 4;
-
и
2.
2
-
= 3;
mЬ();
ь
1
Linux.
с
=
Ь;
rmb() ;
d
=
а ;
Каких возможных ошибок удается избежать с помощью барьеров памяти?
Приве
ЧАСТЬ 111
ПАМЯТЬ
ГЛАВА rz:;
УПРАВЛЕНИЕ
ПАМЯТЬЮ
В ЭТОЙ ГЛАВЕ ...
7 .1. Требования к управлению памятью
Перемещение
Защита
Совместное использование
Логическая организация
Физическая организация
7 .2. Распределение памяти
Фиксированное распределение
Размеры разделов
7 .З. Страничная организация памяти
7 .4. Сегментация
7.5. Резюме
7 .б. Ключевые термины, контрольные вопросы и задачи
Ключевые термины
Контрольные вопросы
Задачи
Приложение 7.А. Загрузка и связывание
Загрузка
Абсолютная загрузка
Перемещаемая загрузка
Динамическая загрузка во время выполнения
Компоновка
Редактор связей
Динамический компоновщик
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
400
УЧЕБНЫЕ ЦЕЛИ
Обсудить основные требования к управлению памятью.
•
Понимать причины распределения памяти и пояснять работу различных использу
•
емых технологий.
•
Понимать концепцию страничной организации памяти .
•
Понимать концепцию сегментации.
•
Оценить относительные преимущества страничной организации памяти и сегмен
тации.
•
Описать концепции загрузки и связывания.
В однозадачных системах основная память разделяется на две части: одна часть
для операционной системы (резидентный монитор, ядро), а вторая
-
-
для выполняющей
ся в текущий момент времени программы. В многозадачных системах "пользователь
ская" часть памяти должна быть распределена для размещения нескольких процессов .
Эта задача распределения выполняется операционной системой динамически и известна
под названием управление памятью
(memory
maпagement).
Эффективное управление памятью жизненно важно для многозадачных систем. Если
в памяти располагается только небольшое число процессов, то большую часть времен11
все эти процессы будут находиться в состоянии ожидания выполнения операций ввода
вывода, и загрузка процессора будет низкой. Таким образом, желательно эффективное
распределение памяти, позволяющее разместить в ней как можно больше процессов .
Глава начинается с рассмотрения требований, которым должны удовлетворять разра
батываемые системы управления памятью. Позже мы приступим к рассмотрению различ
ных технологий управления памятью, начав с применения нескольких простых схем.
В табл.
ТАБЛИЦА
Кадр
7.1
7.1.
приведены некоторые ключевые термины по данной теме.
ОСНОВНЫЕ ТЕРМИНЫ, СВЯЗАННЫЕ С УПРАВЛЕНИЕМ ПАМЯТЬЮ
(frame)
Страница
(page)
Блок основной памяти фиксированной длины
Блок данных фиксированной длины, находящийся во вторичной
памяти (такой, как диск). Страница данных может быть временно
скопирована в кадр основной памяти
Сегмент (segmeпt)
Блок данных переменной длины, находящийся во вторичной
памяти. В доступную область основной памяти может быть ско
пирован сегмент полностью (сегментация); возможно также
разделение сегмента на страницы, которые копируются в основ
ную память по отдельности (комбинированная сегментация, или
страничная организация памяти)
7 .1. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПАМЯТЬЮ
7 .1.
401
ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПАМЯТЬЮ
При рассмотрении различных механизмов и стратегий, связанных с управлением па
мятью, полезно помнить требования, которым они должны удовлетворять. Эти требова
ния включают следующее.
•
Перемещение
•
Защита
•
Совместное использование
•
Логическая организация
•
Физическая организация
Перемещение
В многозадачной системе доступная основная память в общем случае разделяется
среди множества процессов. Обычно программист не знает заранее, какие программы
будут резидентно находиться в основной памяти во время работы разрабатываемой им
программы. Кроме того, для максимизации загрузки процессора желательно иметь боль
шой пул процессов, готовых к выполнению, для чего требуется возможность загрузки и
выгрузки активных процессов из основной памяти. Требование, чтобы выгруженная из
памяти программа была вновь загружена в то же самое место, где находилась и ранее,
было бы слишком сильным ограничением. Крайне желательно, чтобы программа могла
быть перемещена
(relocate)
в другую область памяти.
Таким образом, заранее неизвестно, где именно будет размещена программа, а кроме
того, программа может быть перемещена из одной области памяти в другую при свопин
ге. Эти обстоятельства обусловливают наличие определенных технических требований к
адресации, проиллюстрированных на рис.
7.1.
На рисунке представлен образ процесса.
Дпя простоты предположим, что образ процесса занимает одну непрерывную область ос
новной памяти. Очевидно, что операционной системе необходимо знать местоположение
управляющей информации процесса и стека выполнения, а также точки входа для начала
выполнения процесса. Поскольку управлением памятью занимается операционная система
и она же размещает процесс в основной памяти, соответствующие адреса она получает ав
томатически. Однако, помимо получения операционной системой указанной информации,
процесс должен иметь возможность обращаться к памяти в самой программе. Так, коман
ды ветвления содержат адреса, указывающие на команды, которые должны быть выполне
ны после них; команды обращения к данным
-
адреса байтов или слов, с которыми они
работают. Так или иначе, но процессор и программное обеспечение операционной систе
мы должны быть способны перевести ссылки в коде программы в реальные физические
адреса, соответствующие текущему расположению программы в основной памяти.
Защита
Каждый процесс должен быть защищен от нежелательного воздействия других про
цессов, случайного или преднамеренного. Следовательно, код других процессов не дол
жен иметь возможности без разрешения обращаться к памяти данного процесса для чте
ния или записи. Однако удовлетворение требованию перемещаемости усложняет задачу
защиты.
402
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
Управляющая
информация
процесса
Входная точка
~
Управляющий
блок процесса
программы
Команда
Программа
Увеличение
адресов
-
ветвления
1
Ссьшка на
данные
Данные
Текущая
вершина стека
Стек
Рис.
7 .1.
Требования к адресации процесса
Поскольку расположение программы в основной памяти непредсказуемо, проверка
абсолютных адресов во время компиляции невозможна. Кроме того, в большинстве язы
ков программирования возможно динамическое вычисление адресов во время выполне
ния (например, вычисление адреса элемента массива или указателя на поле структуры
данных). Следовательно, во время работы программы необходимо выполнять провер
ку всех обращений к памяти, генерируемых процессом, чтобы удостовериться, что все
они
-
только к памяти, выделенной данному процессу. К счастью, как вы увидите поз
же, механизмы поддержки перемещений обеспечивают и поддержку защиты.
Обычно пользовательский процесс не может получить доступ ни к какой части опе
рационной системы
-
ни к коду, ни к данным. Код одного процесса не может выполнить
команду ветвления, целевой код которой находится в другом процессе. Если не приняты
специальные меры, код одного процесса не может получить доступ к данным другого
процесса. Процессор должен быть способен прервать выполнение таких команд.
Заметим, что требования защиты памяти должны быть удовлетворены на уровне про
цессора (аппаратного обеспечения), а не на уровне операционной системы (програм
много обеспечения), поскольку операционная система не в состоянии предвидеть все
обращения к памяти, которые будут выполнены программой. Даже если бы такое было
возможно, сканирование каждой программы в поиске предлагаемых нарушений защиты
было бы слишком расточительным с точки зрения использования процессорного време
ни. Следовательно, соответствующие возможности аппаратного обеспечения
-
един
ственное средство определения допустимости обращения к памяти (данным или коду)
во время работы программы.
7 .1. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПАМЯТЬЮ
403
Совместное использование
Любой механизм защиты должен иметь достаточную гибкость для тоrо, чтобы обес
печить возможность нескольким процессам обращаться к одной и той же области основ
ной памяти. Например, если несколько процессов выполняют один и тот же машинный
код, то будет выгодно позволить каждому процессу работать с одной и той же копией
этоrо кода, а не создавать собственную. Процессам, сотрудничающим в работе над не
которой задачей, может потребоваться совместный доступ к одним и тем же структурам
данных. Система управления памятью должна, таким образом, обеспечивать управляе
мый доступ к разделяемым областям памяти, при этом никоим образом не ослабляя за
щиrу памяти. Как мы увидим позже, механизмы поддержки перемещений обеспечивают
и поддержку совместного использования памяти.
Логическая организация
Практически всегда основная память в компьютерной системе организована как ли
нейное (одномерное) адресное пространство, состоящее из последовательности байтов
или слов. Аналогично организована и вторичная память на своем физическом уровне.
Хотя такая организация и отражает особенности используемого аппаратноrо обеспече
ния, она не соответствует способу, которым обычно создаются программы. Большинство
программ организованы в виде модулей, одни из которых неизменны (только для чте
ния, только для выполнения), а другие содержат данные, которые могут быть изменены.
Если операционная система и аппаратное обеспечение компьютера могут эффективно
работать с пользовательскими программами и данными, представленными модулями, то
это обеспечивает ряд преимуществ.
1.
Модули могут быть созданы и скомпилированы независимо один от друrого, при
этом все ссылки из одного модуля во второй разрешаются системой во время ра
боты программы.
2.
Разные модули могут получить разные степени защиты (только для чтения, только
для выполнения) за счет весьма умеренных накладных расходов.
3.
Возможно применение механизма, обеспечивающего совместное использование
модулей разными процессами. Основное достоинство обеспечения совместноrо
использования на уровне модулей заключается в том, что они соответствуют взгля
ду программиста на задачу и, следовательно, ему проще определить, требуется ли
совместное использование того или иного модуля.
Инструментом, наилучшим образом удовлетворяющим данным требованиям, являет
ся сегментация, которая будет рассмотрена в данной главе среди прочих методов управ
ления памятью.
Физическая организация
Как указывалось в разделе
1.5,
память компьютера разделяется как минимум на два
уровня: основная и вторичная. Основная память обеспечивает быстрый доступ по отно
сительно высокой цене; кроме того, она энергозависима, т.е. не обеспечивает долговре
менное хранение. Вторичная память медленнее и дешевле основной и обычно энергоне
зависима. Следовательно, вторичная память большой емкости может служить для дол-
404
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
говременного хранения программ и данных, а основная память меньшей емкости
-
для
хранения программ и данных, использующихся в текущий момент.
В такой двухуровневой структуре основной заботой системы становится организа
ция потоков информации между основной и вторичной памятью. Ответственность за
эти потоки может быть возложена и на отдельного программиста, но это непрактично и
нежелательно по следующим причинам.
1.
Основной памяти может быть недостаточно для программы и ее данных. В этом
случае программист вынужден прибегнуть к практике, известной как структуры с
перекрытием
-
оверлеи
(overlay),
когда программа и данные организованы таким
образом, что различные модули могут быть назначены одной и той же области
памяти; основная программа при этом ответственна за перезагрузку модулей при
необходимости. Даже при помощи соответствующего инструментария компиляции
оверлеев разработка таких программ приводит к дополнительным затратам време
ни программиста.
2.
Во многозадачной среде программист при разработке программы не знает, какой
объем памяти будет доступен программе и где эта память будет располагаться.
Таким образом, очевидно, что задача перемещения информации между двумя уровня
ми памяти должна возлагаться на операционную систему. Эта задача является сущнос
тью управления памятью.
РАСПРЕДЕЛЕНИЕ ПАМЯТИ
7 .2.
Главной операцией управления памятью является размещение программы в основ
ной памяти для ее выполнения процессором. Практически во всех современных много
задачных системах эта задача предполагает использование сложной схемы, известной
как виртуальная память. Виртуальная память, в свою очередь, основана на использова
нии одной или обеих базовых технологий
организации памяти
(paging).
-
сегментации (segmentatioп) и страничной
Перед тем как перейти к рассмотрению этих методов ор
ганизации виртуальной памяти, мы должны познакомиться с более простыми методами,
не связанными с виртуальной памятью (табл.
нологий
-
распределение
(partitioning)
7.2).
-
памяти
Одна из приведенных в таблице тех
использовалась в различных вариа
циях в некоторых уже подзабытых к настоящему времени операционных системах. Две
другие технологии
-
простые страничная организация памяти и сегментация
-
сами
по себе не используются, однако их рассмотрение в отрыве от виртуальной памяти уп
ростит дальнейшее понимание предлагаемого материала.
Фиксированное распределение
В большинстве схем управления памятью мы будем полагать, что операционная сис
тема занимает некоторую фиксированную часть основной памяти и что остальная часть
основной памяти доступна для использования многочисленным процессам. Простейшая
схема управления этой доступной памятью
ванными границами.
-
ее распределение на области с фиксиро
7.2.
ТА&ЛИЦА
7.2.
РАСПРЕДЕЛЕНИЕ ПАМЯТИ
405
ТЕХНОЛОГИИ УПРАВЛЕНИЯ ПАМЯТЬЮ
Технология
Описание
Сильные стороны
Слабые сторонь1
Фиксированное
Основная память разде-
Простота реали-
Неэффективное ис-
распределение
ляется на ряд статических
зации, малые сие-
пользование памяти
разделов во время гене-
темные накладные
из-за внутренней
рации системы. Процесс
расходы
может быть загружен в
фрагментации, фиксированное макси-
раздел равного или боль-
мальное количество
шего размера
активных процессов
Динамическое
Разделы создаются дина-
Отсутствует внутрен-
Неэффективное ис-
распределение
мически; каждый процесс
няя фрагментация,
пользование процес-
загружается в раздел стро-
более эффективное
сора из-за необходи-
го необходимого размера
использование ос-
мости уплотнения для
новной памяти
противодействия внешней фрагментации
Простая стра-
Основная память разделе-
Отсутствует внешняя
Наличие небольшой
ничная органи-
на на ряд кадров равного
фрагментация
внутренней фрагмен-
зация
размера. Каждый процесс
тации
разделен на некоторое количество страниц равного
размера и той же длины,
что и кадры. Процесс загружается путем загрузки
всех его страниц в доступ-
ные, но не обязательно
последовательные кадры
Простая
Каждый процесс распре-
Отсутствует внутренняя
Внешняя фрагмен-
сегментация
делен на ряд сегментов.
фрагментация; по срав-
тация
Процесс загружается пу-
нению с динамическим
тем загрузки всех своих
распределением повы-
сегментов в динамические
шенная эффективность
(не обязательно смежные)
использования памяти
разделы
и сниженные накладные расходы
Накладные расходы
Страничная
Все, как при простой стра-
организация
ничной организации, с тем
Нет внешней фрагментации; более вы-
из-за сложности
виртуальной
исключением, что не требу·
сокая степень много-
системы управления
памяти
ется одновременно загру-
задачности; большое
памятью
жать все страницы процесса.
виртуальное адрес-
Необходимые нерезидент-
ное пространство
ные страницы автоматически
загружаются в память
Сегментация
Все, как при простой сег-
виртуальной
ментации, с тем исклю-
Нет внутренней
фрагментации; бо-
из-за сложности
памяти
чением, что не требуется
лее высокая степень
системы управления
одновременно загружать
многозадачности;
памятью
все сегменты процесса.
большое виртуальное
Необходимые нерези-
адресное пространс-
дентные сегменты авто-
тво; поддержка за-
матически загружаются в
щиты и совместного
память
использования
Накладные расходы
406
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
Размеры разделов
На рис.
7.2
показаны два варианта фиксированного распределения. Одна возможность
состоит в использовании разделов одинакового размера. В этом случае любой процесс,
размер которого не превышает размер раздела, может быть загружен в любой досrупный
раздел. Если все разделы заняты и нет ни одного процесса в состоянии готовности или
работы, операционная система может выгрузить процесс из любого раздела и загрузить
другой процесс, обеспечивая тем самым процессор работой.
Операционная
Операционная
система
система
8М
8М
2М
8М
4М
6М
8М
8М
8М
8М
8М
8М
l2M
8М
16М
8М
а) Разделы одинакового размера
Рис.
7.2.
б) Разделы разных размеров
Пример фиксированного распределения 64-мегабайтовой памяти
При использовании разделов с одинаковым размером имеются две трудности.
•
Программа может быть слишком велика для размещения в разделе. В этом случае
программист должен разрабатывать программу, использующую оверлеи, с тем что
бы в любой момент времени ей требовался только один раздел основной памяти.
Когда требуется модуль, который в настоящий момент отсутствует в основной памя
ти, пользовательская программа должна сама загрузить этот модуль в раздел памяти
программы (независимо от того, является ли этот модуль кодом или данными).
7.2. РАСПРЕДЕЛЕНИЕ ПАМЯТИ
•
407
Использование основной памяти при этом крайне неэффективно. Любая програм
ма, независимо от ее размера, занимает раздел целиком. Так, в нашем примере
программа размером менее мегабайта все равно будет занимать целиком раздел
в
8
Мбайт; при этом остаются неиспользованными
7
Мбайт блока. Этот феномен
появления неиспользованной памяти из-за того, что загружаемый блок по размеру
меньше раздела, называется внутренней фрагментацией
(intemal fragmentation).
Бороться с этими трудностями (хотя и не устранить полностью) можно посредством
использования разделов разных размеров (см. рис.
мером
16
7.2, 6).
В этом случае программа раз
Мбайт может обойтись без оверлеев, а разделы малого размера позволяют
уменьшить внутреннюю фрагментацию при загрузке программ малого размера.
Алгоритм размещения
В том случае, когда разделы имеют одинаковый размер, размещение процессов в па
мяти представляет собой тривиальную задачу. Не имеет значения, в каком из свободных
разделов будет размещен процесс. Если все разделы заняты процессами, которые не го
товы к немедленной работе, любой из них может быть выгружен для освобождения па
мяти д;1я нового процесса. Принятие решения о том, какой именно процесс следует вы
грузить,
задача планировщика (об этом мы поговорим в части
-
IV,
"Планирование").
Когда разделы имеют разные размеры, есть два возможных подхода к назначению
процессов разделам памяти. Простейший путь состоит в том, чтобы каждый процесс
размещался в наименьшем разделе, способном полностью вместить данный процесс. 1
В таком случае для каждого раздела требуется очередь планировщика, в которой хра
нятся выгруженные из памяти процессы, предназначенные для данного раздела памяти
(рис.
7.3, а).
Преимущество такого подхода заключается в том, что процессы могут быть
распределены между разделами памяти так, чтобы минимизировать внутреннюю фраг
ментацию.
Хотя этот метод представляется оптимальным с точки зрения отдельного раздела,
он не оптимален с точки зрения системы в целом. Представим, что в системе, изобра
женной на рис.
12
от
до
16
7.2, 6,
в некоторый момент времени нет ни одного процесса размером
Мбайт. В результате раздел размером
16
Мбайт будет пустовать, в то время
как он мог бы с успехом использоваться меньшими процессами. Таким образом, более
предпочтительным подходом является использование одной очереди дЛЯ всех процессов
(см. рис.
7.3, 6).
В момент, когда требуется загрузить процесс в основную память, дЛЯ
этого выбирается наименьший доступный раздел, способный вместить данный процесс.
Если все разделы заняты, следует принять решение об освобождении одного из них. По
видимому, следует отдать предпочтение процессу, занимающему наименьший раздел,
способный вместить загружаемый процесс. Можно учесть и другие факторы, такие как
приоритет процесса или его состояние (заблокирован он или активен).
Использование разделов разного размера по сравнению с использованием разделов
одинакового размера придает дополнительную гибкость данному методу. Кроме того,
схемы с фиксированными разделами относительно просты, предъявляют минимальные
требования к операционной системе; накладные расходы работы процессора невелики.
1
При этом предполагается, что заранее известно, какое максимальное количество памяти может
потребоваться процессу. однако :по далеко не всегда так. Если максимальное количество необходи
мой процессу памяти неизвестно. следует ис1юль·ювать оверлеи или виртуальную память.
408
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
Операционная
Операционная
система
система
Новые
процессы
Рис.
7 .3.
а) Оrдельная очередь процессов
б) Общая очередь для всех
для каждого раздела
процессов
Распределение памяти при фиксированном распределении
Однако у этих схем имеются серьезные недостатки.
•
Количество разделов, определенное в момент генерации системы, ограничивает
количество активных (не приостановленных) процессов.
•
Поскольку размеры разделов устанавливаются заранее, в момент генерации сис
темы, небольшие процессы приводят к неэффективному использованию памяти.
В средах, в которых заранее известны потребности в памяти всех задач, примене
ние описанной схемы может быть оправдано, но в большинстве случаев эффектив
ность этой технологии крайне низка.
Фиксированное распределение в настоящее время практически не используется.
Примером успешной операционной системы с использованием данной технологии может
служить ранняя операционная система IВМ для мейнфреймов OS/МFT (мультипрограммная
с фиксированным количеством задач
-
Multiprograrnming with
а
Fixed number of Tasks).
динамическое распределение
Для преодоления сложностей, связанных с фиксированным распределением, был
разработан альтернативный подход, известный как динамическое распределение. Этот
подход в настоящее время также вытеснен более сложными и эффективными технологи
ями управления памятью. В свое время динамическое распределение использовала опе
рационная система IВМ для мейнфреймов
количеством задач
-
OS/MVT (мультипрограммная
Multiprogramming with а VariaЫe number ofTasks).
с переменным
При динамическом распределении образуется переменное количество разделов пе
ременной длины. При размещении процесса в основной памяти для него выделяется
строго необходимое количество памяти, и не более того. В качестве примера рассмот-
7.2. РАСПРЕДЕЛЕНИЕ ПАМ ЯТИ
рим использование
64
Мбайт основной памяти (рис.
7.4).
409
Изначально вся память пуста,
за исключением области, используемой операционной системой (рис.
7.4,
а). Первые
три процесса загружаются в память, начиная с адреса, которым заканчивается операци
онная система, и используя ровно столько памяти, сколько требуется данному процессу
(рис.
б-г). После этого в конце основной памяти остается "дыра", слишком малая
7.4,
для размещения четвертого процесса. В некоторый момент все процессы в памяти ока
зываются неактивными, и операционная система выгружает второй процесс (рис .
7.4, д),
после которого остается достаточно памяти для загрузки нового, четвертого процесса
(рис. 7.4, е). Поскольку процесс 4 меньше процесса 2, создается еще одна небольшая
"дыра" в памяти. После того как в некоторый момент времени все процессы в памяти
оказываются неактивными, но зато готов к работе процесс
2,
свободного места в памяти
для него не находится, и операционная система вынуждена выгрузить процесс
освободить необходимое место (рис.
(рис .
7.4,
7.4,
ж) и разместить процесс
1,
чтобы
в основной памяти
2
з).
Операционная
система
8М
Операционная
Операционная
Операционная
система
система
система
Процесс
1
20М
56М
1
20М
Процесс
1
20М
Процесс2
14М
Процесс2
14М
ПроцессЗ
18М
Процесс
36М
22М
4М
а)
б)
в)
r)
Операционная
Операционная
Операционная
Операционная
система
система
система
система
Процесс
1
20М
Процесс
1
20М
20М
Процесс2
14М
6М
14М
Процесс4
8М
Процесс4
18М
Процесс З
18М
Процесс З
е)
Рис.
7.4.
18М
ж)
Пример динамического распределения
8М
6М
Процесс З
18М
4М
4М
4М
4М
д)
Процесс4
6М
6М
Процесс З
8М
з)
41 о
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
Как показано в данном примере, этот метод хорошо начинает работу, но плохо про
должает
-
в конечном
счете приводит к наличию множества мелких дыр в
памяти.
Со временем память становится все более и более фрагментированной и снижается эф
фективность ее использования. Это явление называется внешней фрагментацией
ternal fragmentation),
(ex-
что отражает тот факт, что сильно фрагментированной становится
память, внешняя по отношению ко всем разделам (в отличие от рассмотренной ранее
внутренней фрагментации).
Один из методов преодоления этого явления состоит в уплотнении
(compaction):
время от времени операционная система перемещает процессы в памяти так, чтобы они
занимали смежные области памяти; свободная память при этом собирается в один блок.
Например, на рис. 7.4,з после уплотнения памяти мы получим блок свободной памя
ти размером
16
Мбайт, чего может оказаться вполне достаточно для загрузки нового
процесса. Сложность применения уплотнения состоит в том, что при этом расходует
ся дополнительное время; кроме того, уплотнение требует динамического перемещения
процессов в памяти, т.е. должна быть обеспечена возможность перемещения программы
из одной области основной памяти в другую без потери корректности ее обращений к
памяти (см. приложение к данной главе).
Алгоритм размещения
Поскольку уплотнение памяти вызывает дополнительные расходы времени процессо
ра, разработчик операционной системы должен принять разумное решение о том, каким
образом размещать процессы в памяти (образно говоря, каким образом затыкать дыры).
Когда наступает момент загрузки процесса в основную память и имеется несколько бло
ков свободной памяти достаточного размера, операционная система должна принять ре
шение о том, какой именно свободный блок использовать. 2
Можно рассматривать три основных алгоритма
-
наилучший подходящий, первый
подходящий, следующий подходящий. Все они, само собой разумеется, ограничены вы
бором среди свободных блоков размера, достаточно большого для размещения процес
са. Метод наилучшего подходящего выбирает блок, размер которого наиболее близок
к требуемому; метод первого подходящего проверяет все свободные блоки с начала
памяти и выбирает первый достаточный по размеру для размещения процесса. Метод
следующего подходящего работает так же, как и метод первого подходящего, однако
начинает проверку с того места, где был выделен блок в последний раз (по достижении
конца памяти он продолжает работу с ее начала).
На рис.
7.5, а
показан пример конфигурации памяти после ряда размещений и вы
грузки процессов из памяти. Последним использованным блоком был блок размером
22
Мбайт, в котором был создан раздел в
14
Мбайт. На рис.
7.5,6
показано различие в
технологии наилучшего, первого и следующего подходящего при выполнении запроса
на выделение блока размером
16
Мбайт. Метод наилучшего подходящего просматри
вает все свободные блоки и выбирает наиболее близкий по размеру блок в
оставляя фрагмент размером
2
оставляет фрагмент свободной памяти размером
щего
- 20
18
Мбайт,
Мбайт. Метод первого подходящего в данной ситуации
6
Мбайт, а метод следующего подходя
Мбайт.
2 Дополнительный материал 1ю 1ю11росам динамического рас11ределения памяти читатель может
найти в разделе
2.5
ритмы, 3-с изд.
-
(с.
488)
к11и1·и Кнут Д. Э. Искусство програм.wирования. Том/. Основные алго
М.: Издатст.ский лом "Вильяме··.
2000.
-1/римеч. ред.
7.2. РАСПРЕДЕЛЕНИЕ ПАМЯТИ
8М
8М
>-----<
Первый
12М
подходящий
411
>-----<
1 2М
22М
Наилучший
бМ
1-----i
подходящий
Последний
18М
выделенный
блок
2М1====1
(14 Мбайт)
8М
t------i
о
Выделенный блок
бМ
>-----<
о
Свободный блок
о
8М
бМ
Блок, кагорый может
быть выделен
14М
14М
Следующий
подходящий
ЗбМ
20М
б) После выделения
а) До выделения
Рис.
7.5.
Пример конфигурации памяти до и после выделения блока
размером
16
Мбайт
Какой из этих методов окажется наилучшим, будет зависеть от точной последова
тельности загрузки и выгрузки процессов и их размеров. Однако можно говорить о не
которых обобщенных выводах (см.
[ 19], (28], (228]).
Обычно алгоритм первого подходя
щего не только проще, но и быстрее и дает лучшие результаты. Алгоритм следующего
подходящего, как правило, дает немного худшие результаты. Это связано с тем, что алго
ритм следующего подходящего проявляет склонность к более частому выделению памя
ти из свободных блоков в конце памяти. В результате самые большие блоки свободной
памяти (которые обычно располагаются в конце памяти) быстро разбиваются на мень
шие фрагменты и, следовательно, при использовании метода следующего подходящего
уплотнение должновыполняться чаще. С другой стороны, алгоритм первого подходя
щего обычно засоряет начало памяти небольшими свободными блоками, что приводит
к увеличению времени поиска подходящего блока в последующем. Метод наилучшего
подходящего, вопреки своему названию, оказывается, как правило, наихудшим. Так как
он ищет блоки, наиболее близкие по размеру к требуемому, он оставляет после себя
множество очень маленьких блоков. В результате, хотя при каждом выделении впустую
тратится наименьшее возможное количество памяти, основная память очень быстро за
соряется множеством мелких блоков, неспособных удовлетворить ни один запрос (так
что при этом алгоритме уплотнение памяти должно выполняться значительно чаще).
412
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
Алгоритм замещения
В многозадачной системе с использованием динамического распределения наступает
момент, когда все процессы в основной памяти находятся в заблокированном состоянии,
а памяти для дополнительного процесса недостаточно даже после уплотнения. Чтобы
избежать потерь процессорного времени на ожидание деблокирования активного про
цесса, операционная система может выгрузить один из процессов из основной памяти
и, таким образом, освободить место для нового процесса или процесса в состоянии го
товности. Задача операционной системы
определить, какой именно процесс должен
-
быть выгружен из памяти. Поскольку тема алгоритма замещения будет детально рас
сматриваться в связи с различными схемами виртуальной памяти, пока что мы отложим
обсуждение этого вопроса.
Система двойников
Как фиксированное, так и динамическое распределение памяти имеют свои недо
статки. Фиксированное распределение ограничивает количество активных процессов и
неэффективно использует память при несоответствии между размерами разделов и про
цессов. Динамическое распределение реализуется более сложно и включает накладные
расходы по уплотнению памяти. Интересным компромиссом в этом плане является сис
тема двойников
([136], [191]).
В системе двойников память распределяется блоками размером 2к, L ~ К ~ И, где
i· - минимальный размер выделяемого блока памяти;
2u -
наибольший распределяемый блок; вообще говоря, 2u представляет собой
размер всей доступной для распределения памяти.
Вначале все доступное для распределения пространство рассматривается как еди
ный блок размером 2и. При запросе размером s, таким, что 2u-i < s ~ 2 11, выделяется
весь блок. В противном случае блок разделяется на два эквивалентных двойника с раз
мерами 2и- 1 • Если 2и-2 < s ~ 2и- 1 , то по запросу выделяется один из двух двойников;
в противном случае один из двойников вновь делится пополам. Этот процесс продол
жается до тех пор, пока не будет сгенерирован наименьший блок, размер которого не
меньше
s.
Система двойников постоянно ведет список "дыр" (доступных блоков) для
каждого размера 2;. Дыра может быть удалена из списка (i+1} разделением ее пополам
и внесением двух новых дыр размером i в список i. Когда пара двойников в списке i
оказывается освобожденной, они удаляются из списка и обьединяются в единый блок в
списке
(i+ 1).
ром 2i-I < k ~
Ниже приведен рекурсивный алгоритм для удовлетворения запроса разме
i, в котором осуществляется поиск дыры размером i.
void get_hole(int i)
{
if (i
if (<
==
(U+l)) ;
i пуст >)
Список
get_hole (i+l);
<
<
Разделить дыру на двойники
<
Поместить двойники в список
Взять первую дыру из списка
>;
i >;
i >;
На рис.
7.6
7.2. РАСПРЕДЕЛ Е Н И Е ПАМ ЯТИ
413
1
Мбайт.
приведен пример использования блока с начальным размером
Первый запрос А
-
100
на
Кбайт (для него требуется блок размером
этого начальный блок делится на два двойника по
на двойники размером
256
512
128
Кбайт). Дllя
Кбайт. Первый из них делится
Кбайт, и, в свою очередь, первый из получившихся при этом
разделении двойников также делится пополам. Один из получившихся двойников раз
мером 128 Кбайт выделяется запросу А . Следующий запрос В требует 256 Кбайт. Такой
блок имеется в наличии и выделяется . Процесс продолжается с разделением и слиянием
двойников при необходимости. Обратите внимание, что после освобождения блока Е
происходит слияние двойников по
128
Кбайт в один блок размером
256
Кбайт, который,
в свою очередь, тут же сливается со своим двойником.
На рис.
7.7
показано представление системы двойников в виде бинарного дерева,
непосредственно после освобождения блока В. Листья представляют текущее распреде
ление памяти. Если два двойника являются листьями , то по крайней мере один из них
занят; в противном случае они должны слиться в блок большего размера .
Система двойников представляет собой разумный компромисс для преодоления не
достатков схем фиксированного и динамического распределения , но в современных
операционных системах ее превосходит виртуальная память, основанная на страничной
организации и сегментации. Однако система двойников нашла применение в параллель
ных системах как эффективное средство распределения и освобождения параллельных
программ (см" например,
Модифицированная версия системы двойников исполь
[ 118)).
зуется для распределения памяти ядром
UNIX
(подробнее об этом вы узнаете в главе
"Виртуальная память").
Исходный блок
IM
IМбайт
Заnрос 100 Кбайт 1 А= 128К
1
1 28К
256К
512К
Заnрос 240Кбайт 1 А= 128К
1
128К
В= 256К
512К
Заnрос 64 Кбайт 1 А= l 28K
lc= 64кl 64К 1
В = 256К
5 1 2К
Заnрос 256 Кбайт 1 А= l 28K
lc•64KI64К 1
В= 256К
D = 256К
256К
1
256К
D = 256K
256К
ic= 64кl 64К 1
256К
0=256К
256К
Заnрое 75 Кбайт 1 Е = 128К iс · 64к/ 64К /
256К
D=256K
256К
256К
D=256K
256 К
О = 256К
256К
Освобождение В 1 А= 128К lc = 64кl 64К
Освобождение А 1
Освобождение С
1
Освобождение Е
1
128К
Е= 128К
1
128К
5 1 2К
Освобождение О
lM
Рис.
7.6.
Пример системы двойников
8,
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
414
IM
512К
256К
128К
64К
256К
Q
Лист для выделенного
блока
Рис.
7. 7.
Q
256К
D = 256K
Лист для невыделенного
блока
@ Внутренн_ий узел, не
ЯВЛЯЮЩИИСЯ листом
Представление системы двойников в виде бинарного дерева
Перемещение
Перед тем как мы рассмотрим способы, с помощью которых можно избежать недо
статков распределения, следует до конца разобраться в вопросах, связанных с разме
щением процессов в памяти. При использовании фиксированной схемы распределения,
показанной на рис.
7.3,
а, можно ожидать, что процесс всегда будет назначаться одному
и тому же разделу памяти. Это означает, что какой бы раздел ни был выбран для нового
процесса, для размещения этого процесса после выгрузки и последующей загрузки в
память всегда будет использоваться именно этот раздел. В данном случае можно исполь
зовать простейший загрузчик, описанный в приложении к данной главе: при загрузке
процесса все относительные ссылки в коде замещаются абсолютными адресами памяти,
определенными на основе базового адреса загруженного процесса.
Если размеры разделов равны (см. рис.
для разделов разного размера (см. рис.
7.2) и существует единая очередь процессов
7.3, 6), процесс по ходу работы может занимать
разные разделы. При первом создании образа процесса он загружается в некоторый раз
дел памяти; позже, после того как он был выгружен из памяти и вновь загружен, про
цесс может оказаться в другом разделе (не в том, в котором размещался в последний
раз). Та же ситуация возможна и при динамическом распределении. Так, на рис.
и
7.4,
з процесс
2
7.4,
в
занимает при размещении в памяти различные места. Кроме того,
при выполнении уплотнения процессы также перемещаются в основной памяти. Таким
образом, расположение команд и данных, к которым обращается процесс, не является
7.2. РАСПРЕДЕЛЕНИЕ ПАМЯТИ
415
фиксированным и изменяется всякий раз при выгрузке и загрузке (или перемещении)
процесса. Для решения этой проблемы следует различать типы адресов. Логический
адрес представляет собой ссылку на ячейку памяти, не зависящую от текущего располо
жения данных в памяти; перед тем как получить доступ к этой ячейке памяти, необходи
мо транслировать логический адрес в физический. Относительный адрес представляет
собой частный случай логического адреса, когда адрес определяется положением отно
сительно некоторой известной точки (обычно
-
начала программы). Физический адрес
(известный также как абсолютный) представляет собой действительное расположение
интересующей нас ячейки основной памяти.
Программа, которая использует относительные адреса в памяти, загружается с по
мощью динамической загрузки времени выполнения (см. приложение к данной главе).
Обычно все ссылки на память в загруженном процессе даны относительно начала этой
программы. Таким образом, для корректной работы программы требуется аппаратный
механизм, который транслировал бы относительные адреса в физические в процессе вы
полнения команды, которая обращается к памяти.
На рис.
7.8
показан обычно используемый способ трансляции адреса. Когда процесс
переходит в состояние выполнения, в специальный регистр процессора, иногда называ
емый базовым, загружается начальный адрес процесса в основной памяти. Кроме того,
используется "граничный"
(bounds)
регистр, в котором содержится адрес последней
ячейки памяти программы. Эти значения заносятся в регистры при загрузке программы
в основную память.
Относительный адрес
Базовый регистр
---------- --------------
~
Управляющий
блок процесса
Программа
Сумматор
Абсолютный
адрес
Граничный регистрf---__,~ Компаратор
1
1
1
1
1
,____ _
t
у
Прерывание операционнои
.....
Данные
системы
Стек
Образ процесса в
основной памяти
Рис.
7.8.
Аппаратная поддержка перемещения
416
ГЛАВА 7. УПРАВЛЕНИЕ ПАМЯТЬЮ
При выполнении процесса встречающиеся в командах относительные адреса обра
батываются процессором в два этапа. Сначала к относительному адресу прибавляется
значение базового регистра для получения абсолютного адреса. Затем полученный аб
солютный адрес сравнивается со значением в граничном регистре. Если полученный
абсолютный адрес принадлежит данному процессу, команда может быть выполнена; в
противном случае генерируется соответствующее данной ошибке прерывание операци
онной системы.
Схема, представленная на рис.
7.8,
обеспечивает возможность выгрузки и загрузки
программ в основную память в процессе их выполнения; кроме того, образ каждого
процесса ограничен адресами, содержащимися в базовом и граничном регистрах, и, та
ким образом, защищен от нежелательного досrупа со стороны других процессов.
7 .3.
СТРАНИЧНАЯ ОРГАНИЗАЦИЯ ПАМЯТИ
Как разделы с разными фиксированными размерами, так и разделы переменного
размера недостаточно эффективно используют память. Результатом работы первых ста
новится внутренняя фрагментация, результатом работы последних
-
внешняя. Пред
положим, однако, что основная память разделена на одинаковые блоки относительно
небольшого фиксированного размера. Тогда блоки процесса, известные как страницы
(pages),
могут быть связаны со свободными блоками памяти, известными как кадры
(Пames) или фреймы. Каждый кадр может содержать одну страницу данных. При такой
организации памяти, о которой вы узнаете из этого раздела, внешняя фрагментация от
сутствует вовсе, а потери из-за внутренней фрагментации ограничены частью последней
страницы процесса.
На рис.
7.9
показано использование страниц и кадров. В любой момент времени не
которые из кадров памяти используются, а некоторые свободны. Операционная система
поддерживает список свободных кадров. Процесс А, хранящийся на диске, состоит из
четырех страниц. Когда приходит время загрузить этот процесс в память, операционная
система находит четыре свободных кадра и загружает страницы процесса А в эти кадры
(рис.
7.9, 6).
Затем загружаются процесс В, состоящий из трех страниц, и процесс С, со
стоящий из четырех страниц. После этого процесс В приостанавливается и выгружается
из основной памяти. Позже насrупает момент, когда все процессы в памяти оказываются
заблокированными, и операционная система загружает в память новый процесс
D,
со
стоящий из пяти страниц.
Теперь предположим, что, как в только что рассмотренном выше примере, не име
ется одной непрерывной области кадров, достаточной для размещения процесса цели
ком. Помешает ли это операционной системе загрузить процесс
D?
Нет, поскольку в
этой сиrуации можно воспользоваться концепцией логических адресов. Однако одного
регистра базового адреса в этой сиrуации недостаточно, и для каждого процесса опера
ционная система должна поддерживать таблицу страниц. Таблица страниц указывает
расположение кадров каждой страницы процесса. Внутри программы логический адрес
состоит из номера страницы и смещения внутри нее. Вспомним, что в случае простого
распределения логический адрес представляет собой расположение слова относительно
начала программы, которое процессор транслирует в физический адрес. При страничной
организации преобразование логических адресов в физические также остается задачей
аппаратного уровня, решаемой процессором.
417
7.3. СТ РАНИЧНАЯ ОРГАНИЗАЦИЯ ПАМЯТИ
Номер Основная память
кадра
