Архитектура памяти, используемая операционной системой,
Архитектура памяти, используемая операционной системой, — ключ к пониманию того, что в ней происходит. Не имея представления о ней, невозможно ответить на такие вопросы:
Как повысить эффективность приложения?
Как создать данные, разделяемые двумя приложениями?
Где хранятся системные переменные окружения?
Как известно, объем адресуемой памяти определяется размером регистра команд, который обычно зависит от длины машинного слова. Во времена, когда эта длина была равна 16 битам, можно было без особых ухищрений обратиться к любому байту из диапазона (0, 216-1), или 65536 = 64 Кбайт. Обращение к адресам памяти вне этого диапазона стоило определенных усилий.
Затем, как вы помните, длина регистра команд стала равной 20 битам и появилась возможность адресовать память в диапазоне (0, 220-1) или 1 048 576 = 1 Мбайт. Правда из-за того, что длина машинного слова оставалась равной 16 битам, приходилось иметь дело с сегментами памяти по 64 Кбайт, базой, смещением, сдвигами и т. д.
Теперь, когда наконец длина машинного слова и регистра команд стали равными 32 битам, мы можем свободно адресовать любой байт из диапазона (0, 232-1), или 4 294 967 296 = 4 Гбайт. Так как реально мы не имеем такого объема памяти, то нам предлагают научиться жить в виртуальном мире, а точнее, адресном пространстве Windows. В этом мире, как вы знаете, каждый процесс получает свое адресное пространство объемом 4 Гбайт. Корпорация Microsoft обеспечивает эту, реально не существующую, память с помощью механизма подкачки страниц памяти (page swapping), который позволяет использовать часть жесткого диска для имитации оперативной памяти. Конечно, процессор способен работать лишь с настоящей памятью типа RAM, которой ровно столько, сколько вы купили и установили, но вы можете разрабатывать приложения, не задумываясь об этом ограничении, и считать, что каждый процесс обладает пространством в 4 Гбайт. Как только в программе происходит обращение к адресу памяти, который выше реально доступного, операционная система загружает (подкачивает) недостающие данные с жесткого диска в RAM и работает с ними обычным способом.
В MS-DOS и 16- битной Windows все процессы располагаются в едином адресном пространстве, и поэтому любой процесс может считывать и записывать любой участок памяти, в том числе и принадлежащий другому процессу или операционной системе. В таком мире состояние процесса и его благополучие зависят от поведения других процессов. В Win32 память, отведенная другим процессам, скрыта от текущего потока и недоступна ему. В Windows NT/2000 память самой ОС скрыта от любого выполняемого потока. В Windows 95 последнее свойство не реализовано, поэтому в ней текущий поток может испортить память, принадлежащую ОС.
Итак, адресное пространство процесса — это его частная собственность, которая неприкосновенна/Поэтому первичные потоки всех процессов, одновременно существующих в физической памяти, загружаются с одного и того же адреса. В Windows NT/2000 — это 0x00400000 (4 Мбайт). Такое возможно только в виртуальном мире, в котором реальные адреса физической памяти не совпадают с виртуальными адресами в пространстве процесса. Как система отображает виртуальные адреса в реальные? Оказывается, что Windows 95 делает это не так, как Windows NT/2000. Мы будем рассматривать только последний случай, так как первый хоть и отличается от него, но эти отличия могут заинтересовать лишь ограниченный контингент разработчиков, ориентированных на разработку приложений только для Windows 95.
Критические секции Это самые простые
i = 0; i<m_nTotalCallers; i++)
{
//=== Предварительные установки и создание потоков
CCaller * pCaller = new CCaller(Лпараметры*/);
BOOL bRc = pCaller->CreateThread();
}
//======= Блокировка
CSingleLock lock (Sm_CallersReadyEvent) ;
//======= Попытка дождаться события
if (lock.Lock(WAIT_VERY_LONG_TIME))
{
for (i=0; i<m_nTotalCallers; i++)
{
//===== Совершение соединений (звонков)
)
lock.Unlock();
}
else // Отказ ждать
{
//====== Обработка исключения
}
Класс CEvent представляет функциональность синхронизирующего объект ядра (события). Он позволяет одному потоку уведомить (notify) другой поток о том, что произошло событие, которое тот поток, возможно, ждал. Например, поток, копирующий данные в архив, должен быть уведомлен о том, что поступили новые данные. Использование объекта класса CEvent позволяет справиться с этой задачей максимально быстро.
Существуют два типа объектов: ручной (manual) и автоматический (automatic). Ручной объект начинает сигнализировать, когда будет вызван метод SetEvent. Вызов ResetEvent переводит его в противоположное состояние. Автоматический объект класса CEvent не нуждается в сбросе. Он сам переходит в состояние nonsignaled, и охраняемый код при этом недоступен, когда хотя бы один поток был уведомлен о наступлении события. Объект «событие» (CEvent) тоже используется совместно с объектом блокировка (CSingleLock или CMultiLock).
Семафоры
Семафором называется объект ядра, который позволяет только одному процессу или одному потоку процесса обратиться к критической секции — блоку кодов, осуществляющему доступ к объекту. Серверы баз данных используют их для защиты разделяемых данных. Классический семафор был создан Dijkstra, который описал его в виде объекта, который обеспечивает выполнение двух операций Р и V. Первая литера является сокращением голландского слова Proberen, что означает тестирование, вторая — обозначает глагол Verhogen, что означает приращивать (increment). Первая операция дает доступ к ресурсу, вторая — запрещает доступ и увеличивает счетчик объектов, его ожидающих. Различают
два основных использования семафоров: защита критической секции и обеспечение совместного доступа к ресурсу.
В качестве примера может служить критическая секция в виде функции, осуществляющей доступ к таблице базы данных.. Другим примером может служить реализация списка операционной системы, который называется process control blocks (PCBs). Это список указателей на активные процессы. В каждый конкретный момент времени только один поток ядра системы может изменять этот список, иначе будет нарушена семантика его использования.
Семафор может быть использован также для управления перемещением данных (data flow) между п производителями и m потребителями. Существует много систем, имеющих архитектуру типа data flow. В них выход одного блока функциональной схемы целиком поступает на вход другого блока. Когда потребители хотят получить данные, они выполняют операцию типа Р. Когда производители создают данные, они выполняют операцию типа V.
Традиционно семафоры создавались как глобальные структуры, совместно с глобальными API-функциями, реализующими операции Р и V. Теперь семафоры реализуются в виде класса объектов. Обычно абстрактный класс Семафор определяет чисто виртуальные функции типа Р и V. От него производятся классы, реализующие два указанных типа семафоров: защита критической секции и обеспечение совместного доступа к ресурсу. В смысле видимости оба типа семафоров могут быть объявлены либо глобально во всей операционной системе, либо глобально в пространстве процесса. Первые видны всем процессам системы и, следовательно, могут ими управлять. Вторые действуют только в пространстве одного процесса и, следовательно, могут управлять его потоками.
Сам семафор ничего не знает о том, что он защищает. Ему обычно передается ссылка на объект класса, который хочет использовать критическую секцию, и он либо дает доступ к объекту, либо подвешивает (suspends) объект до тех пор, пока доступ не станет возможным. Важно отметить, что при реализации семафоров и других объектов ядра используют специальные атомарные команды (atomic steps), которые не прерываются системой.
Блокировки (Locks)
Блокировки — это семафоры, которые приспособлены для двух операций транзакции (commit и abort). Они используются для обеспечения последовательного доступа конкурирующих потоков или процессов к критическим секциям. Обычно в базах данных блокируется некоторое множество данных (range of items), так как блокировка одного элемента более накладна. Представьте такой запрос:
Select * from Customer where country = Russia and city = "Moscow";
Чтобы защитить данные от рассмотренных выше неприятностей, надо заблокировать все строки таблицы, которые удовлетворяют указанному критерию поиска. Такой способ защиты, оказывается, обладает побочным эффектом. Он может породить запись-призрак (phantom). Допустим, что в это же время другой поток процесса добавляет в ту же таблицу Customer (Клиент) новую запись и ее поля удовлетворяют тому же критерию (клиент из Мосвы). Она, конечно же, будет добавлена в таблицу, но для первого потока она является фантомом (не существует).
Специальные блокировки
Для того чтобы записи-фантомы не создавались, надо избегать блокирования отдельных записей. Альтернативой является блокировка всей таблицы. Но это решение приводит к снижению эффективности работы СУБД. Другим выходом является предикатная блокировка (predicate locking). Предикат мы определили в уроке, посвященном библиотеке шаблонов STL. Это функция, которая может принимать только два значения (false, true} или {0,1}. В нашем примере такая блокировка запомнит не только записи, которые существуют в таблице и удовлетворяют критерию, но и все несуществующие записи такого типа, то есть блокируется весь тип записей заданного типа. Поэтому второй поток процесса найдет таблицу закрытой и будет вынужден ждать окончания работы первого.
Предикатные блокировки хороши, но достаточно накладны. Еще одной альтернативой являются прецизионные блокировки (precision locking). Они не закрывают доступ к записям, но обнаруживают конфликты, когда транзакция пытается прочесть или сохранить записи. Прецизионные блокировки более просты в реализации, но создают повышенный риск тупиковых ситуаций (deadlocks).
До сих пор мы говорили о блокировках, которые имеют одинаковую гранулярность, то есть размер единицы блокируемых данных: таблица, запись или поле. Обычно запрос хочет иметь доступ ко всей таблице, в то время как изменения вносятся только в отдельные записи или даже только в отдельные поля записи. Разработчики механизмов синхронизации ищут оптимум между двумя взаимно противоположными устремлениями: обеспечить максимальную защиту и использовать минимальное число блокировок.
Гранулярные блокировки ограничивают транзакции небольшим множеством определенных предикатов, которые образуют дерево. В корне дерева обычно находится предикат, который разрешает или запрещает доступ ко всей базе данных. На следующем уровне может быть предикат, возвращающий доступ к определенному сайту (site) распределенной базы данных. Следующий уровень связан с таблицей и т. д. вплоть до домена или поля. Блокировки, определенные предикатом какого-то уровня, блокируют все объекты, описываемые предикатом следующего уровня. Это свойство принадлежит всем деревьям. В связи с чем может возникнуть новая проблема. Допустим, что одна транзакция заблокировала базу на уровне записи, а другая в это же время блокирует базу на уровне таблицы. При этом первый поток не может ничего сделать, и вынужден ждать, а второй споткнется при попытке изменить запись, блокированную первой. Опять имеем deadlock.
Это привело к разработке нового, более изощренного типа блокировок — целевые блокировки (intention locks). Их идея состоит в том, что при блокировке обозначается ее цель. Например, блокировка таблицы сообщает, что ее целью являются изменения на уровне записей. В этом случае устраняется возможность тупиковой ситуации рассмотренного выше типа. Например, для установки разделяемой блокировки (share lock) на уровне записей транзакция должна сначала установить целевые блокировки (intention locks) на всех уровнях, которые расположены ниже или выше, в зависимости от интерпретации дерева, то есть на уровне таблицы, на уровне базы данных или сайта, если база является распределенной. После этого можно произвести запрос на становку блокировки типа share-lock на уровне записей.
Устранение тупиковых ситуаций
Единственным способом выхода из тупиковой ситуации (deadlock) является снятие блокировки одним из потоков. Это означает прерывание или отказ от транзакции. Система может либо предупреждать захваты либо допускать их, но затем соответствующим образом обрабатывать. Оказалось, что стандартные протоколы работы с базами данных достаточно редко приводят к образованию захватов, поэтому было признано целесообразным допускать появление захватов при условии, что разработаны механизмы их обнаружения. Особую проблему составляет обнаружение захватов в распределенных базах данных, так как нет простого способа, с помощью которого один узел сети может узнать, какие блокировки наложены в данный момент другим узлом.
Два технических приема используются для обнаружения тупиковой ситуации. Первый — это установка таймера перед совершением транзакции. Если время для ее совершения вышло, то транзакция прерывается, блокировка снимается, что дает возможность другому потоку или процессу закончить свою операцию. Это решение очень просто реализовать, но его недостатком является то, что врожденно медленные транзакции могут потерять шанс быть выполненными. Другим методом является создание специальной структуры данных, которая моделирует граф ожиданий (waits-for graph) — бинарное отношение ожидания между транзакциями. Узлами графа являются транзакции, а дугами — факты ожидания. Так, например, дуга (i, j) (из узла i в узел j) существует, если транзакция i ожидает освобождения блокировки, наложенной транзакцией j. Очевидно, что тупиковой ситуации в этой модели соответствует цикл. Отметьте, что" длина цикла (количество его дуг) может быть более двух.
Алгоритмы обнаружения циклов в графах давно разработаны. Графы обычно хранятся в виде динамических списков, то есть каждый узел хранит список блокировок — указателей на транзакции, которые ему мешают. Сам список обычно защищен семафором. С целью экономии времени процессора детектор циклов включается лишь при необходимости или периодически. Цикл считается обнаруженным, если в списке транзакций, которые тормозят данную, присутствует транзакция, в списке которой есть указатель на исходную. Эту фразу, вероятно, придется прочесть несколько раз.
Отметим, что библиотека классов MFC поддерживает механизмы синхронизации, но детали их реализации скрыты от разработчика. Тем не менее он может использовать их, не заботясь о деталях реализации. Главным требованием при этом, как и при работе с любыми другими объектами классов MFC, является соблюдение протокола, описанного в интерфейсе класса.
К сожалению, время, отведенное для написания книги, закончилось и мне не удастся привести и описать примеры приложений, иллюстрирующих использование синхронизирующих объектов ядра Windows, хотя такие примеры разработаны и достаточно давно используются в вышеупомянутом учебном центре.
Многозадачные операционные системы
Переключение потоков в системе с вытесняющей многозадачностью
Некоторые сведения об архитектуре Windows
Windows 2000 — многозадачная операционная система
Уровни и платформы
Однозадачные и многозадачные ОС
Процессы и потоки
Архитектура памяти Win32
Подсистемы ОС и их взаимодействие
Разделяемые ресурсы
Механизмы синхронизации
Переключение потоков Планировщик
Вытеснение потока с более низким приоритетом
Плакировщик изменяет класс процесса, связанного с этим окном, так чтобы он был больше или равен классу любого процесса, связанного с background-окном. Класс приоритета вновь восстанавливается при потере процессом статуса foreground. Отметьте, что в Windows NT/2000 пользователь может управлять величиной ускорения всех процессов класса NORMAL_PRIORITY с помощью панели управления (команда System, вкладка Performance, ползунок Boost Application Performance).
Когда окно получает сообщение типа WM_TIMER, WM_LBUTTONDOWN или WM_KEYDOWN, планировщик также ускоряет (boosts) ноток, владеющий этим окном. Существуют еще ситуации, когда планировщик временно повышает уровень приоритета потока. Довольно часто потоки ожидают возможности обратиться к диску. Когда диск освобождается, блокированный поток просыпается и в этот момент система повышает его уровень приоритета. После ускорения потока планировщик постепенно снижает уровень приоритета до базового значения. Уровень снижается на одну единицу после завершения очередного кванта времени. Иногда система инвертирует приоритеты, чтобы разрешить конфликты типа deadlock. Благодаря динамике изменения приоритетов потоки активного процесса вытесняют потоки фонового процесса, а потоки с низким приоритетом все-таки имеют шанс получить управление.
Представьте такую ситуацию: поток 1 с высоким приоритетом вынужден ждать, пока поток 2 с низким приоритетом выполняет код в критической секции. В это же время готов к выполнению поток 3 со средним значением приоритета. Он получает время процессора, а два других потока застревают на неопределенное время, так как поток 2 не в состоянии вытеснить поток 3, а поток 1 помнит, что надо ждать, когда поток 2 выйдет из критической секции. Отметьте, что планировщик не способен провести анализ подобной ситуации и решить проблему. Он видит ситуацию только в свете существования двух готовых (ready) потоков с разными приоритетами.
Windows NT/ 2000 разрешает эту ситуацию так. Планировщик увеличивает приоритеты готовых потоков на величину, выбранную случайным образом. В нашем примере это приводит к тому, что поток с низким приоритетом получает шанс на время процессора и, в течение, может быть, нескольких квантов закончит выполнение кодов критической секции. Как только это произойдет, поток 1 с высоким приоритетом сразу получит управление и сможет, вытеснив поток 3, начать выполнение кодов критической секции.
Windows 95 разрешит эту ситуацию по-другому. Она определяет факт того, что поток 1 с высоким приоритетом зависит от потока 2 с низким приоритетом, и повышает приоритет второго потока до величины приоритета первого. Это приводит к тому, что поток 3 вытесняется потоком 2 и он, закончив выполнение кодов критической секции, пропускает вперед ждавший поток 1.
В системе Windows NT/2000 программист имеет возможность управлять процессом ускорения потоков с помощью API-функций SetProcessPriorityBoost (все потоки данного процесса) или SetThreadPriorityBoost (данный поток) в пределах, которые обозначены на рис. 12.7. Функции GetProcessPriorityBoost и GetThreadPriorityBoost позволяют выяснить текущее состояние флага.
Рис. 12.7. Диапазон изменения приоритета потока
При наличии нескольких процессоров Windows NT применяет симметричную модель распределения потоков по процессорам (symmetric multiprocessing SMP), Это означает, что любой поток может быть направлен на любой процессор, но программист может ввести некоторые коррективы в эту модель равноправного распределения. Функции SetProcessAffinityMask и SetThreadAffinityMask позволяют указать предпочтения в смысле выбора процессора для всех потоков процесса или для одного определенного потока. Потоковое предпочтение (thread affinity) вынуждает систему выбирать процессоры только из множества, указанного в маске. Существует также возможность для каждого потока указать один предпочтительный процессор. Это делается с помощью функции SetThreadidealProcessor. Это указание служит подсказкой для планировщика заданий, но не гарантирует строгого соблюдения.
Подсистемы ОС
Операционная система Windows NT представляет собой множество отдельных модулей (подсистем), которые разработаны с учетом двух фундаментальных принципов:
модульность, инкапсуляция, скрытие данных, :
некоторые подсистемы функционируют в привилегированном режиме процессора (kernel mode), а остальные в режиме (user mode).
Первый принцип подразумевает, что каждая подсистема отвечает за отдельную функцию всей системы и все другие потоки — другие части ОС или приложения пользователя, общаются с ней с помощью одного и того же хорошо продуманного интерфейса. Реализация принципа делает невозможными какие-то другие способы (back doors) доступа к критическим для функционирования системы структурам данных. Кроме того, такой подход дает возможность легко производить усовершенствование (upgrade) системы, так как подсистемы, удовлетворяющие заранее известному интерфейсу, можно заменять без какого-либо ущерба для системы.
Для оценки важности второго принципа необходимо пояснить суть режимов выполнения команд kernel mode и user mode. В режиме ядра (kernel mode) вся память доступна и все команды выполнимы. Это привилегированный режим по сравнению с режимом user mode, когда система проверяет права доступа потока при каждом его обращении к памяти. Режим выполнения user mode значительно более надежен, но требует дополнительных затрат, которые снижают общую производительность процесса. В литературе режим ядра иногда называют режимом супервизора или режимом Ring(). Степени защиты памяти называют кольцами, а нулевое кольцо обозначает самый привилегированный аппаратный уровень. Вы можете встретить также обозначения PL=0 (Privilege Level) для kernel mode и PL = 3 для user mode. Если операционная система выполняет первый принцип и большинство ее модулей выполняется в режиме user mode, то говорят, что ОС является риге microkemel-системой. Возможны две версии перевода: «имеет чистое микроядро» и «настоящая microkernel-система». Если система удовлетворяет только первому принципу, то ее называют macrokernel OS. Большинство коммерческих ОС не выполняет второй принцип, так как они хотят быть быстрыми. Windows сразу примкнула к сторонникам microkernel OS, так как здесь соображения надежности поставлены на более высокое место.
На рис. 12. 9 приведена схема, иллюстрирующая архитектуру (состав подсистем) Windows NT. Подсистема Win32 Subsystem состоит из пяти модулей:
Window Manager—компонент, который управляет вводом и выводом на экран. Этот модуль имеет и другое имя — User. Он и располагается в библиотеке User32.dll;
Graphics Device Interface (GDI) — библиотека функций и структур, которые реализуют рисование в контексте устройства. Контекст устройства — это логическая структура, не зависящая от физического устройства и позволяющая пользоваться максимальными возможностями и средствами для вывода графики. Вывод в конкретное физическое устройство производится с помощью драйвера устройства. Система при этом преобразовывает и, возможно, искажает информацию с учетом ограничений, характерных для конкретного устройства. Поэтому реальная картина может отличаться от идеальной, созданной в контексте устройства. Различают шесть инструментов GDI, с помощью которых осуществляется рисование: Pen, Brush, Font, Bitmap, Palette и Region;
Graphics Device Drivers (GDD) — аппаратно-зависимые драйверы, которые осуществляют связь с конкретными физическими устройствами ввода и вывода;
Console — компонент, который поддерживает текстовый режим вывода в окно;
Operating System Functions — функции, которые поддерживают все другие компоненты подсистемы Win32.
Рис. 12.9. Архитектура Windows
Каждый компонент расположен в отдельном DLL-файле. Все они выполнялись в режиме user mode. Однако теперь (в NT 4.0) большинство подсистем выполняется в режиме kernel mode. При этом утверждается, что при переносе блоков из области user mode в область kernel mode надежность системы не снижается благодаря особым усилиям компании Microsoft, которая проявляет особую осторожность при создании такой части ОС, как GDD (Graphics Device Olivers).
Разработчики системы утверждают, что Windows NT является удивительно модульной и инкапсулированной системой, то есть слабозависящей от неожиданных изменений ситуации. Например, она не зависит от размера страницы page-файла. При загрузке системы, точнее, выполнении модуля NTDetect.com, который вы можете видеть в корневом каталоге системного диска, она определяет оптимальный размер страницы. Размер зависит от архитектуры процессора, то есть конкретной платформы. Система, например, может переключиться с размера 4К на 16К. При этом она продолжает надежно работать, несмотря на достаточно радикальную перемену в своей архитектуре.
Функции некоторых подсистем: Virtual Memory Manager (Менеджер виртуальной памяти), Process Manager (Менеджер процессов) мы уже пояснили. Process Manager, кроме рассмотренных функций обеспечивает вместе с Virtual Memory Manager и Security Model (Модель защиты) защиту процессов друг от друга. Подсистема Object Manager (Менеджер объектов) создает, управляет и уничтожает объекты Windows NT Executive. Это абстрактные типы данных, используемые для представления таких ресурсов системы, как файлы, директории, разделяемые сегменты памяти, процессы, потоки, глобальное пространство имен и др. Благодаря модульной структуре подсистемы в нее могут быть легко добавлены и другие новые объекты.
I/O Manager (Менеджер ввода-вывода) состоит из серии компонентов, таких как файловая система, сетевой маршрутизатор и сервер, система драйверов устройств, менеджер кэша. Стандартный интерфейс позволяет одинаковым образом общаться с любым драйвером. Здесь в полной мере проявляются преимущества многослойной (multi-layered) архитектуры.
Много слов сказано в литературе и на конференциях про Security Reference Monitor (Монитор обращений к системе безопасности), но эта тема далеко не всем интересна. Почему-то она абсолютно не захватывает и мое воображение, хотя я понимаю, что тема может оказаться жизненно важной для тех, кому есть, что скрывать.
Hardware Abstraction Layer (Аппаратный уровень абстракции) — HAL является изолирующим слоем между программным обеспечением, поставляемым разными производителями, и более высокими абстрактными слоями ОС. Благодаря HAL
различные типы устройств выглядят одинаково с точки зрения системы. При этом убирается необходимость подстройки системы при введении новых устройств. При проектировании HAL была поставлена цель — создать процедуры, которые позволят общаться только с драйвером устройства, чтобы можно было управлять самим устройством в рамках любой платформы.
Процессы и потоки Различают два
Приоритеты потоков
|
Уровень приоритета потока |
Базовый уровень | ||
|
THREAD_PRIORITY_IDLE |
1 | ||
|
THREAD_PRIORITY_LOWEST |
11 | ||
|
THREAD_PRIORITY_8ELOW_NORMAL |
12 | ||
|
THREAD_PRIORITY_NORMAL |
13 | ||
|
THREAD_PRIORITY_ABOVE_NORMAL |
14 | ||
|
THREAD_PRIORITY_HIGHEST |
15 | ||
|
THREAD_PRIORITY_TIME_CRITICAL |
15 |
Разделы адресного пространства
Разделы адресного пространства процесса
Любому Wm,32-nponeccy могут понадобиться объекты ядра Windows, а также ее подсистемы User или GDI. Они расположены в динамически подключаемых библиотеках: Kernel32.dll, User32.dll, Gdi32.dll и Advapi32.dll Эти библиотеки при необходимости подгружаются в верхнюю часть блока, доступного процессу.
Общий объем памяти, который система может предоставить всем одновременно выполняемым процессам, равен сумме физической памяти RAM и свободного пространства па диске, которым может пользоваться специальный страничный файл (paging file). Страницей называется блок памяти (4 Кбайт для платформ х86, MIPS, PowerPC и 8 Кбайт для DEC Alpha), который является дискретным квантом (единицей измерения) при обмене с диском. Виртуальный адрес в пространстве процесса проецируется системой в эту динамическую страничную память с помощью специальной внутренне поддерживаемой структуры данных (page map). Когда система перемещает страницу в страничный файл, она корректирует page тар того процесса, который ее используют. Если системе нужна физическая память RAM, то она перемещает на диск те страницы, которые дольше всего не использовались. Манипуляции с физической памятью никак не затрагивают приложения, которые работают с виртуальными адресами. Они просто не замечают динамики жизни физической памяти.
Функции API для работы с памятью (virtualAlloc и virtualFree) позволяют процессу получить страницы памяти или возвратить их системе. Процесс отведения памяти имеет несколько ступеней, когда блоки памяти постепенно проходят через определенные состояния. Страницы памяти в виртуальном адресном пространстве процесса могут пребывать в одном из трех возможных состояний.
Таблица 12.2. Состояния страниц памяти в виртуальном адресном пространстве процесса
|
Состояние |
Описание | ||
| Free | Страница недоступна, но ее можно либо зарезервировать (reserve) для процесса, либо отдать процессу (committed) | ||
| Reserved | Зарезервированный блок памяти недоступен процессу и не связан с какой-либо физической памятью, но он подготовлен для того, чтобы в любое время быть отданным (committed) процессу. Зарезервированный диапазон адресов не может быть отдан другому потоку этого же процесса. Такой способ работы снижает фрагментарность физической памяти, так как обычно память резервируется для какой-либо динамической структуры с учетом ее будущего роста. | ||
|
Committed |
Отданная страница представляет интересы уже реальной физической памяти как в RAM, так и на диске. Она может иметь различную степень доступа для процесса. (Readonly, ReadWrite и т. д.) |
Память, которую процесс отводит, вызывая функцию virtualAlloc, доступна только этому процессу. Если какая-то DLL в пространстве процесса отводит себе новую память, то она размещается в пространстве процесса, вызвавшего DLL, и недоступна для других процессов, одновременно пользующихся услугами той же DLL. Иногда необходимо создать блок памяти, который был бы общим для нескольких процессов или DLL, используемых несколькими процессами. Для этой цели существует такой объект ядра системы, как файлы, проецируемые в память (file mapping).
Два процесса создают два упомянутых объекта с одним и тем же именем, получают описатель (handle) объекта и работают с ним так, как будто этот объект находится в памяти. На самом деле они работают с одними и теми же страницами физической памяти. Заметьте, что эта память не является глобальной, так как она остается недоступной для других процессов. Кроме того, ей могут соответствовать различные виртуальные адреса в пространствах разных процессов, ее разделяющих. Если процессы намерены записывать в общую память, то во избежание накладок вы должны использовать синхронизирующие объекты ядра Windows (семафоры, мыотексы, события).
Алгоритм работы с динамической памятью процесса довольно сильно отличается от привычного алгоритма работы с динамической памятью области heap в программах на языке C++. Там вы с помощью операции new отводите память определенного размера, работаете с ней и затем освобождаете ее операцией delete. Здесь необходимы более сложные манипуляции:
резервирование диапазона адресов в виртуальном пространстве процесса. Физическая память при этом не выделяется;
отдача (commiting) процессу какого-то количества страниц из предварительно зарезервированного диапазона адресов. При этом процессу становится доступной физическая память, соответствующая виртуальной. Здесь одновременно указывается тип доступа к выделенным страницам (read-write, read-only, или no access). Сравните с обычным способом, который всегда выделяет страницы С доступом read-write;
освобождение диапазона зарезервированных страниц;
освобождение диапазона отданных страниц. Здесь освобождается физическая память.
Кроме того, возможна операция блокирования страниц памяти в RAM, которая запрещает системе перемещать их в страничный файл подкачки (paging file). Есть функция, позволяющая определить текущее состояние диапазона страниц и изменить тип доступа к ним.
Транзакции В системе с преимущественной
Существует несколько стратегий, которые могут применяться, чтобы разрешать описанные проблемы. Наиболее распространенным способом является синхронизация потоков. Суть синхронизации состоит в том, чтобы вынудить один поток ждать, пока другой не закончит какую-то определенную заранее операцию. Для этой цели существуют специальные синхронизирующие объекты ядра операционной системы Windows. Они исключают возможность одновременного доступа к тем данным, которые с ними связаны. Их реализация зависит от конкретной ситуации и предпочтений программиста, но все они управляют потоками процесса по принципу: «Не все сразу, по одному, ребята».
MFC предоставляет несколько классов, реализующих механизмы синхронизации. Прежде всего отметим, что хорошо спроектированный {thread-safe) класс не должен требовать особых затрат для синхронизации работы с ним. Все делается внутри класса его методами. Обычно при создании надежного класса в него изначально внедряют какой-либо синхронизирующий объект. Например, критическую секцию, событие, семафор, мъютекс или ожидаемый таймер. Иерархию классов MFC для поддержки синхронизирующих объектов можно увидеть в MSDN:
Рис. 12.10. Иерархия классов синхронизации
Все перечисленные классы, кроме критической секции, принадлежат ядру Windows. Вы знаете, что Windows-приложение использует множество и других объектов:
окна, меню, курсоры, значки, клавиатурные ускорители и т.д. (объекты GUI или Graphics User Intrface);
перья, кисти, растровые рисунки, шрифты (объекты GDI Graphics Device Interface).
При работе с объектами этих подсистем надо соблюдать определенные правила. Но при работе с объектами ядра правила особые. Вам следует познакомиться с общими положениями об использовании объектов ядра системы. Они похожи на стандарты СОМ.
Однажды созданный объект ядра можно открыть в любом приложении, если оно имеет соответствующие права доступа к нему.
Каждый объект ядра имеет счетчик числа своих пользователей. Как только он станет равным нулю, система уничтожит объект ядра.
Обращаться к объекту ядра надо через описатель (handle), который система дает при создании объекта.
Каждый объект может находиться в одном из двух состояний: свободном (signaled) и занятом (nonsignaled).
Синхронизация потоков развивается по такому сценарию. При засыпании одного из них операционная система перестает выделять ему кванты процессорного времени, приостанавливая его выполнение. Прежде чем заснуть, поток сообщает системе то особое событие, которое должно разбудить его. Как только указанное событие произойдет, система возобновит выдачу ему квантов процессорного времени и ноток вновь получит право на жизнь. Потоки усыпляют себя до освобождения какого-либо синхронизирующего объекта с помощью двух функций:
DWORD WaitForSingleObject (HANDLE hObject, DWORD dwTimeOut);
DWORD WaitForMultipleObjects(DWORD nCount,
CONST HANDLE* lpHandles, BOOL bWaitAll,
DWORD dwTimeOut);
Первая функция приостанавливает поток до тех пор, пока или заданный параметром hObject синхронизирующий объект не освободится, или пока не истечет интервал времени, задаваемый параметром dwTimeOut. Если указанный объект в течение заданного интервала не перейдет в свободное состояние, то система вновь активизирует поток и он продолжит свое выполнение. В качестве параметра dwTimeOut могут выступать два особых значения:
Таблица 12.3. Значения, выступающие в качестве параметра dwTimeOut
| dwTime | Out Описание |
| 0 | Функция только проверяет состояние объекта (занят или свободен) и сразу же возвращается |
INFINITE |
Время ожидания бесконечно. Если объект так и не освободится, поток останется в неактивном состоянии и никогда не получит процессорного времени |
Таблица 12.4. Возвращение значений функцией WaitForSingleObject
Возвращаемое значение |
Описание |
| WAITJ1MEOUT | Объект не перешел в свободное состояние, но интервал времени истек |
| WAIT_ABANDONED | Ожидаемый объект является мьютексом, который не был освобожден владеющим им потоком перед окончанием этого потока. Объект мьютекс автоматически переводится системой в состояние свободен. Такая ситуация называется «отказ от мьютекса» |
| WAIT_OBJECT_0 | Объект перешел в свободное состояние |
WAIT_FAILED |
Произошла ошибка, причину которой можно узнать, вызвав GetLastError |
освобождение хотя бы одного синхронизирующего объекта из заданного списка;
освобождение всех указанных объектов;
истечение заданного интервала времени.
Уровни и платформы В последнее
Диаграмма взаимодействия ОС с прикладной программой
Системный модуль, который подготавливает запуск прикладной программы, с тем чтобы вернуть управление обратно после ее завершения, называется program prefix segment. Он, так же как и модуль завершения программы пользователя, занимает определенное время и другие ресурсы системы. Если в процессе выполнения пользовательской прбграмме нужно выполнить какое-либо стандартное действие, например вывести строку символов на принтер, она может обратиться к стандартной подпрограмме, входящей в состав операционной системы. Такие стандартные действия, реализованные в ОС в виде отдельных процедур, принято называть системными сервисами. Обратите внимание на тот факт, что прикладная программа сама определяет момент предоставления ей системного сервиса. Программа при завершении, как вы знаете, может вернуть системе некий код (успех или неудача). Как программа может узнать о наступлении какого-либо события, внешнего по отношению к ней, например такого, как нажатие пользователем клавиши клавиатуры? Существуют два способа: по опросу готовности и с помощью механизма аппаратных прерываний. Клавиатура является устройством, о котором можно программно, анализируя содержимое программно-доступного регистра состояния клавиатуры, узнать, готово ли оно к обмену, то есть нажата ли клавиша. Алгоритм процедуры обмена, соответствующий первому способу, изображен на рис. 12.2. Он обладает тем недостатком, что при ожидании процессор используется неэффективно, то есть простаивает. Второй способ иллюстрируется рис. 12.3.
В результате какого-либо события: нажатия клавиши клавиатуры, движения мыши, срабатывания таймера, вырабатывается сигнал. По этому сигналу процессор прерывает выполнение текущей программы, запоминает состояние (контекст) прерванной программы и передает управление программе-обработчику возникшей ситуации.
Рис. 12.2. Алгоритм опроса готовности
Рис. 12.3. Алгоритм обработки аппаратного прерывания
Аппаратные прерывания могут возникать в произвольные моменты времени, и они прозрачны для прикладной программы, то есть она не знает, что была прервана в ответ на какое-то событие. Почему необходимо запоминать контекст прерванной программы и не нужно этого делать при вызове внешней функции? В последнем случае контекст не нарушается, так как программист проектирует вызов функции и сам управляет последовательностью действий, например передачей аргументов. В случае прерывания контекст выполняемой программы нарушается и уже сама система должна сделать все, чтобы восстановить текущее состояние прерванной программы, так как прерывание не было запланировано — не входило в намерения программиста. Теперь рассмотрим, как в случае прерывания прикладная программа узнает о том, что была нажата клавиша и какая (рис. 12.4).
Рис. 12.4. Диаграмма асинхронного взаимодействия
Обработчик аппаратного прерывания от клавиатуры преобразует код нажатия клавиши в код, понятный прикладной программе (ASCII), и помещает его в буфер. Прикладная программа не реагирует на нажатие клавиши и не замечает вызова обработчика, но когда у нее возникает желание выяснить, нажимал ли пользователь какие-нибудь клавиши, она вызывает системную функцию. Последняя анализирует буфер и, если он не пуст, возвращает код нажатой клавиши или признак того, что буфер пуст.
Взаимодействие подсистем Приложения
}
Он должен писать код с учетом того, что файл может быть заблокирован какое-то время другим процессом. Если следовать уже рассмотренной тактике ожидания ресурса в течение какого-то времени, то надо создать код вида:
bool CMyWnd::TryOpen()
<
//====== Попытка открыть файл и внести изменения
CFile file;
CString fn("MyFile.dat"), Buffer;
//===== Флаг первой попытки
static bool bFirst = true;
if (file.Open (fn, CFile:: modeReadWrite I CFile::shareExclusive))
{
// Никакая другая программа не сможет открыть
// этот файл, пока мы с ним работаем
int nBytes = flie.Read(Buffer,MAX_BYTES);
//==== Работаем с данными из строки Buffer
//==== Изменяем их нужным нам образом
//==== Пришло время вновь сохранить данные
file.Write(Buffer, nBytes);
file. Close ();
//==== Начиная с этого момента, файл доступен
//==== для других процессов
//==== Если файл был открыт не с первой попытки,
//==== то выключаем таймер ожидания
if (IbFirst)
KillTimer(WAIT_ID);
//===== Возвращаем флаг успеха
return bFirst = true;
}
//====== Если не удалось открыть файл
else
if (bFirst) // и эта неудача — первая,
//===== то запускаем таймер ожидания
SetTiraer(WAIT_ID, 1000, 0);
//===== Возвращаем флаг неудачи
return bFirst = false;
}
В другой функции, реагирующей на сообщения таймера, называемой, как вы знаете, функцией-обработчиком (Message Handler), надо предусмотреть ветвь для реализации выбранной тактики ожидания:
//====== Обработка сообщений таймера
void CMyWnd::OnTimer(UINT nID)
{
//====== Счетчик попыток
static int iTrial = 0;
//====== Переход по идентификатору таймера
switch (nID)
{
//== Здесь могут быть ветви обработки других таймеров
case WAIT_ID:
//====== Если не удалось открыть
if (ITryOpenO)
{
//===== и запас терпения не иссяк,
if (++iTrial < 10)
return; // то продолжаем ждать
//=== Если иссяк, то сообщаем о полной неудаче
else
{
MessageBox ("Файл занят более 10 секунд",
"Ошибка"); //====== Отказываемся ждать
KillTimer(WAIT_ID);
//====== Обновляем запас терпения
iTrial = 0;
}
}
}
}
Существуют многочисленные варианты рассмотренной проблемы, и в любом случае программист должен решать их, например путем синхронизации доступа к разделяемым ресурсам. Большинство коммерческих систем управления базами данных умеют заботиться о целостности своих данных, но и вы должны обеспечить целостность данных своего приложения. Здесь существуют две крайности: отсутствие защиты или ее слабость и избыток защиты. Вторая крайность может создать низкую эффективность приложения, замедлив его работу так, что им невозможно будет пользоваться. Например, если в примере с повышением зарплаты первый поток заблокирует-таки доступ к записи, но затем начинает вычислять новое значение зарплаты, обратившись к источнику данных о средней (в отрасли) зарплате по всей стране. Такое решение проблемы может привести к ситуации, когда второй поток процесса, который готов корректировать эту же запись, будет вынужден ждать десятки минут.
Одним из более эффективных решений может быть такое: первый поток читает запись, вычисляет прибавку и только после этого блокирует, изменяет и освобождает запись. Такое решение может снизить время блокирования до нескольких миллисекунд. Однако защита данных теперь не сработает в случае, если другой поток поступает также. Второй поток может прочитать запись после того, как ее прочел первый, но до того, как первый начал изменять запись. Как поступить в этом случае? Можно, например, ввести механизм слежения за доступом к записи, и если к записи было обращение в интервале между чтением и модификацией, то отказаться от модификации и повторить всю процедуру вновь.
Windows 2000 — многозадачная операционная система
В тексте этого урока использованы материалы, любезно предоставленные преподавателем СПбГТУ Мариной Полубенцевой, с которой мы совместно ведем курс Visual C++ в Microsoft Certified Educational Center при Санкт-Петербургском государственном техническом университете (www.Avalon.ru).
Разработчики Windows-приложений живут в особом мире событий и сообщений, в котором последовательность выполнения операций не всегда строго предсказуема. Они выработали свое особое представление о том, как правильно ставить и решать задачи в виртуальном мире операционной системы, управляемой событиями. Если вы, читатель, выполнили все шаги по разработке традиционного Windows-приложения, описанные в третьем уроке этой книги, то, вероятно, уже имеете понятие о структуре и принципе функционирования любой Windows-программы. Традиционным называется приложение, созданное на основе функций API (Application Programming Interface) или программируемого интерфейса приложений. API — это подсистема Windows, которая помогает программировать, то есть планировать и создавать, графический интерфейс пользователя. В состав API, как вы знаете, входят не только функции, но и множество структур языка С, сообщений Windows, макросов и интерфейсов.
