Марапулец Ю.В. Основы программирования в Win32API

Подождите немного. Документ загружается.

(LPVOID lpvAddress, // начало блокируемой области

DWORD dwSize, // размер блокируемой области);

BOOL VirtualUnlock

(LPVOID lpvAddress, // начало области, с которой снимается

// блокировка

DWORD dwSize, // размер области, с которой снимается

// блокировка);…

В системе отсутствует счетчик, определяющий, сколько раз блокирова-

лась виртуальная память. Необязательно, чтобы каждой функции VirtualLock()

соответствовала функция VirtualUnlock(). Например, можно заблокировать три

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

менить их блокировку с помощью одной функции. Все три страницы предва-

рительно должны быть заблокированы. Однако диапазон, заданный функцией

VirtualUnlock(), может не совпадать с диапазоном, заданным функцией Vir-

tualLock().

Перед блокировкой память должна быть закреплена. По завершении про-

цесса операционная система автоматически отменяет блокировку всех стра-

ниц, которые остались заблокированными. Функция VirtualFree() освобождает

все страницы, даже заблокированные.

3.3.2. Файлы, проецируемые в память

Как и виртуальная память, проецируемые файлы позволяют резервиро-

вать регион адресного пространства и передавать ему физическую память.

Различие между этими механизмами состоит в том, что в последнем случае

физическая память не выделяется из системного страничного файла, а берется

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

к нему можно обращаться так, как будто он в нее целиком загружен.

Данный механизм может использоваться в следующих случаях [2]:

– для запуска исполняемых файлов (EXE) и динамически связываемых

библиотек (DLL);

– для работы с файлами;

– для одновременного использования одной области данных двумя про-

цессами.

Рассмотрим подробнее каждый из вышеперечисленных механизмов.

Запуск исполняемых файлов и библиотек. Ранее рассматривалась функция

CreateProcess() для запуска процессов. При использовании данной функции

применяется VMM для выполнения следующих действий:

– создание адресного пространства процесса (размером 4 Gb);

– резервирование в адресном пространстве процесса региона размером,

достаточным для размещения исполняемого файла. Начальный адрес региона оп-

ределяется в заголовке EXE-модуля. Обычно он равен 0 × 00 400 000, но может

быть изменен при построении файла параметром /BASE компоновщика;

– отображение исполняемого файла на зарезервированное адресное про-

странство; тем самым VMM распределяет физические страницы не из файла

подкачки, а непосредственно из EXE-модуля;

– отображение на адресное пространство процесса необходимых ему ди-

намически связываемых библиотек. Информация о необходимых библиотеках

находится в заголовке EXE-модуля. Желательное расположение региона адре-

сов описано внутри библиотеки: Visual C++, например, устанавливает по умол-

чанию адрес 0 × 10 000 000. Этот адрес может также изменяться параметром

/BASE компоновщика. Если при загрузке выясняется, что данный регион занят,

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

нове настроечной информации, содержащейся в DLL-модуле. Однако эта опе-

рация снижает эффективность системы, и кроме того, если настроечная инфор-

мация удалена при компоновке библиотеки параметром /FIXED, то загрузка

становится вообще невозможной.

При одновременном запуске нескольких приложений Win32 отображает

один и тот же исполняемый файл и библиотеки на адресные пространства

различных процессов. При этом возникает проблема независимого исполь-

зования процессами статических переменных и областей данных. Кроме то-

го, изменение данных исполняющейся программой не должно приводить к

изменению EXE-файла. Win32 откладывает решение этой проблемы на мак-

симально возможный срок (Lazy Evaluation). При этом используется класси-

ческий механизм отложенного копирования (copy-on-write – копирование

при попытке записи). Все страницы адресного пространства процесса полу-

чают атрибут защиты PAGE_WRITECOPY. При попытке записи в такую

страницу возникает исключение нарушения защиты и VMM копирует стра-

ницу для обратившегося процесса. В дальнейшем эта страница будет выгру-

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

вызвавшей исключение.

Работа с файлами данных, проецируемых в память. Проецирование фай-

ла данных в адресное пространство процесса предоставляет мощный механизм

работы с файлами. Спроецировав файл на адресное пространство процесса,

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

вание файла в память выполняется в три этапа:

1. Создается объект ядра «файл». В прежней терминологии это операция

открытия файла. Для создания объекта «файл» используется функция

CreateFile, аналогичная функции open() из CRT-библиотеки.

2. С помощью функции CreateFileMapping создается объект ядра «про-

ецируемый файл». При этом используется описатель файла (handle), возвра-

щенный функцией CreateFile. Теперь файл готов к проецированию.

3. Производится отображение объекта «проецируемый файл» или его

части на адресное пространство процесса. Для этого применяется функция

MapViewOfFile.

Для открепления файла от адресного пространства процесса используется

функция UnmapViewOfFile(), а для уничтожения объектов «файл» и «проеци-

руемый файл» – функция CloseHandle(). Последовательность кода работы

с проецированными файлами следующая:

HANDLE hFile, hFileMapping;

PVOID pMassive;

hFile = CreateFile(«File Name», ...);

hFileMapping = CreateFileMapping(hFile, ...);

CloseHandle(hFile) ;

pMassive = MapViewOfFile(hFileMapping, ...);

/* Работа с массивом pMassive */

UnmapViewOfFile(pMassive);…

Взаимодействие процессов через общую область данных. Когерентность.

Два процесса могут совместно использовать объект «проецируемый файл».

При этом при помощи функции MapViewOfFile() каждый процесс проецирует

этот объект на свое адресное пространство и использует эту часть адресного

пространства как разделяемую область данных. Общий механизм таков: один

процесс создает объект «проецируемый файл» с помощью функции

CreateFileMapping() и порождает другой процесс, передавая ему в наследство

описатель этого объекта. Дочерний процесс может пользоваться этим описате-

лем наравне с родительским. Проблема состоит только в том, как сообщить

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

ется описателем «проецируемого файла». Это можно сделать любым способом

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

среды, передачей сообщения в главное окно процесса и т. д.).

Общая область данных может быть создана не только путем проецирова-

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

в функцию CreateFileMapping() необходимо передать в качестве параметра не

дескриптор ранее открытого файла, а – 1. В этом случае необходимо задать

размеры выделяемой области. Кроме того, в параметре lpName можно задать

имя объекта, которое является глобальным в системе. Если это имя задается

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

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

стного использования.

Если один процесс меняет разделяемую область данных, то она меняется

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

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

рентности процессы должны работать с одним объектом – «проецируемый

файл», а не с одним файлом.

3.3.3. Функции для работы с динамической областью памяти

Динамическая область памяти, или куча (heap), представляет собой блок

памяти, из которого программа при необходимости выделяет себе более мел-

кие фрагменты. 16-разрядные Windows-программы выделяют память как из

глобальной, так и из локальной динамической области. Последняя работает

быстрее, но ее объем ограничен 64 Кб.

Современные ОС семейства Windows со своим плоским адресным про-

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

а также дальний и ближний, превращая всю память в одну нераздельную ди-

намическую область.

Даже при наличии большого непрерывного адресного пространства ино-

гда целесообразно работать с динамической областью памяти меньшего разме-

ра. Резервирование и закрепление виртуальной памяти имеет очевидные пре-

имущества при работе с большими динамическими или разреженными

структурами. А как быть с алгоритмами, которые предполагают выделение

большого количества мелких блоков памяти? Команды для работы с динами-

ческой областью памяти позволяют создавать в адресном пространстве про-

граммы одну или несколько локальных куч и выделять из них более мелкие

блоки памяти.

Команды для работы с динамической областью памяти удобны тем, что

позволяют сосредоточить выделенные блоки в небольшом диапазоне адресно-

го пространства. Группировка выделенных блоков выполняется по следующим

причинам:

– она позволяет отделить и защитить группу связанных блоков. Про-

грамма, создающая большое количество маленьких блоков одинакового раз-

мера, гораздо эффективнее упаковывает память, если блоки следуют последо-

вательно;

– если все узлы связанного списка находятся в одной куче, а узлы дво-

ичного дерева – в другой, ошибка одного алгоритма в меньшей степени ска-

жется на работе другого алгоритма;

– объекты памяти, работающие совместно, могут быть сгруппированы,

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

одной странице памяти, можно прочитать с помощью одной дисковой операции.

Для получения дескриптора кучи «по умолчанию» используется функция

HANDLE GetProcessHeap(VOID).Используя возвращаемый этой функцией де-

скриптор, можно осуществлять работу с кучей.

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

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

управления виртуальной памятью, – ведь именно так поступает Windows. Для соз-

дания кучи нужно задать ее начальный и максимальный размеры:

HANDLE HeapCreate

(DWORD dwOptions, // флаг выделения кучи

DWORD dwInitialSize, // начальный размер кучи

DWORD dwMaximumSize, // максимальный размер кучи);…

Подсистема Win32 реагирует на эту функцию, резервируя блок памяти

максимального размера и закрепляя страницы, которые определяют начальный

размер кучи. Последующие выделения памяти приводят к увеличению или

уменьшению объема кучи. Если для очередного выделения памяти потребуют-

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

Страницы остаются закрепленными до тех пор, пока куча не будет уничтожена

или пока сама программа не завершится.

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

чу или перемещать объекты внутри нее. Поэтому не исключено, что после

многократного выделения и освобождения большого количества мелких объ-

ектов куча станет фрагментированной. Если при очередном выделении памяти

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

вершаются. Однако если аргумент dwMaximumSize равен 0, размер кучи огра-

ничивается объемом доступной памяти.

Параметр dwOptions позволяет установить один-единственный флаг –

HEAP_NO_SERIALIZE.

По умолчанию без этого флага (значение аргумента

равно 0) куча не допускает взаимодействия посредством потоков, которые

совместно используют дескрипторы памяти. Сериализованная куча препят-

ствует одновременному выполнению нескольких операций с одним дескрип-

тором. Один из потоков блокируется до тех пор, пока другой поток не за-

вершит выполнение своей операции. Сериализация несколько снижает

быстродействие. Если в программе реализован только один поток, если

только один из нескольких потоков программы обращается к куче или если

программа самостоятельно обеспечивает защиту кучи (например, путем соз-

дания исключающего семафора или критического раздела), сериализация

кучи не требуется.

Функции HeapAlloc(), HeapReAlloc() и HeapFree() осуществляют выделе-

ние, повторное выделение и освобождение блоков памяти из кучи. Все эти

функции в качестве одного из аргументов принимают дескриптор, возвращен-

ный функцией HeapCreate():

LPSTR HeapAlloc

(HANDLE hHeap, // дескриптор локальной кучи

DWORD dwFlags, // управляющие флаги

DWORD dwBytes, // количество выделяемых байтов);…

Функция HeapAlloc() возвращает указатель блока необходимого размера.

Ей могут быть переданы два управляющих флага:

HEAP_GENERATE_EXCEPTIONS определяет, как команда будет

обрабатывать ошибки. Если он не установлен, функция HeapAlloc() сооб-

щает об ошибке, возвращая значение NULL.

Если флаг установлен, то в

ответ на любую ошибку функция порождает исключение;

HEAP_ZERO_MEMORY дает функции HeapAlloc() указание инициа-

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

выполнении функция выделяет столько памяти, сколько требуется, или

немного больше, чтобы достичь ближайшей границы страницы.

Чтобы узнать точный размер любого блока, необходимо вызвать функцию

HeapSize(). Наряду с байтами блока при каждом выделении будет задействовано

несколько дополнительных байтов, необходимых для поддержки внутренней

структуры динамической области памяти. Точный размер этого дополнительно-

го кусочка памяти варьируется и составляет в среднем около 16 байтов. Это не-

обходимо знать, потому что без учета подобных «накладных расходов» невоз-

можно выделить из кучи столько блоков, сколько изначально требовалось. Если

создать динамическую область памяти объемом 2 Мб и попытаться выделить из

нее два блока размером по 1 Мб каждый, то второй блок, скорее всего, не будет

выделен.

Изменить размер блока после его выделения позволяет функция Hea-

pReAlloc():

LPSTR HeapReAlloc

(HANDLE, hHeap, // дескриптор локальной кучи

DWORD dwFlags, // флаги, влияющие на перераспределение памяти

LPSTR lpMem, // адрес блока памяти, размер которого изменяется

DWORD dwBytes, // новый размер выделенного блока памяти);…

Кроме двух флагов, которые функция HeapAllос() использовала для обнуле-

ния памяти и для генерации исключений, параметр dwFlags функции

HeapReAlloc() принимает еще один флаг – HEAP_REALLOC_IN_PLACE_ONLY.

(Microsoft заботится о том, чтобы мы все понимали, объединив целых пять слов в

имени одной-единственной константы.) Этот флаг предотвращает перемещение

выделенного блока в более свободную область памяти, выполняемое функцией

HeapReAlloc. Если соседние блоки мешают расширению данного блока до тре-

буемого размера, в результате выполнения функции HeapReAlloc() возникает

ошибка. Флаг HEAP_REALLOC_IN_PLACE_ONLY

обычно применяется в соче-

тании с другими флагами.

Если выделенный блок памяти больше не нужен, освободите его с помо-

щью функции HeapFree(). Если же отсутствует необходимость и в самой куче,

освободите ее посредством функции HeapDestroy():

BOOL HeapFree

(HANDLE hHeap, // дескриптор локальной кучи

DWORD dwFlags, // не используется (должен быть равен нулю)

LPSTR lpMem, // адрес освобождаемого блока памяти);…

BOOL HeapDestroy( HANDLE hHeap);…

Освобождение блока памяти не приводит к отмене закрепления страниц,

которые он занимал, однако это пространство становится доступным для по-

следующих выделений из той же динамической области памяти. Функция

HeapDestroy() освобождает все страницы кучи, независимо от наличия в ней

выделенных блоков. После выполнения функции HeapDestroy() дескриптор

hHeap становится недействительным (неопределенным).

Еще один набор функций предназначен для проверки правильности ука-

зателей (табл. 3.2). Каждая функция из этого набора получает виртуальный ад-

рес и возвращает значение TRUE,

если процесс не имеет определенных приви-

легий доступа.

Таблица 3.2.

Функция Аргумент Вид проверки

IsBadCodePtr() Указатель функции

Проверяет возможность чтения начала

функции

IsBadReadPtr()

Указатель блока

памяти

Проверяет возможность чтения заданного

диапазона адресов

IsBadStringPtr() Указатель строки

Проверяет возможность чтения всех байтов до

конца заданной строки

IsBadWritePtr()

Указатель блока

памяти

Проверяет возможность записи заданного

диапазона адресов

Глава 4. ОРГАНИЗАЦИЯ ВВОДА/ВЫВОДА В ОС WINDOWS

4.1. Асинхронный ввод/вывод

Наиболее простым способом работы с файлами является использование

стандартных операций компиляторов языков – использование функции fopen()

для С/С++, потоковых классов ввода-вывода, класса CFile для программирова-

ния с использованием MFC и т. п. Однако в ОС Windows заложен гораздо бо-

лее мощный механизм работы с файлами, который не используется стандарт-

ными компиляторами – асинхронный ввод/вывод [4].

Асинхронный ввод/вывод – это механизм, позволяющий программе осуще-

ствлять обмен данными с каким-либо устройством ввода/вывода и одновре-

менно с этим выполнять какую-либо другую полезную работу. Например, про-

грамма отдает команду на чтение данных из файла, а затем, не ожидая

завершения чтения данных, приступает к выполнению математических вычис-

лений. Когда данные из файла перемещаются в оперативную память, програм-

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

причем это лишь один из множества возможных сценариев использования

асинхронного ввода/ вывода.

Если вы разрабатываете программу, принимающую данные из нескольких

разных источников, вам также может потребоваться асинхронный ввод/вывод.

Предположим, что вы разрабатываете терминальную программу, которая чи-

тает данные как с клавиатуры, так и из последовательного порта. По мере по-

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

В этой ситуации также чрезвычайно удобно использовать механизмы асин-

хронного ввода/ вывода.

Прежде чем приступать к изучению различных форм асинхронного вво-

да/вывода, следует изучить основы файлового ввода/вывода Windows,

а также базовые методы, используемые этой ОС для обмена данными

с внешними устройствами.

Обычно, если программист хочет открыть файл, он использует один из

стандартных вызовов библиотеки C++ (такой, как, например, fopen). В боль-

шинстве языков программирования предусмотрены достаточно удобные высо-

коуровневые средства работы с файлами. Однако в некоторых ситуациях требу-

ется открыть файл и работать с ним на уровне операционной системы, не

используя высокоуровневые функции. Например, прямое обращение к операци-

онной системе может потребоваться в случае, если вы намерены использовать

асинхронный ввод/вывод.

Системной функцией, с помощью которой осуществляется открытие фай-

ла, называется CreateFile(). В зависимости от флагов, которые программист пе-

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

файл, либо открыть уже существующий. В любом случае вызов CreateFile()

создает дескриптор файла и возвращает его вызвавшей программе, которая

может использовать этот дескриптор для дальнейшей работы с файлом:

HANDLE CreateFile

(LPCTSTR lpFileName,

DWORD dwDesiredAccess,

DWORD dwShareMode,

LPSECURITY_ATTRIBUTES lpSecurityAttributes,

DWORD dwCreationDispostion,

DWORD dwFlagsAndAttributes,

HANDLE hTemplateFile);…

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

Таблица 4.1

Аргумент Описание

lpFileName Указатель на имя файла или устройства

DesiredAccess

Устанавливает вид доступа к объекту. Приложение может

создать (открыть) файл (устройство) для чтения, записи, чте-

ния/записи или в режиме запроса к устройству. Значение 0

(ноль) указывает на то, что программа желает проверить воз-

можность доступа к объекту. В противном случае можно ис-

пользовать GENERIC_READ (чтение), GENERIC_WRITE (за-

пись) или и то и другое (оба значения объединяются при

помощи оператора | – логическое сложение)

dwShareMode

Набор битовых флагов, указывающий на режим совместного

доступа к объекту. Если значение dwShareMode равно 0, совмест-

ный доступ к объекту запрещен. Все последующие операции, на-

правленные на открытие объекта, не сработают до тех пор, пока

ваша программа не закроет дескриптор. Если необходимо обеспе-

чить совместный доступ к файлу, используйте комбинацию фла-

гов FILE_SHARE_DELETE (совместное удаление),

FILE_SHARE_READ (совместное чтение) и

FILE_SHARE_WRITE (совместная запись)

lpSecurityAttributes

Указатель на структуру SECURITY_ATTRIBUTES, которая

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

дочерними процессами. Если аргумент lpSecurityAttributes

имеет значение NULL, дескриптор не будет наследоваться

dwCreationDisposition

Указывает, каким образом следует создать (или открыть)

файл. Допускается использовать следующие значения:

CREATE_NEW (создать новый файл; если файл существует,

функция не срабатывает); CREATE_ALWAYS (создать новый

файл; если файл существует, он перезаписывается);

OPEN_EXISTING (открыть файл; если файл не существует,

функция не срабатывает); OPEN_ALWAYS (открыть файл; ес-

ли файл не существует, он создается) или TRUN-

CATE_EXISTING (открыть файл и сделать его длину равной

нулю; если файл не существует, функция не срабатывает)

dwFlagsAndAttributes

Набор атрибутов и флагов, которыми должен обладать файл.

Например, если требуется, чтобы новый файл был скрытым, ис-

пользуйте значение FILE_ATTRIBUTE_HIDDEN; если при работе

с файлом требуется отключить кэширование, используйте значе-

ние FILE_FLAG_NO_BUFFERING. Возможные значения флагов

перечислены в табл. 12.2. Здесь же можно использовать специаль-

ные флаги для именованных каналов

hTemplateFile

Содержит дескриптор с доступом GENERIC_READ. Это де-

скриптор шаблонного файла, атрибуты которого (включая

расширенные) будут присвоены создаваемому файлу

Наиболее интересным аргументом функции CreateFile() является предпо-

следний, шестой аргумент, который является набором флагов доступа к файлу

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

(табл. 4.2), можно настроить доступ к файлу самым причудливым образом.

Например, можно приказать системе удалить файл сразу же после того, как он

будет закрыт, или объявить, что файл будет использоваться для перекрываю-

щегося (overlapped) доступа (перекрывающийся доступ – базовый метод осу-

ществления асинхронного ввода/вывода). Помимо прочего, флаги позволяют

управлять механизмом кэширования.

Таблица 4.2

Флаг Значение

FILE_FLAG_WRITE-

_THROUGH

Приказывает Windows осуществлять немедленную запись

данных на диск. Система может по-прежнему кэшировать опе-

рации записи, однако она будет стараться немедленно

записывать данные на диск, избегая задержек

FILE_FLAG_NO_BU-

FFERING

Приказывает системе открыть файл без использования кэши-

рования или буферизации. В комбинации с флагом

FILE_FLAG_OVERLAPPED это дает максимальную произво-

дительность при асинхронном вводе/выводе, так как осуществ-

ление ввода/вывода не зависит от функционирования менедже-

ра памяти, работа которого обычно синхронизируется. Вместе

с тем некоторые операции ввода/вывода могут потребовать

больше времени для своего завершения, так как данные не со-

храняются в кэше. Чтобы работать с файлами, открытыми в

режиме FILE_FLAG_NO_BUFFERING, приложение должно

удовлетворять определенным требованиям. В частности, жест-

кие требования предъявляются к начальному смещению, размеру

блока и адресу буферов хранения данных

FILE_FLAG_RAN-

DOM_ACCESS

Оповещает систему о том, что доступ к файлу осуществляет-

ся случайным образом. Система может использовать это об-

стоятельство для оптимизации кэширования файла

FILE_FLAG_SEQU-

ENTIAL_SCAN

Оповещает систему о том, что доступ к файлу осуществляет-

ся последовательно от начала к концу файла. Система может

использовать это обстоятельство для оптимизации кэширова-

ния файла. Если в этом режиме указатель доступа к файлу пе-

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

будет выполнена корректно, однако при этом кэш не будет ис-

пользован наиболее оптимальным образом

FILE_FLAG_OVER-

LAPPED

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

вающегося ввода/вывода

FILE_FLAG_DELE-

TE_ON_CLOSE

Приказывает системе уничтожить файл сразу же после того,

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

что закрыть необходимо не только дескриптор, который был

получен с использованием флага

FILE_FLAG_DELETE_ON_CLOSE, но и все остальные деск-

рипторы файла. Если при открытии файла в этом режиме не

был использован режим FILE_SHARE_DELETE, все после-

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

Окончание табл. 4.2