| Назад | Содержание | Вперед |
Работая с Delphi, нужно иметь в виду: этот замечательный продукт не только упрощает разработку сложных приложений, он использует при этом все возможности операционной системы. Одна из возможностей, которую поддерживает Delphi, — это так называемые потоки (threads) или нити.
Потоки позволяют в рамках одной программы решать несколько задач одновременно. С недавних пор операционные системы для персональных компьютеров сделали это возможным.
Операционная система (ОС) предоставляет приложению некоторый интервал времени центрального процессора (ЦП) и в момент, когда приложение переходит к ожиданию сообщений или освобождает процессор, операционная система передает управление другой задаче. Теперь, когда компьютеры с более чем одним процессором резко упали в цене, а операционная система Windows NT может использовать наличие нескольких процессоров, пользователи действительно могут запускать одновременно более одной задачи. Планируя время центрального процессора, Windows 95 или Windows NT распределяют его между потоками, а не между приложениями. Чтобы использовать все преимущества, обеспечиваемые несколькими процессорами в современных операционных системах, программист должен знать, как создавать потоки.
В этой главе рассматриваются следующие вопросы:
Определение потока довольно простое: потоки — это объекты, получающие время процессора. Время процессора выделяется квантами (quantum, time slice). Квант времени — это интервал, имеющийся в распоряжении потока до тех пор. пока время не будет передано в распоряжение другого потока.
Обратите внимание, что кванты выделяются не программам или процессам, а порожденным ими потокам. Как минимум, каждый процесс имеет хотя бы один (главный) поток, но современные операционные системы, начиная с Windows 95 (для приверженцев Borland Kylix и Linux также), позволяют запустить в рамках процесса несколько потоков.
Если вы новичок в использовании потоков, самый простой пример их использования — приложения из состава Microsoft Office. К примеру, пакеты Excel и Word задействуют по несколько потоков. Word может одновременно корректировать грамматику и печатать, при этом осуществляя ввод данных с клавиатуры и мыши; программа Excel способна выполнять фоновые вычисления и печатать.
Примечание
Узнать число потоков, запущенных приложением, в Windows NT, 2000 и ХР можно при помощи утилиты Task Manager (Диспетчер задач). Для этого среди показателей, отображаемых в окне Processes, нужно выбрать опцию Thread Count. Так, в момент написания этих строк MS Word использовал 5 потоков, среда Delphi — 3.
Вполне возможно, что эту главу сейчас вы читаете из чистого любопытства. Но, более вероятно, вы пришли в поиске ответов на конкретные проблемы. Какого же рода проблемы могут быть решены с применением потоков?
Если задачи приложения можно разделить на различные подмножества: обработка событий, ввод/вывод, связь и др., то потоки могут быть органично встроены в программное решение. Если разработчик может разделить большую задачу на несколько мелких, это только повысит переносимость кода и возможности его многократного использования.
Сделав приложение многопоточным, программист получает дополнительные возможности управления им. Например, через управление приоритетами потоков. Если один из них "притормаживает" приложение, занимая слишком много процессорного времени, его приоритет может быть понижен.
Другое важное преимущество внедрения потоков — при возрастании "нагрузки" на приложение можно увеличить количество потоков и тем самым снять проблему.
Потоки упрощают жизнь тем программистам, которые разрабатывают приложения в архитектуре клиент/сервер. Когда требуется обслуживание нового клиента, сервер может запустить специально для этого отдельный поток. Такие потоки принято называть симметричными потоками (symmetric threads) — они имеют одинаковое предназначение, исполняют один и тот же код и могут разделять одни и те же ресурсы. Более того, приложения, рассчитанные на серьезную нагрузку, могут поддерживать пул (pool) однотипных потоков. Поскольку создание потока требует определенного времени, для ускорения работы желательно заранее иметь нужное число готовых потоков и активизировать их по мере подключения очередного клиента.
Примечание
Такой подход особенно характерен для Web-сервера Microsoft Internet Information Services и приложений, обрабатывающих запросы в его среде. Если вы создаете приложения ISAPI на Delphi, то можете использовать пулинг потоков, подключив к проекту модуль ISAPIThreadPool.pas. Если вы хотите позаимствовать идеи для других целей, ознакомьтесь с содержимым этого модуля.
Асимметричные потоки (asymmetric threads) — это потоки, решающие различные задачи и, как правило, не разделяющие совместные ресурсы. Необходимость в асимметричных потоках возникает:
Когда мы говорим "программа" (application), то обычно имеем в виду понятие, в терминологии операционной системы обозначаемое как "процесс". Процесс состоит из виртуальной памяти, исполняемого кода, потоков и данных. Процесс может содержать много потоков, но обязательно содержит, по крайней мере, один. Поток, как правило, имеет "в собственности" минимум ресурсов; он зависит от процесса, который и распоряжается виртуальной памятью, кодом, данными, файлами и другими ресурсами ОС.
Почему мы используем потоки вместо процессов, хотя, при необходимости, приложение может состоять и из нескольких процессов? Дело в том, что переключение между процессами — значительно более трудоемкая операция, чем переключение между потоками. Другой довод в пользу использования потоков — то, что они специально задуманы для разделения ресурсов; разделить ресурсы между процессами (имеющими раздельное адресное пространство) не так-то просто.
Здесь мы рассмотрим возможность для организации фоновых действий (job) внутри однопоточной программы с сохранением реакции этого потока на события от мыши и клавиатуры.
Еще не столь давно программисты пытались эмулировать потоки, запуская процедуры внутри цикла обработки сообщений Windows. Цикл обработки сообщений (или цикл ожидания) — это особый фрагмент кода в программе, управляемой событиями. Он исполняется тогда, когда программа находит в очереди события, которые нужно обработать; если таковых нет, программа может выполнить в это время "фоновую процедуру". Такой способ имитации потоков весьма сложен, т. к. вынуждает программиста, во-первых, сохранять состояние фоновой процедуры между ее вызовами, а во-вторых, определять момент, когда она вернет управление обработчику событий. Если такая процедура выполняется долго, то у пользователя может сложиться впечатление, что приложение перестало реагировать на внешние события. Использование потоков снимает проблему переключения контекста, теперь контекст (стек и регистры) сохраняет операционная система.
В Delphi возможность создать фоновую процедуру реализована через событие Onldle .объекта Application!
type TIdleEvent = procedure (Sender: TObject;
var Done: Boolean)
of object;
property Onldle: TIdleEvent;
Обработчик этого события вы можете написать, поместив на форму компонент TApplicationEvents со страницы Additional Палитры компонентов.
Чтобы сделать в фоновом режиме какую-то работу, следует разбить ее на кванты и выполнять по одному кванту каждый вызов Onldle — иначе приложение будет плохо реагировать на внешние воздействия.
Интерфейс Win32 API позволяет программисту управлять распределением времени между потоками; это распространяется и на приложения, написанные на Delphi. Операционная система планирует время процессора в соответствии с приоритетами потоков.
Приоритет потока — величина, складывающаяся из двух составных частей: приоритета породившего поток процесса и собственно приоритета потока. Когда поток создается, ему назначается приоритет, соответствующий приоритету породившего его процесса.
В свою очередь, процессы могут иметь следующие классы приоритетов.
Примечание
Классы Above normal и Below normal появились впервые в Windows 2000.
Класс реального времени задает приоритет даже больший, чем у многих процессов операционной системы. Такой приоритет нужен для процессов, обрабатывающих высокоскоростные потоки данных. Если такой процесс не завершится за короткое время, пользователь почувствует, что система перестала откликаться, т. к. даже обработка событий мыши не получит времени процессора.
Использование класса High ограничено процессами, которые должны завершаться за короткое время, чтобы не вызвать сбойной ситуации. Пример — процесс, который посылает сигналы внешнему устройству; причем устройство отключается, если не получит своевременный сигнал. Если у вас возникли проблемы с производительностью вашего приложения, было бы неправильно решать их просто за счет повышения его приоритета до high — такой процесс также влияет на всю ОС. Возможно, в этом случае следует модернизировать компьютер.
Большинство процессов запускается в рамках класса с нормальным приоритетом. Нормальный приоритет означает, что процесс не требует какого-либо специального внимания со стороны операционной системы.
И наконец, процессы с фоновым приоритетом запускаются лишь в том случае, если в очереди Диспетчера задач нет других процессов. Обычные виды приложений, использующие такой приоритет, — это программы сохранения экрана и системные агенты (system agents). Программисты могут использовать фоновые процессы для организации завершающих операций и реорганизации данных. Примерами могут служить сохранение документа или резервное копирование базы данных.
Приоритеты имеют значения от 0 до 31. Процесс, породивший поток, может впоследствии изменить его приоритет; в этой ситуации программист имеет возможность управлять скоростью отклика каждого потока.
Базовый приоритет нити складывается из двух составляющих, однако это не означает, что он просто равен их сумме. Взгляните на соответствующие величины, которые показаны в табл. 29.1. Для потока, имеющего собственный приоритет THREAD_PRIORITY_IDLE, базовый приоритет будет равен 1, невзирая на приоритет породившего его процесса.
И еще для класса Normal приведены по два приоритета, снабженные буквами В (Background) и F (Foreground). Объяснение этому дается ниже.
Таблица 29.1. Классы процессов и приоритеты их потоков (для Windows 2000 и ХР)
| IDLE_ PRIORITY CLASS |
BELOW_ NORMAL PRIORITY CLASS |
NORMAL_ PRIORITY_ CLASS |
ABOVE_ NORMAL_ PRIORITY_ CLASS |
HIGH PRIORITY CLASS |
REALTIME PRIORITY CLASS |
|
|
THREAD_ PRIORITY_ IDLE |
1 |
1 |
1 |
1 |
1 |
16 |
|
THREAD_ PRIORITY LOWEST |
2 |
4 |
5(B) 7(F) |
8 |
11 |
22 |
|
THREAD_ PRIORITY_ BELOW NORMAL |
3 |
5 |
6(B) 8(F) |
9 |
12 |
23 |
|
THREAD_ PRIORITY_ NORMAL |
4 |
6 |
7(B) 9(F) |
10 |
13 |
24 |
|
THREAD PRIORITY_ ABOVE_ NORMAL |
5 |
7 |
8(В) 10(F) |
11 |
14 |
25 |
|
THREAD_ PRIORITY_ HIGHEST |
6 |
8 |
9(B) 11(F) |
12 |
15 |
26 |
|
THREAD_ PRIORITY TIME CRITICAL |
15 |
15 |
15 |
15 |
15 |
31 |
Помимо базового приоритета, описываемого в этой таблице, планировщик заданий (scheduler) может назначать так называемые динамические приоритеты. Для процессов класса NORMAL_PRIORITY_CLASS при переключении из фонового режима в режим переднего плана и в ряде других случаев приоритет потока, с которым создано окно переднего плана, повышается. Так работают все клиентские операционные системы от Microsoft. Серверные операционные системы оптимизированы для выполнения фоновых приложений. Впрочем, Windows NT и более поздние ОС на этом ядре позволяют переключать режим оптимизации, используя переключатель Application response апплета System панели управления Windows (рис. 29.1).
К тому же Windows 2000 Professional и Windows 2000 Server имеют разные алгоритмы выделения квантов времени. Первая — клиентская — операционная система выделяет время короткими квантами переменной длины для ускорения реакции на приложения переднего плана (foreground). Для сервера же более важна стабильная работа системных служб, поэтому во второй ОС система распределяет длинные кванты постоянной длины.
Рис. 29.1. С помощью диалога Performance Options можно управлять алгоритмом назначения приоритетов
Теперь, разобравшись в приоритетах потоков, нужно обязательно сказать о том, как же их использует планировщик заданий для распределения процессорного времени.
Операционная система имеет различные очереди готовых к выполнению потоков — для каждого уровня приоритета свой. В момент распределения нового кванта времени она просматривает очереди — от высшего приоритета к низшему. Готовый к выполнению поток, стоящий первым в очереди, получает этот квант и перемещается в хвост очереди. Поток будет исполняться всю продолжительность кванта, если не произойдет одно из двух событий:
Теперь, наверное, вам более ясна опасность, исходящая от неоправданного завышения приоритетов. Ведь, если есть активные потоки с высоким приоритетом, ни один поток с более низким приоритетом ни разу не получит времени процессора. Эта проблема может подстерегать вас даже на уровне вашего приложения. Предположим, вы назначили вычислительному потоку приоритет THREAD_PRIORITY_ABOVE_NORMAL, а потоку, где обрабатывается ввод пользователя, — THREAD_PRIORITY_BELOW_NORMAL. Тогда вместо запланированного результата — совместить вычисления с нормальной реакцией приложения — вы получите строго обратный. Приложение вообще перестанет откликаться на ввод, и снять его будет возможно только с помощью средств ОС.
Так что нормальная практика для асимметричных потоков — это назначение потоку, обрабатывающему ввод, более высокого приоритета, а всем остальным — более низкого или даже приоритета idle, если этот поток должен выполняться только во время простоя системы.
Delphi представляет программисту полный доступ к возможностям программирования интерфейса Win32. Для чего же тогда фирма Borland представила специальный класс для организации потоков? Вообще говоря, программист не обязан разбираться во всех тонкостях механизмов, предлагаемых операционной системой. Класс должен инкапсулировать и упрощать программный интерфейс; класс TThread — прекрасный пример предоставления разработчику простого доступа к программированию потоков. Сам API потоков, вообще говоря, не очень сложен, но предоставленные классом TThread возможности вообще замечательно просты. В двух словах, все, что вам необходимо сделать, — это перекрыть виртуальный метод Execute.
Другая отличительная черта класса TThread — это гарантия безопасной работы с библиотекой визуальных компонентов VCL. Без использования класса TThread во время вызовов VCL могут возникнуть ситуации, требующие специальной синхронизации (см. разд. "Проблемы при синхронизации потоков" далее в этой главе).
Нужно отдавать себе отчет, что с точки зрения операционной системы поток — это ее объект. При создании он получает дескриптор и отслеживается ОС. Объект класса TThread — это конструкция Delphi, соответствующая потоку ОС. Этот объект VCL создается до реального возникновения потока в системе и уничтожается после его исчезновения.
Изучение класса TThread начнем с метода Execute:
procedure Execute; virtual; abstract;
Это и есть код, исполняемый в создаваемом вами потоке TThread.
Примечание
Хотя формальное описание Execute — метод abstract, но мастер создания нового объекта TThread создает для вас пустой шаблон этого метода.
Переопределяя метод Execute, мы можем тем самым закладывать в новый потоковый класс то, что будет выполняться при его запуске. Если поток был создан с аргументом CreateSuspended, равным False, то метод Execute выполняется немедленно, в противном случае Execute выполняется после вызова метода Resume (см. описание конструктора ниже).
Если поток рассчитан на однократное выполнение каких-либо действий, то никакого специального кода завершения внутри Execute писать не надо.
Если же в потоке будет выполняться какой-то цикл, и поток должен завершиться вместе с приложением, то условия окончания цикла должны быть примерно такими:
procedure TMyThread.Execute;
begin
repeat
DoSomething;
Until CancelCondition or Terminated;
end;
Здесь CancelCondition — ваше личное условие завершения потока (исчерпание данных, окончание вычислений, поступление на вход того или иного символа и т. п.), а свойство Terminated сообщает о завершении потока (это свойство может быть установлено как изнутри потока, так и извне; скорее всего, завершается породивший его процесс).
Конструктор объекта:
constructor Create(CreateSuspended: Boolean);
получает параметр CreateSuspended. Если его значение равно True, вновь созданный поток не начинает выполняться до тех пор, пока не будет сделан вызов метода Resume. В случае, если параметр CreateSuspended имеет значение False, конструктор завершается и только затем поток начинает исполнение.
destructor Destroy; override;
Деструктор Destroy вызывается, когда необходимость в созданном потоке отпадает. Деструктор завершает его и высвобождает все ресурсы, связанные с объектом TThread. function Terminate: Integer;
Для окончательного завершения потока (без последующего запуска) существует метод Terminate. Но если вы думаете, что этот метод делает какие-то принудительные действия по остановке потока, вы ошибаетесь. Все, что происходит, — это установка свойства
property Terminated: Boolean;
в значение True. Таким образом, Terminate — это указание потоку завершиться, выраженное "в мягкой форме", с возможностью корректно освободить ресурсы. Если вам нужно немедленно завершить поток, используйте функцию Windows API TerminateThread.
Примечание
Метод Terminate автоматически вызывается и из деструктора объекта. Поток— объект VCL будет дожидаться, пока завершится поток— объект операционной системы. Таким образом, если поток не умеет завершаться корректно, вызов деструктора потенциально может привести к зависанию всей программы.
Еще одно полезное свойство:
property FreeOnTerminate: Boolean;
Если это свойство равно True, то деструктор потока будет вызван автоматически по его завершении. Это очень удобно для тех случаев, когда вы в своей программе не уверены точно, когда именно завершится поток, и хотите использовать его по принципу "выстрелил и забыл" (fire and forget).
function WaitFor: Integer;
Метод WaitFor предназначен для синхронизации и позволяет одному потоку дождаться момента, когда завершится другой поток. Если вы внутри потока FirstThread пишите код
Code := SecondThread.WaitFor;
то это означает, что поток FirstThread останавливается до момента завершения потока SecondThread. Метод WaitFor возвращает код завершения ожидаемого потока (см. свойство Returnvalue).
property Handle: THandle read FHandle;
property ThreadID: THandle read FThreadID;
Свойства Handle и ThreadID дают программисту непосредственный доступ к потоку средствами API Win32. Если разработчик хочет обратиться к потоку и управлять им, минуя возможности класса TThread, значения Handle и ThreadID могут быть использованы в качестве аргументов функций Win32 API. Например, если программист хочет перед продолжением выполнения приложения дождаться завершения сразу нескольких потоков, он должен вызвать функцию API waitForMuitipieObjects; для ее вызова необходим массив дескрипторов потоков.
property Priority: TThreadPriority;
Свойство Priority позволяет запросить и установить приоритет потоков. Приоритеты потоков в деталях описаны выше. Допустимыми значениями приоритета для объектов TThread являются tpidle, tpLowest, tpLower, tpNormai, tpHigher, tpHighest и tpTimeCritical.
procedure Synchronize(Method: TThreadMethod);
Этот метод относится к секции protected, т. е. может быть вызван только из потомков TThread. Delphi предоставляет программисту метод Synchronize для
безопасного вызова методов VCL внутри потоков. Во избежание конфликтных ситуаций, метод synchronize дает гарантию, что к каждому объекту VCL одновременно имеет доступ только один поток. Аргумент, передаваемый в метод Synchronize, — это имя метода, который производит обращение к VCL; вызов Synchronize с этим параметром — это то же, что и вызов самого метода. Такой метод (класса TThreadMethod) не должен иметь никаких параметров и не должен возвращать никаких значений. К примеру, в основной форме приложения нужно предусмотреть функцию
procedure TMainForm.SyncShowMessage; begin
ShowMessagedntToStr (ThreadListl. Count) ) ; // другие обращения к VCL
end;
а в потоке для показа сообщения писать не
ShowMessage(IntToStr(ThreadListl.Count));
и даже не
MainForm.SyncShowMessage;
а только так:
Synchronize(MainForm.SyncShowMessage);
Примечание
Производя любое обращение к объекту VCL из потока, убедитесь, что при этом используется метод Synchronize; в противном случае результаты могут оказаться непредсказуемыми. Это верно даже в том случае, если вы используете средства синхронизации, описанные ниже.
procedure Resume;
Метод Resume класса TThread вызывается, когда поток возобновляет выполнение после остановки, или для явного запуска потока, созданного с параметром CreateSuspended, равным True.
procedure Suspend;
Вызов метода Suspend приостанавливает поток с возможностью повторного запуска впоследствии. Метод suspend приостанавливает поток вне зависимости от кода, исполняемого потоком в данный момент; выполнение продолжается с точки останова.
property Suspended: Boolean;
Свойство suspended позволяет программисту определить, не приостановлен ли поток. С помощью этого свойства можно также запускать и останавливать поток. Установив свойство suspended в значение True, вы получите тот же результат, что и при вызове метода Suspend — приостановку. Наоборот, установка свойства Suspended в значение False возобновляет выполнение потока, как и вызов метода Resume.
property ReturnValue: Integer;
Свойство ReturnValue позволяет узнать и установить значение, возвращаемое потоком по его завершении. Эта величина полностью определяется пользователем. По умолчанию поток возвращает ноль, но если программист захочет вернуть другую величину, то простая переустановка свойства ReturnValue внутри потока позволит получить эту информацию другим потокам. Это, к примеру, может пригодиться, если внутри потока возникли проблемы, или с помощью свойства ReturnValue нужно вернуть число не прошедших орфографическую проверку слов.
На этом завершим подробный обзор класса TThread. Для более близкого знакомства с потоками и классом Delphi TThread создадим многопоточное приложение. Для этого нужно написать всего несколько строк кода и несколько раз щелкнуть мышью.
Этот раздел содержит описание шагов, необходимых для создания простого, но показательного примера многопоточного приложения. Мы будем пытаться вычислить число "пи" с максимальной точностью после запятой. Конечно, встроенная в Delphi константа Pi имеет достаточную точность, правильнее сказать — максимальную, допускаемую самым точным 10-байтным форматом для вещественных чисел Extended. Так что превзойти ее нам не удастся. Но этот пример использования потоков может послужить прологом для решения реальных задач.
Первый пример будет содержать два потока: главный (обрабатывающий ввод пользователя) и вычислительный; мы сможем изменять их свойства и наблюдать за реакцией. Итак, выполните следующую последовательность действий:
1. В среде Delphi откройте меню File и выберите пункт New Application.
2. Расположите на форме пять меток и один переключатель, как показано на рис. 29.2.
Переименуйте главную форму в fmMain.
3. Откройте меню File и выберите пункт Save Project As. Сохраните модуль как uMain, а проект — как Threads 1.
Рис. 29.2. Внешний вид формы для приложения Threads'1
4. Откройте меню File и выберите пункт New. Затем дважды щелкните на объекте типа поток (значок Thread Object). Откроется диалоговое окно New Items, показанное на рис. 29.3.
Рис. 29.3. Диалоговое окно New Items с выбранным объектом типа "поток"
Рис. 29.4. Диалоговое окно New Thread Object
5. Когда появится диалоговое окно для именования объекта поток, введите TPiThread и нажмите клавишу <Enter> (рис. 29.4). Помимо этого, при желании, вы можете присвоить создаваемому потоку имя, установив флажок Named Thread и задав имя в поле Thread Name. Так как имя потока используется только для удобства обозначения, эту возможность мы использовать не будем.
Delphi создаст новый модуль и поместит в него шаблон для нового потока.
6. Код, вносимый в метод Execute, вычисляет число я, используя сходимость бесконечного ряда Лейбница:
Pi = 4 - 4/3 + 4/5 - 4/7 + 4/9 -...
Разумеется, отображать новое значение после каждой итерации — это то же самое, что стрелять из пушки по воробьям. На отображение информации система потратит в десятки раз больше времени, чем на собственно вычисления. Поэтому мы ввели константу updatePeriod, которая регулирует периодичность отображения текущего значения.
Код метода Execute показан ниже:
const
// Лучше использовать нечетное число для того, чтобы избежать эффекта // мерцания UpdatePeriod = 1000001;
procedure TPiThread.Execute; var sign : Integer;
PiValue, PrevValue : Extended; i : Int64;
begin
{ Place thread code here } PiValue := 4; sign := -1; i := 0; repeat Inc(i);
PrevValue := PiValue;
PiValue := PiValue + sign * 4 / (2*i+l); sign := -sign;
if i mod UpdatePeriod = 0 then
begin
GlobalPi := PiValue; GlobalCounter := i; Synchronize(fmMain.UpdatePi);
end;
until Terminated or (Abs(PiValue - PrevValue)<1E-19); end;
7. Откройте меню File и выберите пункт Save As. Сохраните модуль с потоком как uPiThread.pas.
8. Отредактируйте главный файл модуля uMain.pas и добавьте модуль uPiThread к списку используемых модулей в секции интерфейса. Он должен выглядеть так:
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, StdCtrls, uPiThread;
9. В секции public формы TfmMain добавьте ссылку на создаваемую нить: PiThread : TPiThread;
10. Добавьте в модуль uMain две глобальные переменные
GlobalPi : Extended;
GlobalCounter : Int64;
и метод UpdatePi:
procedure TfmMain.UpdatePi;
begin
if Islconic(Application.Handle) then
Exit;
LaValue.Caption := FloatToStrF(GlobalPi, ffFixed, 18, 18);
lalterNum.Caption := IntToStr(GlobalCounter) + ' iterations';
end;
Этот метод, если вы обратили внимание, вызывается из потока посредством процедуры Synchronize. Он отображает текущее значение приближения к числу "пи" и количество итераций.
В случае, если главное окно приложения свернуто, отображение не производится; так что после его развертывания вам, возможно, придется подождать некоторое время для обновления.
11. Выполните двойной щелчок на свободном месте рабочей области формы, при этом создастся шаблон метода FormCreate. Здесь мы отобразим значение системной константы р±:
procedure TfmMain.FormCreate(Sender: TObject);
begin
laBuiltln.Caption := FloatToStrF(Pi, ffFixed, 18, 18); end;
12. Выберите на форме переключатель (его название cbcalcuiate) и назначьте событию Onclick код, создающий и уничтожающий вычислительный поток в зависимости от состояния переключателя:
procedure TfmMain.cbCalculateClick(Sender: TObject);
begin if cbCalculate.Checked then
begin
PiThread := TPiThread.Create(True);
PiThread.FreeOnTerminate := True;
PiThread.Priority := tpLower;
PiThread.Resume; end else begin
if Assigned(PiThread) then PiThread.Terminate;
end;
end;
Таким образом, многопоточное приложение готово к запуску. Если все пройдет нормально, вы увидите картинку, подобную той, которая приведена на рис. 29.5.
Рис. 29.5. Выполняющееся приложение Threads1
Пока один из авторов писал текст этого раздела, запущенное одновременно приложение Threadsl выполнило пять миллиардов итераций и приблизилось к встроенному значению Pi в десятом разряде. Интересно, насколько хватит терпения у вас?
Этот простой пример — первый шаг в усвоении того, как от базового класса rrhread можно порождать собственные классы. Из-за своей простоты он не лишен недостатков; более того — если бы вычислительных нитей было не одна, а более, кое-какие приемы были бы даже ошибочными. Но — об этом ниже.
К сожалению, простота создания потоков подчас "компенсируется" сложностью их применения. Две типичные проблемы, с которыми программист может столкнуться при работе с потоками, — это тупики (deadlocks) и гонки (race conditions).
Вероятно, вы не раз наблюдали на трамвайной остановке следующую забавную картину (рис. 29.6).
Рис 29.6. Ситуации тупиков возникают не только в программировании
Рисунок дает исчерпывающее пояснение ситуации тупиков. Тупики имеют место, когда поток ожидает ресурс, который в данный момент принадлежит другому потоку. Рассмотрим пример. Поток 1 захватывает ресурс А, и для того чтобы продолжать работу, ждет возможности захватить ресурс Б. В то же время Поток 2 захватывает ресурс Б и ждет возможности захватить ресурс А. Развитие этого сценария заблокирует оба потока; ни один из них не будет исполняться. Ресурсами могут выступать любые совместно используемые объекты системы — файлы, массивы в памяти, устройства ввода/вывода и т. п.
В ситуации на картинке три трамвая захватили по одному ресурсу (перекрестку) и пытаются захватить еще один, что, очевидно, невозможно без освобождения уже захваченных. В жизни ситуация разрешилась просто — самый молодой из водителей был вынужден отъехать. В информационных технологиях все бывает сложнее. Откройте любой документ, сопровождающий очередной пакет обновления к любой версии Windows. Очень часто там можно найти информацию об одной-двух исправленных ситуациях тупиков.
Ситуация гонок возникает, когда два или более потока пытаются получить доступ к общему ресурсу и изменить его состояние. Рассмотрим следующий пример. Пусть Поток 1 получил доступ к ресурсу и изменил его в своих интересах; затем активизировался Поток 2 и модифицировал этот же ресурс до завершения Потока 1. Поток 1 полагает, что ресурс остался в том же состоянии, в каком был до переключения. В зависимости от того, когда именно был изменен ресурс, результаты могут варьироваться — иногда код будет выполняться нормально, иногда нет. Программисты не должны строить никаких гипотез относительно порядка исполнения потоков, т. к. планировщик ОС может запускать и останавливать их в любое время.
Inc(i) ;
if i = iSomething then DoSomething;
Здесь i — глобальная переменная, доступная из обоих потоков. Пусть два или более потоков исполняют этот код одновременно. Поток 1 инкрементировал значение переменной i и хочет проверить ее значение для выполнения тех или иных условий. Но тут активизируется другой поток, который еще увеличивает значение i. В результате первый поток "проскакивает" мимо условия, которое, казалось бы, должно было быть выполнено.
Возникновения как ситуаций гонок, так и тупиков можно избежать, если использовать приемы, обсуждаемые ниже.
Проще всего говорить о синхронизации, если создаваемый поток не взаимодействует с ресурсами других потоков и не обращается к VCL. Допустим, у вас на компьютере несколько процессоров, и вы хотите "распараллелить" вычисления. Тогда вполне уместен следующий код:
MyCompThread := TComputationThread.Create(False);
// Здесь можно что-нибудь делать, пока второй поток производит вычисления
DoSomeWork;
// Теперь ожидаем его завершения
MyCompThread.WaitFor;
Приведенная схема совершенно недопустима, если во время своей работы поток MyCompThread обращается к VCL посредством метода synchronize. В этом случае поток ждет главный поток для обращения к VCL, а тот, в свою очередь, его — классический тупик.
За "спасением" следует обратиться к программному интерфейсу Win32. Он предоставляет богатый набор инструментов, которые могут понадобиться для организации совместной работы потоков.
Главные понятия для понимания механизмов синхронизации — функции ожидания и объекты синхронизации. В Windows API предусмотрен ряд функций, позволяющих приостановить выполнение вызвавшего эту функцию потока вплоть до того момента, как будет изменено состояние какого-то объекта, называемого объектом синхронизации (под этим термином здесь понимается не объект Delphi, а объект операционной системы). Простейшая из этих функций — waitForSingieCbject — предназначена для ожидания одного объекта.
К возможным вариантам относятся четыре объекта, которые разработаны специально для синхронизации: событие (event), взаимное исключение (mutex), семафор (semaphore) и таймер (timer).
Но кроме специальных объектов можно организовать ожидание и других объектов, дескриптор которых используется в основном для иных целей, но может применяться и для ожидания. К ним относятся: процесс (process), поток (thread), оповещение об изменении в файловой системе (change notification) и консольный ввод (console input).
Косвенно к этой группе может быть добавлена критическая секция (critical section).
Примечание
Перечисленные выше средства синхронизации в основном инкапсулированы в состав классов Delphi. У программиста есть две альтернативы. С одной стороны, в состав библиотеки VCL включен модуль SYNCOBJS.PAS, содержащий классы для события (TEvent) и критической секции (TCriticalSection). С другой, с Delphi поставляется отличный пример IPCDEMOS, который иллюстрирует проблемы взаимодействия процессов и содержит модуль IPCTHRD.PAS с аналогичными классами — для того же события, взаимного исключения (TMutex), а также совместно используемой памяти (TSharedMem).
Перейдем к подробному описанию объектов, используемых для синхронизации.
Объект типа событие (event) — простейший выбор для задач синхронизации. Он подобен дверному звонку — звенит до тех пор, пока его кнопка находится в нажатом состоянии, извещая об этом факте окружающих. Аналогично, и объект может быть в двух состояниях, а "слышать" его могут многие потоки сразу.
Класс TEvent (модуль SYNCOBJS.PAS) имеет два метода: setEvent и ResetEvent, которые переводят объект в активное и пассивное состояние соответственно. Конструктор имеет следующий вид:
constructor Create(EventAttributes: PSecurityAttributes;
ManualReset, InitialState: Boolean; const Name: string);
Здесь параметр initialstate — начальное состояние объекта, ManualReset — способ его сброса (перевода в пассивное состояние). Если этот параметр равен True, событие должно быть сброшено вручную. В противном случае событие сбрасывается по мере того, как стартует хоть один поток, ждавший данный объект.
На третьем методе:
TWaitResult = (wrSignaled, wrTimeout, wrAbandoned, wrError);
function WaitFor(Timeout: DWORD): TWaitResult;
остановимся подробнее. Он дает возможность ожидать активизации события в течение Timeout миллисекунд. Как вы могли догадаться, внутри этого метода происходит вызов функции waitFotsingieObject. Типичных результатов на выходе waitFor два — wrsignaied, если произошла активизация события, и wrTimeout, если за время тайм-аута ничего не произошло.
Примечание
Если нужно (и допустимо!) ждать бесконечно долго, следует установить параметр Timeout в значение INFINITE.
Рассмотрим маленький пример. Включим в состав нового проекта объект типа TThread, наполнив его метод Execute следующим содержимым:
Var res: TWaitResult;
procedure TSimpleThread.Execute;
begin
e := TEvent.Create(nil,True,false, 'test');
repeat
e.ReSetEvent;
res := e.WaitFor(10000);
Synchronize(Showlnfo);
until Terminated; e.Free;
end;
procedure TSimpleThread.Showlnfo;
begin
ShowMessage(IntToStr(Integer (res)));
end;
На главной форме разместим две кнопки — нажатие одной из них запускает поток, нажатие второй активизирует событие:
procedure TForml.ButtonlClick(Sender: TObject);
begin
TSimpleThread.Create(False);
end;
procedure TForml.Button2Click(Sender: TObject);
begin
e.SetEvent;
end;
Нажмем первую кнопку. Тогда появившийся на экране результат (метод Showlnfo) будет зависеть от того, была ли нажата вторая кнопка или истекли отведенные 10 секунд.
События используются не только для работы с потоками — некоторые процедуры операционной системы автоматически переключают их. К числу
таких процедур относятся отложенный (overlapped) ввод/вывод и события, связанные с коммуникационными портами.
Объект типа взаимное исключение (mutex) позволяет только одному потоку в данное время владеть им. Если продолжать аналогии, то этот объект можно сравнить с эстафетной палочкой.
Класс, инкапсулирующий взаимное исключение, — TMutex — находится в модуле IPCTHRD.PAS (пример IPCDEMOS). Конструктор:
constructor Create (const Name: string);
задает имя создаваемого объекта. Первоначально он не принадлежит никому. (Но функция API createMutex, вызываемая в нем, позволяет передать созданный объект тому потоку, в котором это произошло.) Далее метод
function Get(TimeOut: Integer): Boolean;
производит попытку в течение Timeout миллисекунд завладеть объектом (в этом случае результат равен True). Если объект более не нужен, следует вызвать метод
function Release: Boolean;
Программист может использовать взаимное исключение, чтобы избежать считывания и записи общей памяти несколькими потоками одновременно.
Семафор (semaphore) подобен взаимному исключению. Разница между ними в том, что семафор может управлять количеством потоков, которые имеют к нему доступ. Семафор устанавливается на предельное число потоков, которым доступ разрешен. Когда это число достигнуто, последующие потоки будут приостановлены, пока один или более потоков не отсоединятся от семафора и не освободят доступ.
В качестве примера использования семафора рассмотрим случай, когда каждый из группы потоков работает с фрагментом совместно используемого пула памяти. Так как совместно используемая память допускает обращение к ней только определенного числа потоков, все прочие должны быть блокированы вплоть до момента, когда один или несколько пользователей пула откажутся от его совместного использования.
Работая в Delphi, программист может также использовать объект типа критическая секция (critical section). Критические секции подобны взаимным исключениям по сути, однако между ними существуют два главных отличия:
Критические секции и взаимные исключения очень схожи. На первый взгляд, выигрыш от использования критической секции вместо взаимного исключения не очевиден. Критические секции, однако, более эффективны, чем взаимные исключения, т. к. используют меньше системных ресурсов. Взаимные исключения могут быть установлены на определенный интервал времени, по истечении которого выполнение продолжается; критическая секция всегда ждет столько, сколько потребуется.
Возьмем класс TCriticalSection (модуль SYNCOBJS.PAS). Логика использования его проста — "держать и не пущать". В многопотоковом приложении создается и инициализируется общая для всех потоков критическая секция. Когда один из потоков достигает критически важного участка кода, он пытается захватить секцию вызовом метода Enter:
MySection.Enter; try DoSomethingCritical;
finally
MySection.Leave;
end;
Когда другие потоки доходят до оператора захвата секции Enter и обнаруживают, что она уже захвачена, они приостанавливаются вплоть до освобождения секции первым потоком путем вызова метода Leave. Обратите внимание, что вызов Leave помещен в конструкцию try. .finally — здесь требуется стопроцентная надежность. Критические секции являются системными объектами и подлежат обязательному освобождению — впрочем, как и остальные рассматриваемые здесь объекты.
Объект типа процесс (process) может быть использован для того, чтобы приостановить выполнение потока в том случае, если он для своего продолжения нуждается в завершении процесса. С практической точки зрения такая проблема встает, когда нужно в рамках вашего приложения исполнить приложение, созданное кем-то другим, или, к примеру, сеанс MS-DOS.
Рассмотрим, как, собственно, один процесс может породить другой. Вместо устаревшей и поддерживаемой только для совместимости функции winExec, перекочевавшей из прежних версий Windows, гораздо правильнее использовать более мощную:
function CreateProcess(IpApplicationName: PChar; IpCorranandLine: PChar;
IpProcessAttributes, IpThreadAttributes: PSecurityAttributes;
blnheritHandles: BOOL;
dwCreationFlags: DWORD; IpEnvironment: Pointer;
IpCurrentDirectory: PChar;
const IpStartupInfo: TStartupInfo;
var IpProcessInformation: TProcessInformation): BOOL;
Первые два параметра ясны — это имя запускаемого приложения и передаваемые ему в командной строке параметры. Параметр dwCreationFlags содержит флаги, определяющие способ создания нового процесса и его будущий приоритет. Использованные в приведенном ниже листинге флаги означают: CREATE_NEW_CONSOLE —будет запущено новое консольное приложение с отдельным окном; NORMAL_PRIORITY_CLASS — нормальный приоритет.
Структура TStartupInfo содержит сведения о размере, цвете, положении окна создаваемого приложения. В нижеследующем примере (листинг 29.1) используется поле wshowwindow: установлен флаг SW_SHOWNORMAL, означающий визуализацию окна с нормальным размером.
На выходе функции заполняется структура IpProcessInformation. В ней программисту возвращаются дескрипторы и идентификаторы созданного процесса и его первичного потока. Нам понадобится дескриптор процесса — в нашем примере создается консольное приложение, затем происходит ожидание его завершения. "Просигналит" нам об этом именно объект IpProcessInformation.hProcess.
Листинг 29.1. Порождение дочернего процесса
var
IpStartupInfo: TStartupInfo;
IpProcessInformation: TProcessInformation;
begin
FillChar(IpStartupInfo,Sizeof(IpStartupInfo),10);
IpStartupInfo.cb := Sizeof(IpStartupInfo};
IpStartupInfo.dwFlags := STARTFJJSESHOWWINDOW; IpStartupInfo.wShowWindow := SW_SHOWNORMAL;
if not CreateProcess(nil,
PChar('ping localhost'),
nil,
nil,
false,
CREATE_NEW_CONSOLE or NORMAL_PRIORITY_CLASS,
nil,
nil,
IpStartupInfo, IpProcessInformation) then
ShowMessage(SysErrorMessage(GetLastError; )
else
begin
WaitForSingleObject
(IpProcessInformation.hProcess, 10000); CloseHandle(IpProcessInformation.hProcess);
end;
end;
Поток может ожидать другой поток точно так же, как и другой процесс. Ожидание можно организовать с помощью функций API (как в только что рассмотренном примере), но удобнее это сделать при помощи метода TThread.WaitFor.
Консольный ввод (console input) годится для потоков, которые должны ожидать отклика на нажатие пользователем клавиши на клавиатуре. Этот тип ожидания может быть использован в программе дуплексной связи (chat). Один поток при этом будет ожидать получения символов; второй — отслеживать ввод пользователя и затем отсылать набранный текст ожидающему приложению.
Этот вид объекта ожидания очень интересен и незаслуженно мало известен. Мы рассмотрели практически все варианты того, как один поток может подать сигнал другому. А как получить сигнал от операционной системы? Ну, например, о том, что в файловой системе произошли какие-то изменения? Такой вид оповещения позаимствован из ОС UNIX и доступен программистам, работающим с Win32. Для организации мониторинга файловой системы нужно использовать
Три функции — FindFirstChangeNotification, FindNextChangeNotification и FinddoseChangeNotification. Первая из них возвращает дескриптор объекта файлового оповещения, который можно передать в функцию ожидания. Объект активизируется тогда, когда в заданной папке произошли те или иные изменения (создание или уничтожение файла или папки, изменение прав доступа и т. д.). Вторая — готовит объект к реакции на следующее изменение. Наконец, с помощью третьей функции следует закрыть ставший ненужным объект.
Так может выглядеть код метода Execute потока, созданного для мониторинга файловой системы:
var DirName : string;
...
procedure TSimpleThread.Execute;
var r: Cardinal;
fn : THandle;
begin
fn := FindFirstChangeNotification(pChar(DirName), True,
FILEJTOTIFY_CHANGE_FILE_NAME);
repeat
r := WaitForSingleObject(fn,2000);
if r = WAIT_OBOECT_0 then
Synchronize(Forml.UpdateList);
if not FindNextChangeNotification(fn) then
break;
until Terminated;
FindCloseChangeNotification(fn);
end;
На главной форме должны находиться компоненты, нужные для выбора обследуемой папки, а также компонент TListBox, в который будут записываться имена файлов:
procedure TForml.ButtonlClick(Sender: TObject);
var dir : string; begin
if SelectDirectory(dir,[],0)
then begin
Editl.Text := dir; DirName := dir;
end;
end;
procedure TForml.UpdateList;
var SearchRec: TSearchRec;
begin
ListBoxl.Clear;
FindFirst(Editl.Text+'\*.*', faAnyFile, SearchRec); repeat ListBoxl.Items.Add(SearchRec.Name);
until FindNext(SearchRec) <> 0;
FindClose(SearchRec);
end;
Приложение готово. Чтобы оно стало полнофункциональным, предусмотрите в нем механизм перезапуска потока при изменении обследуемой папки.
Интересная проблема возникает, если в приложении будет несколько одинаковых потоков. Как избежать совместного использования одних и тех же переменных несколькими потоками? Первое, что приходит на ум, — добавить и использовать поля объекта — потомка TThread, которые можно добавить при его создании. Каждый поток соответствует отдельному экземпляру объекта, и их данные пересекаться не будут. (Кстати, это одно из больших удобств использования класса TThread.) Но есть функции API, которые знать не знают об объектах Delphi и их полях и свойствах. Для поддержки разделения данных между потоками на нижнем уровне в язык Object Pascal введена специальная директива — threadvar, которая отличается от директивы описания переменных var тем, что применяется только к локальным данным потока. Следующее описание:
Var
datal: Integer; threadvar
data2: Integer;
означает, что переменная datal будет использоваться всеми потоками данного приложения, а переменная data2 будет у каждого потока своя.
Такая задача возникает очень часто. Многие, особенно начинающие, пользователи не вполне понимают, что между щелчком по значку приложения и его запуском может пройти несколько секунд, а то и десятков секунд. Они начинают щелкать по значку, запуская все новые копии. Между тем, при работе с базами данных и во многих других случаях иметь более одной копии не только не нужно, но и вредно.
Идея заключается в том, чтобы первая создаваемая копия приложения захватывала некий, ресурс, а все последующие при запуске пытались сделать то же самое и в случае неудачи завершались.
Пример такого ресурса — общий блок в файле, отображаемом в память. Поскольку этот ресурс имеет имя, можно сделать его уникальным именно для вашего приложения:
var UniqueMapping : THandle;
FirstWindow : THandle
; begin
UniqueMapping := CreateFileMapping($ffffffff,
nil, PAGE_READONLY, 0, 32,'MyMap');
if UniqueMapping = 0 then
begin
ShowMessage(SysErrorMessage(GetLastError));
Halt;
end
else if GetLastError = ERROR_ALREADY_EXISTS then
begin
FirstWindow := FindWindowEx(0, 0, TfmMain.ClassName, nil);
if FirstWindowoO then
SetForegroundWindow(FirstWindow};
Halt;
end;
// Нет других копий — продолжение Application.Initialize;
Примерно такие строки нужно вставить в начало текста проекта до создания форм. Блок совместно используемой памяти выделяется в системном страничном файле (об этом говорит первый параметр, равный -1, см. описание функции CreateFileMapping). Его имя — муМар. Если при создании блока будет получен код ошибки ERROR_ALREADY__EXISTS, это свидетельствует о наличии работающей копии приложения. В этом случае приложение переключает фокус на главную форму другого экземпляра и завершается; в противном случае процесс инициализации продолжается.
Потоки, как и другие мощные инструменты, должны быть использованы с осторожностью и без злоупотреблений, поскольку могут возникнуть ошибки, которые очень трудно найти. Есть очень много доводов за использование потоков, но есть и доводы против этого. Работа с потоками будет проще, если учитывать нижеприведенные положения.
Другими словами, избегайте использования в потоках глобальных переменных и переменных других объектов.
| Назад | Содержание | Вперед |