Win 32-эфффективная разработка приложений

Побочные эффекты успешного ожидания

admin — Sun, 05 Sep 2010 15:34:37 +0000

Успешный вызов функции WaitForSingleObject или WaitForMuttipleObjects на самом деле меняет состояние некоторых объектов ядра. Успешным считается такой вызов, который завершается освобождением соответствующего объекта или объектов. При этом функция возвращает значение WAIT_OBJECT_0 или значение, являющееся смещением относительно WAIT_OBJECT_0. Вызов считается неудачным, если возвращается значение WAIT_TIMEOUT или WAIT_FAILED. В этом случае состояние каких-либо объектов не меняется.
Пусть, например, поток вызвал функцию WaitForSingleObject и ждет освобождения объекта «событие с автосбросом» (объекты-события рассматриваются в следующем разделе). Когда объект переходит в свободное состояние, функция обнаруживает это и возвращает значение WAIT_OBJECT_0. Но перед самым возвратом из функции объект-событие будет переведен в занятое состояние. Это и есть побочный эффект успешного ожидания.
Объекты ядра «событие с автосбросом» ведут себя подобным образом, потому что таково одно из правил, определенных Microsoft для объектов этого типа. Другие объекты дают иные побочные эффекты, а некоторые — вообще никаких. К последним относятся объекты ядра «процесс» и «поток».

Wait-функции

admin — Thu, 19 Aug 2010 15:31:01 +0000

Многие объекты ядра могут находиться либо в свободном {signaled state), либо
в занятом состоянии (nonsignaled state). К таким объектам относятся:
процессы;
потоки;
задания;
файлы;
консольный ввод;
уведомления об изменении файлов;
события;
ожидаемые таймеры;
семафоры;
мьютексы.
Wait-функции позволяют потоку в любой момент приостановиться и ждать освобождения какого-либо объекта ядра. Важным свойством функций этого семейства является то, что они не тратят процессорное время, пока ждут освобождения объекта или наступления тайм-аута.

Обмен данными между процессами

admin — Sat, 07 Aug 2010 15:35:59 +0000

Потоки одного процесса не имеют доступа к адресному пространству другого процесса. Однако существуют специализированные механизмы для передачи данных между процессами. Вообще обмен данными между процессами (Interprocess Communication, IPC) в свое время начинался в виде процедуры перемещения перфокарт из выходного отверстия одного вычислительного устройства в устройство чтения другого вычислительного устройства. Позже, с развитием операционных систем, обмен данными между процессами проделал определенный путь в сторону высоких технологий. Наиболее впечатляющим примером обмена информацией является создание Всемирной паутины (World Wide Web). Приведем краткий список механизмов IPC, встроенных в Windows:
Буфер обмена (clipboard) — одна из самых примитивных и хорошо известных форм IPC. Основная его задача состоит в поддержке обмена данными между программами по желанию и под контролем пользователя.
Библиотеки динамической компоновки. Когда в рамках DLL объявляется переменная, то ее можно сделать разделяемой (shared). Все процессы из DLL, обращающиеся к такой переменной, будут использовать одно и то же место в физической памяти.
Сообщение WM_COPYDATA, которое применяется для передачи участка памяти другому процессу.
Разделяемая память (shared memory) реализуется при помощи объектов ядра «проекция файла», которые осуществляют отображение файлов на оперативную память.
Протокол динамического обмена данными (Dynamic Data Exchange, DDE), который определяет все основные функции для обмена данными между приложениями. DDE широко использовался до тех пор, пока Microsoft не приняла решение использовать OLE, которую затем переименовали в ActiveX, в качестве основной технологии взаимодействия программ.
Удаленный вызов процедур (Remote Procedure Call, RPC), строго говоря, не является механизмом IPC. Это скорее, технологическая оболочка, расширяющая возможности традиционных механизмов IPC. Благодаря RPC сеть становится совершенно прозрачной как для сервера, так и для клиента.
ActiveX является универсальной технологией, и одним из ее применений является обмен данными между процессами. Специально для этой цели Microsoft определила стандартный интерфейс IDataObject А для обмена данными по сети используется Distibuted Component Object Model (DCOM), которую можно рассматривать как объединение ActiveX и RPC.
Каналы (pipes) — мощная технология обмена данными. В общем случае канал можно представить в виде трубы, соединяющей два процесса, через которую идет непрерывный поток данных. Каналы делятся на анонимные (anonymous pipes) и именованные (named pipes). Анонимные каналы используются довольно редко. Именованные каналы, которые поддерживаются только в системах WinNT/2000, передают произвольные данные и могут работать через сеть. В последнее время вместо именованных каналов все чаще используют сокеты.
Сокеты (sockets) — очень важная технология, так как именно она отвечает за обмен данными в сети Интернет. Сокеты также часто используются в крупных локальных сетях. Сокеты можно рассматривать как «разъемы», представляющие собой абстракцию конечных точек коммуникационной линии, которая соединяет два приложения. Windows содержит достаточно мощный API для работы с сокетами.
Почтовые слоты (mailslots) — это механизм однонаправленного IPC. Если приложению известно имя слота, то оно может помещать туда сообщения, а приложение, которое является владельцем этого слота, может их оттуда извлекать и обрабатывать. Основное преимущество этого способа заключается в возможности передавать сообщения по локальной сети сразу нескольким компьютерам за одну операцию, если, конечно, несколько приемников имеют почтовые слоты с одним и тем же именем.
Microsoft Message Queue (MSMQ) — обеспечивает посылку сообщений между приложениями с помощью очереди сообщений. В отличие от других форм IPC, эта технология позволяет посылать сообщения процессу, который в данное время недоступен, например, если приложение не запущено, сервер вышел из строя или сетевой канал связи перегружен. Механизм MSMQ ставит сообщение в очередь до тех пор, пока не появится возможность переслать его адресату.
В данной книге будут рассмотрены только два механизма обмена данными между процессами: обмен с помощью разделяемой памяти (или объекта ядра «проекция файла») и обмен при помощи сообщения WM_COPYDATA.
Но сначала — несколько слов об архитектуре памяти Win32.

Физическая память и страничный файл

admin — Fri, 30 Jul 2010 15:45:31 +0000

Так как на современных компьютерах оперативная память RAM имеет размеры, по крайней мере, на порядок меньше 4 Гбайт, то система имитирует задекларированную память за счет дискового пространства. При этом на диске создается страничный файл (page file), который вместе с физической памятью RAM образует виртуальную память, доступную всем процессам. Другое название страничного файла — файл подкачки (swap file).
Процессор сам управляет отображением виртуальных адресов из машинных команд в эквивалентные физические адреса в ходе выполнения команды. Осуществляя это отображение, процессор оперирует страницами памяти размером 4 Кбайта. Этот же размер страниц используется Windows для управления виртуальной памятью.
Теперь посмотрим, что происходит, когда поток пытается получить доступ к блоку данных в адресном пространстве своего процесса. В этом случае возможны три ситуации:
Данные, к которым обращается поток, находятся в оперативной памяти. Тогда процессор проецирует виртуальный адрес данных на физический, и поток получает доступ к этим данным.
Данные отсутствуют в оперативной памяти, но размещены где-то в страничном файле. Попытка доступа к данным генерирует прерывание, называемое Page Fault (Ошибка страницы). Тогда система начинает искать свободную страницу в оперативной памяти. Если такой страницы нет, то система вынуждена освободить одну из занятых страниц. Если занятая страница не модифицировалась, она просто освобождается. В ином случае она сначала копируется из оперативной памяти в страничный файл. После этого система отыскивает в страничном файле запрошенный блок данных, загружает этот блок на свободную страницу оперативной памяти и, наконец, проецирует виртуальный адрес данных на соответствующий адрес в физической памяти.
Иногда из-за программной ошибки или сбоя в аппаратной части требуемая страница отсутствует и в оперативной памяти, и в страничном файле. Тогда система генерирует ошибку Invalid Page Fault, и работающее приложение закрывается.

Архитектура интерфейсов (API) управления памятью

admin — Mon, 19 Jul 2010 15:45:49 +0000

Диспетчер виртуальной памяти (Virtual Memory Manager — VMM) является составной частью ядра операционной системы. Он отображает виртуальные адреса на физические, используя механизм подкачки страниц памяти (page swapping). Кроме того, он предоставляет прикладным программам различные интерфейсы (API) для работы с виртуальной памятью:
Virtual Memory API — набор функций, позволяющих приложению работать с виртуальным адресным пространством. Например, функции VirtualAlloc и VirtualFree позволяют процессу получать страницы из памяти или возвращать их системе.
Memory Mapped File API — набор функций, позволяющих работать с файлами, проецируемыми в память. Это новый механизм, предоставляемый Windows для работы с файлами и взаимодействия процессов.
Heap Memory API — набор функций, позволяющих работать с динамически распределяемыми областями памяти (кучами).

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

admin — Sun, 04 Jul 2010 15:46:03 +0000

Проецирование файла данных в адресное пространство процесса предоставляет разработчику мощный механизм работы с файлами. Спроецировав файл на адресное пространство процесса, программа получает возможность работать с ним, как с массивом. Это очень удобно при манипуляциях с большими потоками данных. Для проецирования файла в память необходимо выполнить три операции:
1. Создать объект ядра «файл», идентифицирующий дисковый файл, который вы хотите использовать как проецируемый в память (функция CreateFile).
2. Создать объект ядра «проекция файла» при помощи функции CreateFileMapping. При этом используется дескриптор файла, возвращенный функцией CreateFile.
3. Указать отображение объекта «проекция файла» или его части на адресное пространство процесса (функция MapViewOfFile).
Закончив работу с проецируемым в память файлом, тоже следует выполнить три операции:
1. Отменить отображение на адресное пространство процесса объекта «проекция файла» (функция UnmapViewOfFile).
2. Закрыть объект ядра «проекция файла».
3. Закрыть объект ядра «файл».
Описанную технологию можно проиллюстрировать следующим фрагментом кода:
HANDLE hFile. hFileMapping:
PVOID pArray;
hFile = CreateFileC'File Name", ... );
hFileMapping = CreateFileMapping(hFile, ... ):
CloseHandle(hFile) :
pArray - MapViewOfFile(hFileMapping. ... );
CloseHandle(hFileMapping) ;
//
/ Работаем с файлом, как с массивом рАггау /
//
UnmapVi ewOfFi1е(pArray);
В этом примере «закрывающие» операции выполняются сразу после использования соответствующего дескриптора объекта. Это уменьшает вероятность утечки ресурсов.

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

admin — Wed, 16 Jun 2010 15:46:21 +0000

Самый низкоуровневый механизм совместного использования данных в одной системе — проецирование файла в память. На нем так или иначе базируются все другие механизмы разделения данных. Поэтому, если вы хотите получить максимальное быстродействие с минимумом издержек, лучше всего применять именно проецирование.
Совместное использование данных в этом случае происходит по следующей схеме. Несколько процессов проецируют в память представления одного и того же объекта «проекция файла», то есть делят одни и те же страницы физической памяти. Поэтому, когда один процесс записывает данные в представление общего объекта «проекция файла», эти изменения немедленно отражаются в других процессах. Но для этого все процессы должны использовать одинаковое имя объекта «проекция файла».
В предыдущем разделе рассматривалось проецирование представления файла, размещенного на диске. Но для целей обмена данными между разными процессами хранение этих данных на диске было бы очень неудобным. К счастью, Win32 API предусматривает возможность проецирования файлов непосредственно на физическую память из страничного файла, а не из специально создаваемого дискового файла.
Этот способ даже проще стандартного, рассмотренного в предыдущем разделе. Во-первых, не нужно вызывать функцию CreateFile. Вы просто вызываете функцию CreateFileMapping и передаете значение INVALID_HANDLE_VALUE (или константу -1) в параметре hFile. Но при вызове функции CreateFileMapping следует передать в последнем ее параметре С-строку, содержащую имя этого объекта. Тогда другие процессы, если им понадобится доступ к разделяемой памяти, смогут вызвать функцию OpenFileMapping и передать ей то же самое имя.
Учтите, что если разделяемая память используется в режиме записи данных более чем одним потоком, то вы должны предусмотреть синхронизацию работы этих потоков. Пример такой синхронизации при помощи объектов-событий рассматривается чуть ниже.
Когда работа с объектом «проекция файла» завершена, процесс должен вызвать функцию CloseHandle. Как только все дескрипторы объекта будут закрыты, система освободит память, переданную из страничного файла.

Таймеры и время

admin — Tue, 01 Jun 2010 15:46:59 +0000

При решении некоторых задач программа должна отслеживать текущее время или выполнять какие-либо действия с определенной периодичностью. Например, эта проблема возникает в приложениях, имитирующих аппаратуру, работающую в реальном масштабе времени, в игровых и мультимедийных приложениях, а также при проведении различных тестов. Кроме того, иногда требуется отладить критичные ко времени исполнения фрагменты кода, для чего нужен «хронометр» с высокой разрешающей способностью.
Win32 API содержит как функции для измерения текущего времени, так и функции для создания виртуальных таймеров — устройств, извещающих приложение об истечении заданного интервала времени. Для успешного применения этих программных средств необходимо учитывать их разрешающую способность и потенциальную точность измерения.
Важно понимать, что многозадачная операционная система Windows не является системой реального времени, поэтому любой виртуальный таймер в Windows не может гарантировать какой бы то ни было фактической точности отсчета временного интервала. Ведь в любой момент времени система может прервать выполнение вашего приложения, чтобы дать возможность поработать другому приложению (простой, вызванный прерыванием, чаще всего длится от 1 до 30 мс1). Вероятность таких прерываний тем ниже, чем меньше рассматриваемый временной интервал и чем меньше других программ работает одновременно с вашим приложением. В то же время, как показывают эксперименты, мультимедийный таймер Windows обеспечивает вполне приемлемую фактическую точность отсчета временных интервалов для многих задач.

Системное время

admin — Sat, 29 May 2010 15:47:37 +0000

Системное время в Windows содержит информацию о текущих дате и времени и представляет собой так называемое UTC-время (Universal Time Coordinated). Время в формате UTC основывается на среднем времени по Гринвичу. Системное время может быть получено при помощи функции GetSystemTime:
VOID GetSystemTimeCLPSYSTEMTIME lpSystemTime);
Функция записывает результат в структуру типа SYSTEMTIME, адрес которой задается параметром lpSystemTime. Структура типа SYSTEMTIME содержит поля для года, месяца, дня недели, дня, часов, минут, секунд и миллисекунд.
Так как системное время отсчитывается по Гринвичу, то, скорее всего, оно не совпадает с местным временем, которое отображается на панели задач. Получить значение местного времени можно при помощи функции GelLocalTime, которая возвращает информацию в том же формате, что и функция GetSystemTime. Если вы считаете, что ваше приложение может изменять системное время, то это можно осуществить при помощи вызова функции SetSystemTime или SetLocalTime. В некоторых случаях может оказаться полезной пара функций, работающих с информацией о часовом поясе, — GetTimeZonelnformation и SetTimeZonelnformation.
Системное время считывается с часов реального времени, встроенных в компьютер и имеющих автономное питание, в момент запуска Windows. Затем операционная система обеспечивает приращения системного времени, используя прерывания системного таймера, аналогично управлению временем Windows. Таким образом, точность измерения времени с помощью GetSystemTime также определяется разрешением системного таймера.

Программирование задержек в исполнении кода

admin — Tue, 11 May 2010 15:48:42 +0000

При создании реальных программ часто возникает необходимость «притормозить» исполнение кода в том или ином месте программы. В качестве простейшего примера можно привести игровую программу, перемещающую некий графический объект по экрану с помощью цикла while. Предположим, что вы отладили вашу программу на компьютере с процессором, имеющим тактовую частоту 500 МГц. Что произойдет, если эта программа будет исполняться на более мощном компьютере с тактовой частотой процессора 2 ГГц? Если не предусмотреть специальных мер, то объект будет двигаться гораздо быстрее, и не исключено, что играть станет совершенно невозможно. Типичное решение проблемы заключается в определении характеристик процессора и добавлении программируемых задержек в таких циклах. Другой пример, с которым мы столкнулись совсем недавно, —использование программируемой задержки для калибровки счетчика меток реального времени в классе KTimer.