Microsoft добавила в Windows поддержку волокон (fibers), чтобы упростить порти рование (перенос) существующих серверных приложений из UNIX в Windows C точ ки зрения терминологии, принятой BWindows, такие серверные приложения следует считать однопоточпыми, но способными обслуживать множество клиентов. Иначе говоря, разработчики UNIX-приложений создали свою библиотскудля организации многопоючности и с ее помощью эмулируют истинные потоки. Она создает набор стеков, сохраняет определенные регистры процессора и переключает контексты при обслуживании клиентских запросов.
Разумеется, чтобы добиться большей производительности от таких UNIX-прило жений, их следует перепроектировать, заменив библиотеку, эмулирующую потоки, на настоящие потоки, используемые в Windows. Ho переработка может занять несколь ко месяцев, и поэтому компании сначала просто переносят существующий UNIX-код в Windows — это позволяет быстро предложить новый продук на рынке Windows приложений.
Но при переносе UNIX-программ в Windows могут возникнуть проблемы В част ности, механизм управления стеком потока в Windows куда сложнее простого выде ления памяти. В Windows стеки начинают работать, располагая сравнительно малым объемом физической памяти, и растут по мере необходимости (об этом я расскажу в разделе «Стек потока» главы l6). Перенос усложняется и наличием механизма струк турной обработки исключений (см. главы 23, 24 и 25).
Стремясь помочь быстрее (и с меньшим числом ошибок) переносить UNIX-код в Windows, Microsoft добавила в операционную систему механизм поддержки волокон. В этой главе мы рассмотрим концепцию волокон и функции, предназначенные для операций с ними. Кроме того, я покажу, как эффективнее работать с такими функци ями. Но, конечно, при разработке новых приложений следует использовать настоя щие потоки
Во-первых, потоки в Windows реализуются на уровне ядра операционной системы, которое отлично осведомлено об их существовании и "коммутирует» их в соответ ствии с созданным Microsoft алгоритмом В то жс время волокня реализованы на уров не кода пользовательского режима, ядро ничего не знает о них, и процессорное вре мя распределяется между волокнами по алгоритму, определяемому Вами. А раз так, то о вытеснении волокон говорить не приходится — по крайней мере, когда дело каса ется ядра
Второе, о чем следует помнить, — в потоке может быть одно или несколько воло кон. Для ядра поток — все то, что можно вытеснить и что выполняет код. Единовре менно поток будет выполнять код лишь одного волокна — какого, решать Вам (соот ветствующие концепции я поясню позже).
Приступая к работе с волокнами, прежде всего преобразуйте существующий по ток в волокно. Эчо делает функция ConvertThreadToFiber
PVOID ConvertThreadToFiber(PVOID pvParam);
Она создает в памяти контекст волокна (размером около 200 байтов). С него вхо дят следующие элементы:
В регистры процессора, включая указатели стека и команд.
Создав и инициализировав контекст волокна, Вы сопоставляете его адрес с пото ком, преобразованным в волокно, и теперь оно выполняется в этом потоке Convert ThreadToFiber возвращает адрес, по которому расположен контекст волокна. Этот ад pcc сщe понадобится Вам, но ни считывать, ни записывать по нему напрямую ни в коем случае нельзя — с содержимым этой структуры работают только функции, уп равляющие волокнами При вызове ExitThread завершаются и волокно, и поток
Нет смысла преобразовывать поток в волокно, если Вы не собираетесь создавать дополнительные волокна в том же потоке Чтобы создать другое волокно, поток (вы полняющий в данный момент волокно), вызывает функцию CreateFiber:
PVOID CreateFiber( DWORD dwStackSize, PFIBER_START_ROUTINE pfnStartArtrtress, PVOID pvParam);
Сначала она пытается создать новый стек, размер которого задан в параметре dwStackSize. Обычно передают 0, и тогда максимальный размер стека ограничивается 1 Мб, а изначально ему передается две страницы памяти. Если Вы укажече ненулевое значение, то для стека будет зарезервирован и передан именно такой объем памяти.
Создав стек, CrealeFiber формирует новую структуру контекста волокна и иници ализирует ее. При этом первый ее элемент получает значение, переданное функции как параметр pvParam, сохраняются начальный и конечный адреса стека, а также адрес функции волокна (переданный как аргумет pfnStartAddress)
У функции волокна, реализуемой Вами, должен бьпь такой прототип;
VOID WINAPI FiberFunc(PVOID pvParam);
Она выполняется, когда волокно впервые получает управление В качестве пара метра ей передается значение, изначально переданное как аргумент pvParam функ ции CreateFtber Внутри функции волокна можно делать что угодно. Обратите внима ние на тип возвращаемого значения — VOID Причина не в том, что это значение несущественно, а в том, чго функция никогда не возвращает управление! А иначе поток и все созданные внутри него волокна были бы тут же уничтожены.
Как и ConvertThreadToFiber, CreateFiber возвращает адрес контекста волокна, но с тем отличием, что новое волокно начинает работать не сразу, поскольку продолжа ется выполнение текущего. Единовременно поток может выполнять лишь одно волок но. И, чтобы новое волокно стало работать, надо вызвать SwitchToFiber
VOID SwitchToFiber(PVOID pvFiberExeculionContext);
Эта функция принимает единственный параметр (pvFiberExecutionContext) — ад рес контекста волокна, полученный в предшествующем вызове ConvertThreadToFiber или CreateFiber По этому адресу она определяет, какому волокну предоставить про цессорное время SwitchToFiber осуществляет такие операции
Применение SwitchToFiber — единственный способ выделить волокну процессор ное время Поскольку Ваш код должен явно вызывать эту функцию в нужные момен ты, Вы полностью управляете распределением процессорного времени для волокон Помните такой вид планирования не имеет ничего общего с планированием пото ков Поток, в рамках которого выполняются волокна, всегда может быть вытеснен операционной системой Когда поток получает процессорное время, выполняется только выбранное волокно, и никакое другое не получит управление, пока Вы сами не вьповете SwitchToFiber
Для уничтожения волокна предназначена функция DeleteFiber
VOID DeleteFiber(PVOID pvFiberExecutionContext);
Она удаляет волокно, чей адрес контекста определяется параметром pvFtberExecu tionContext, освобождает память, занятую стеком волокна, и уничтожает его контекст Но, если Вы передаете адрес волокна, связанного в данный момент с потоком, Delete Fiber сама вызывает ExitThread — в результате поток и все созданные в нем волокна «погибают»
DeleteFiber обычно вызывается волокном, чтобы удалить другое волокно Стек уда ляемого волокна уничтожается, а его контекст освобождается И здесь обратите вни мание на разницу между волокнами и потоками потоки, как правило, уничтожают себя сами, обращаясь к ExitThread Использование с этой целью TerminateThread счи тается плохим тоном — ведь тогда система не уничтожает стек потока Так вот, спо собность волокна корректно уничтожать другие волокна нам еще пригодится — как именно, я расскажу, когда мы дойдем до программы-примера
Для удобства предусмотрено еще две функции, управляющие волокнами В каж дый момент потоком выполняется лишь одно волокно, и операционная система все гда знает, какое волокно связано сейчас с потоком Чтобы получить адрес контекста текущего волокна, вызовите GetCurrentFiber
PVOID GetCurrentFiber();
Другая полезная функция — GetFiberData
PVOID GetFiberData();
Как я уже говорил, контекст каждого волокна содержит определяемое програм мистом значение Оно инициализируется знячением параметра pvParam, передавае мого функции ConvertThreadToFiber или CreateFiber, и служит аргументом функции во локна GetFtberData просто «заглядывает» в контекст текущего волокна и возвращает хранящееся там значение
Обе функции — GetCurrentFiber и GetFiberData — работают очень быстро и обыч но реализуются компилятором как встраиваемые (т e. вместо вызовов этих функций он подставляет их код)
Эта программа, «12 Counter.exe» (см. листинг на рис 12-1), демонстрирует примснс нис волокон для реализации фоновой обработки. Запустив се, Вы увидите диалого вое окно, показанное ниже (Настоятельно советую запустить программу Counter, тогда Вам будет легче понять, что происходит в ней и как она себя ведет)
Считайте эту программу свсрхминиатюрной электронной таблицей, состоящей всего из двух ячеек. В первую из них можно записывать — она реализована как поле, расположенное за меткой Count To. Вторая ячейка доступна только для чтения и ре ализована как статический элемент управления, размещенный за меткой Answer Из менив число в поле, Вы заставите программу пересчитать значение в ячейке Answer. В этом простом примере пересчет заключается в том, что счетчик, начальное значе ние которого равно 0, постепенно увеличивается до максимума, заданного в ячейке Count То. Для наглядности статический элемент управления, расположенный в ниж ней части диалогового окна, показывает, какое из волокон — пользовательского ин терфейса или расчетное — выполняется в данный момент
Чтобы протестировать программу, введите в поле число 5 — строка Currently Running Fiber будет заменена строкой Recalculation, а значение в поле Answer посте пенно возрастет с 0 до 5. Когда пересчет закончится, текущим волокном вновь станет интерфейсное, а поток заснет Теперь введите число 50 и вновь понаблюдайте за пе ресчегом — на этот paз перемещяя окно по экрану. При этом Вы заметите, что рас четное волокно вытесняется, а интерфейсное вновь получает процессорное время, благодаря чему программа продолжает реагировать на действия пользователя. Оставь те окно в покое, и Вы увидите, что расчетное волокно снова получило управление и возобновило работу с того значения, на котором было прервано
Остается проверить лишь одно. Давайте изменим число в поле ввода в момент пересчета Заметьте: интерфейс отреагировал на Ваши действия, но после ввода дан ных пересчет начинается заново. Таким образом, программа ведет себя как настоя щая электронная таблица.
Обратите внимание и на то, что в программе не задействованы ни критические секции, ни другие объекты, синхронизирующие потоки, — все сделано на основе двух волокон в одном потоке
Теперь обсудим внутреннюю реализацию программы Counter Когда первичный поток процесса приступает к выполнению _tWinMain, вызывается функция Convert ThreadToFiber, преобразующая поток в волокно, которое впоследствии позволит нам создать другое волокно. Затем мы создаем немодальнос диалоговое окно, выступаю щее в роли главного окна программы. Далее инициализируем переменную — инди катор состояния фоновой обработки (background processing stale, BPS) Она реализо вана как элемент bps в глобальной переменной g_FiberInfo Ее возможные состояния описываются в следующей таблице.
|
Состояние |
Описание |
|
BPS_DONE |
Пересчет завершен, пользователь ничего не изменял, новый пересчет не нужен |
|
BPS_STARTOVER |
Пользователь внес изменения, требуется пересчет с самою начала |
|
BPS_CONTINUE |
Пересчет еще продолжается, пользователь ничего не изменил, пере счет заново не нужен |
Индикатор bps проверяется внутри цикла обработки сообщений потока, который здесь сложнее обычного. Вот что делает этот цикл.
Если интерфейсному волокну делать нечего, а пользователь только что изменил значение в поле ввода, начинаем вычисления заново (BPS_STARTOVER). Главное, о чем здесь надо помнить, — волокно, отвечающее за пересчет, может уже работать. Тогда это волокно следует удалить и создать новое, которое начнет все с начала. Чтобы уничтожить выполняющее пересчет волокно, интерфейсное вызывает DeleteFiber. Именно этим и удобны волокна. Удаление волокна, занятого пересчетом, — операция вполне допустимая, стек волокна и его контекст корректно уничтожаются Если бы мы использовали потоки, а не волокна, интерфейсный поток не смог бы корректно уничтожить поток, занятый пересчетом, — нам пришлось бы задействовать какой нибудь механизм межпоточного взаимодействия и ждать, пока поток пересчета не завершится сам. Зная, что волокна, отвечающего за пересчет, больше нет, мы впра ве создать новое волокно для тех же целей, присвоив переменной bps значение BPS_CONTINUE.
Когда пользовательский интерфейс простаивает, а волокно пересчета чем-то за нято, мы выделяем ему процессорное время, вызывая SwitchToFiber, Последняя не вер пет управление, пока волокно пересчета тоже не обратится к SwitchToFiber, передав ей адрес контекста интерфейсного волокна.
FtberFunc является функцией волокна и содержит код, выполняемый волокном пересчета. Ей передается адрес глобальной структуры g_FiberInfo, и поэтому она зна ет описатель диалогового окна, адрес контекста интерфейсного волокна и текущее состояние индикатора фоновой обработки. Конечно, раз это глобальная переменная, то передавать ее адрес как параметр необязательно, но и решил показать, как в функ цию волокна передаются параметры. Кроме того, передача адресов позволяет добить ся того, чтобы код меньше зависел от конкретных переменных. - именно к этому и следует стремиться.
Первое, что делает функция волокна, — обновляет диалоговое окно, сообщая, что сейчас выполняется волокно пересчета. Далее функция получает значение, введенное в поле, и запускает цикл, считающий от 0 до указанного значения. Перед каждым приращением счетчика вызывается GetQueueStаtus — эта функция проверяет, не по
явились ли в очсрсди потока новые сообщения. (Все волокна, работающие в рамках одного потока, делят его очередь сообщений) Если сообщение появилось, значит, интерфейсному волокну есть чем заняться, и мы, считая его приоритетным по отно шению к расчетному, сразу же вызываем SwitchToFiber, давая ему возможность обра ботать поступившее сообщение Когда сообщение (или сообщения) будет обработа но, интерфейсное волокно передаст управление волокну, отвечающему за пересчет, и фоновая обработка возобновится.
Если сообщений нет, расчетное волокно обновляет поле Answer диалогового окна и засыпает на 200 мс. В коде настоящей программы вызов Sleep надо, естественно, убрать — я поставил его, только чтобы «потянуть" время.
Когда волокно, отвечающее за пересчет, завершает свою работу, статус фоновой обработки устанавливается как BPS_DONE, и управление передается (через Switch ToFiber) интерфейсному волокну. В этот момент ему делать нечего, и оно вызывает WaitMessage, которая приостанавливает поток, чтобы не тратить процессорное время понапрасну.
Counter