Файл: Debian Таненбаум Бос.pdf

ВУЗ: Не указан

Категория: Книга

Дисциплина: Операционные системы

Добавлен: 29.10.2018

Просмотров: 48040

Скачиваний: 190

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

10.8. Android   

921

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

Зависимости процессов

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

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

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

Зависимости процессов оказывают влияние на два ключевых момента: когда процессы 
будут созданы (и созданы компоненты внутри них) и каким будет у процесса пока-
затель важности oom_adj. Следует напомнить, что важность процесса определяется 
наиболее важным из имеющихся в нем компонентов. Его важность определяется также 
наиболее важным из зависящих от него процессов.

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

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

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


background image

922  

 Глава 10. Изучение конкретных примеров: Unix, Linux и Android 

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

Таблица 10.18. Обычное состояние важности процессов

Процесс

Состояние

Важность

system

Основная часть операционной системы

SYSTEM (системный)

phone

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

PERSISTENT (постоянно при-
сутствующий)

email

Текущее приложение первого плана

FOREGROUND (первого 
плана)

camera

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

FOREGROUND (первого 
плана)

music

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

PERCEPTIBLE (воспринима-
емый)

media

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

PERCEPTIBLE (воспринима-
емый)

download

Загружает файл для пользователя

SERVICE (служба)

launcher

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

HOME (главный)

maps

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

CACHED (кэшированный)

Рассмотрим, что получится, если состояние, показанное в табл. 10.18, изменится таким 
образом, что почтовое приложение завершит загрузку прикрепления и перестанет ис-
пользовать поставщика контента камеры. В табл. 10.19 показано, как изменится состоя-
ние процесса. Заметим, что приложение камеры больше не нужно, поэтому оно выведено 
из разряда первостепенной важности и переведено на уровень кэшированного прило-
жения. Кэширование приложения камеры также выталкивает старое приложение maps 
на строчку ниже в кэшированном списке наиболее редко используемых приложений.

Таблица 10.19. Состояние процессов после того, как почтовое приложение переста-
ло использовать камеру

Процесс

Состояние

Важность

system

Основная часть операционной системы

SYSTEM (системный)

phone

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

PERSISTENT (постоянно при-
сутствующий)

email

Текущее приложение первого плана

FOREGROUND (первого плана)

music

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

PERCEPTIBLE (воспринимае-
мый)

media

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

PERCEPTIBLE (воспринимае-
мый)

download

Загружает файл для пользователя

SERVICE (служба)

launcher

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

HOME (главный)


background image

10.9. Краткие выводы   

923

Процесс

Состояние

Важность

camera

Ранее использованное почтовым приложением

CACHED (кэшированный)

maps

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

CACHED+1 (кэшированный + 1)

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

10.9. Краткие выводы

Операционная система Linux начала свое существование как полный клон (с открытым 
кодом) системы UNIX, и теперь она используется на различных машинах (от ноутбуков 
до суперкомпьютеров). Она имеет три основных интерфейса: оболочку, библиотеку 
языка C и сами системные вызовы. Для упрощения взаимодействия пользователя с си-
стемой часто используется графический интерфейс пользователя. Оболочка позволяет 
пользователям вводить команды и исполнять их. Это могут быть простые команды, 
конвейеры или более сложные структуры. Ввод и вывод могут перенаправляться. 
В библиотеке языка C содержатся системные вызовы, а также множество расширенных 
вызовов (например, printf для записи форматированного вывода в файлы). Реальный 
интерфейс системных вызовов зависит от архитектуры и на платформах х86 состоит 
приблизительно из 250 вызовов, каждый из которых выполняет только необходимые 
функции и ничего более.

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

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


background image

924  

 Глава 10. Изучение конкретных примеров: Unix, Linux и Android 

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

Файловая система иерархическая, с файлами и каталогами. Все диски монтируются 
в единое дерево каталогов, начинающееся в едином корне. Отдельные файлы могут 
быть связаны с любым каталогом файловой системы. Чтобы пользоваться файлом, 
его нужно сначала открыть, при этом выдается дескриптор файла, который затем 
используется при чтении этого файла и записи в него. Внутри файловая система ис-
пользует три основные таблицы: таблицу дескрипторов файлов, таблицу описания 
открытых файлов и таблицу i-узлов. Таблица i-узлов является наиболее важной из 
этих таблиц. В ней содержится вся административная информация о файле и место-
положении его блоков.

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

Операционная система Android является платформой, позволяющей приложениям вы-
полняться на мобильных устройствах. Она основана на ядре Linux, но состоит из боль-
шой программной надстройки над Linux и небольшого количества изменений в ядре 
Linux. Основная часть Android написана на языке Java. Приложения также написаны 
на Java, затем транслированы в байт-код Java, а затем в байт-код Dalvik. Приложения 
Android обмениваются данными в виде передачи защищенных сообщений, называемых 
транзакциями. Обменом данных между процессами (interprocess-communication (IPC)) 
управляет специализированная модель Linux-ядра, названная Binder.

Пакеты Android обладают автономностью и имеют манифест, описывающий содер-
жимое пакета. Пакеты включают в себя активные части, получатели, поставщики 
контента и намерения. Модель безопасности Android отличается от той, что исполь-
зуется в Linux, и аккуратно помещает каждое приложение в песочницы, потому что 
рассматривает все приложения как не заслуживающие доверия.

Вопросы

1.  Объясните, как тот факт, что UNIX написана на языке C, упрощает ее перенос на 

новые машины.

2.  POSIX-интерфейс определяет набор библиотечных процедур. Объясните, поче-

му в POSIX были стандартизированы библиотечные процедуры, а не интерфейс 
системных вызовов.

3.  При переносе на новые архитертуры Linux зависит от компилятора gcc. Назовите 

одно из преимуществ и один из недостатков такой зависимости.

4.  Каталог содержит следующие файлы:


background image

Вопросы  

925

aardvark

feret

koala

porpoise

unicorn

bonefish

grunion

llama

quacker

vicuna

capybara

hyena

marmot

rabbit

weasel

dingo

ibex

nuthatch

seahorse

yak

emu

jellyfish

ostrich

tuna

zebu

Какие файлы будут перечислены командой

    ls [abc]*e*?

5.  Что делает следующий конвейер оболочки Linux?

    grep nd xyz | wc -l

6.  Напишите конвейер Linux, печатающий восьмую строку файла 

z

 в стандартный 

вывод.

7.  Зачем в операционной системе Linux проводится различие между стандартным 

выводом и стандартным потоком ошибок, если по умолчанию обоим соответствует 
терминал?

8.  Пользователь вводит с терминала следующие команды:

    a | b | c&
    d | e | f&

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

9.  Когда оболочка Linux запускает новый процесс, она помещает копии своих пере-

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

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

процесс при следующих условиях: размер текста — 100 Кбайт, размер данных — 
20 Кбайт, размер стека — 10 Кбайт, размер структуры задачи — 1 Кбайт, размер 
структуры пользователя — 5 Кбайт. Обработка эмулированного прерывания ядром 
занимает 1 мс, а компьютер может копировать 32-разрядное слово каждые 50 нс. 
Текстовые сегменты используются совместно, а сегменты данных и стека — нет.

11. По 

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

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

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

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

13.  Linux-процессы, не являющиеся процессами реального времени, имеют уровень 

приоритета от 100 до 139. Каков исходный статический приоритет и как для его 
изменения используется значение nice?