Как запускать и останавливать потоки?

Перейдем теперь от теории к практике, а именно к тому, как реально использовать многопоточность в своих программах. Начнем с ответа на, казалось бы, банальный вопрос: как запустить и остановить поток и процесс?

Пожалуй, более-менее просто дело обстоит лишь с запуском процесса. Для этого есть API-функция CreateProcess. Ей нужно передать путь к exe-файлу, который нужно запустить (плюс еще с десяток не очень интересных сейчас параметров, о которых вы прочтете в документации). CreateProcess проделывает большую работу: создает новое виртуальное адресное пространство, проецирует туда наш файл, а также все статически прилинкованные к нему динамические библиотеки и библиотеки, прилинкованные к этим библиотеками, и запускает первичный поток процесса. Этот поток сначала вызывает функции DllMain всех загруженных DLL, и только затем переходит к точке входа в exe-файл. Обратите внимание на то, что точка входа – это, как правило, совсем не привычная WinMain. Дело в том, что компилятор и линковщик (если их специально не попросить об обратном) в качестве точки входа подставляют свою собственную функцию (в Visual С++ она называется WinMainCRTStartup), которая выполняет некую подготовительную работу по инициализации стандартной библиотеки, по умолчанию включаемой в любой исполняемый модуль, и только затем вызывает WinMain. На выходе из WinMain эта же функция деинициализирует стандартную библиотеку, то есть освобождает ресурсы и т.п. В C++ роль этой функции еще больше. Вы никогда не задумывались над тем, кто вызывает конструкторы и деструкторы глобальных объектов? Да, ответственность за это ложится именно WinMainCRTStartup. Таким образом, ваша программа начинает выполняться еще до вызова WinMain и не заканчивается с выходом из нее. Кстати, все это относится и к DllMain, вместо нее линковщик тоже подставляет библиотечную функцию, которая в свою очередь вызывает вашу DllMain.

С запуском нового потока в существующем процессе (а первый поток, как я уже сказал, запускается системой при создании процесса) уже связана одна тонкость. В Platform SDK, в разделе, посвященном процессам и потокам, говорится, что для запуска нового потока предназначена API-функция CreateThread. Этой функции надо передать адрес, с которого начнется исполнение потока, иначе говоря, указатель на функцию потока и, как и в случае с CreateProcess, кучу дополнительных параметров. В рамках Platform SDK это утверждение, наверно, можно считать правильным, поскольку там идет речь лишь о Win32 API, но не о конкретных языках программирования. Но дело в том, что стандартная библиотека С (ее многопоточный вариант), должна подготовиться к запуску нового потока, инициализировать свои внутренние структуры данных (об истоках этих проблем я уже рассказывал). И точно так же как с WinMain, выполнение потока должно начаться со специальной библиотечной процедуры, которая уже вызовет вашу функцию потока. Чтобы это произошло, вместо CreateThread следует использовать функцию стандартной библиотеки _beginthreadex. Ее параметры и возвращаемое значение практически полностью соответствуют CreateThread, хотя есть и небольшие различия. В случае неудачи одна из них возвращает NULL, а другая -1. Хэндл потока у API функции описан как HANDLE, а у С-функции, как unsigned long, хотя на самом деле это одна и та же величина. Существует еще функция _beginthread (без «ex»), но она является атавизмом и использовать ее не рекомендуется. Заметьте, в однопоточной версии стандартной библиотеки функции _beginthread и _beginthreadex вообще отсутствуют. Итак, чтобы стандартная библиотека С могла правильно работать, для запуска нового потока следует использовать _beginthreadex.

Теперь перейдем к вопросу о том, как поток правильно завершить. Прежде всего, хочу обратить особое внимание на то, что для этого никогда нельзя использовать функцию TerminateThread! Удивительно, но, несмотря на то, что это написано не только в MSDN, у Рихтера, но и в любой мало-мальски приличной книге по программированию под Windows, юные «чайники» с завидным упорством продолжают пытаться использовать эту функцию. Во всяком случае, читая различные программистские конференции в FIDO и интернете, я постоянно встречаю советы использовать TerminateThread. Более того, я с удивлением прочитал этот совет даже в этом, в целом уважаемом мною журнале! Именно поэтому я хочу отметить это особо.

Почему же в обычном приложении нельзя использовать TerminateThread, и для чего же эта функция все-таки существует? Все дело в том, что TerminateThread предназначена не для завершения, а для аварийной остановки потока. Она существует лишь на «пожарный случай», когда завершить поток корректно нет возможности, например, если он банально зациклился. Поэтому место этой функции (вместе с TerminateProcess) – лишь в специальных системных приложениях вроде менеджера задач (Task Manager) или отладчика. И даже в таких приложениях к этим функциям стоит прибегать лишь в крайнем случае. В подтверждение этого могу обратить внимание на интересный факт: в MSDN можно найти специальную статью о том, каким образом отладчик (уж ему-то, казалось бы, естественно воспользоваться TerminateThread) может убить чужой поток, не прибегая к TerminateThread! Таким образом, если вы используете TerminateThread для уничтожения собственных потоков, это автоматически означает, что ваше приложение работает в аварийном режиме! Соответственно ожидать стабильной и надежной работы от него не приходится.

Чем же грозит насильственное «убийство» потоков? В первую очередь утечкой ресурсов. Почти в каждой программе нам приходится получать от системы различные ресурсы, которые по окончании работы необходимо освободить: память, файлы, объекты графического интерфейса, COM-интерфейсы и т.п. Поэтому если поток прекратил работу раньше времени, то функции, освобождающие эти объекты, не будут вызваны, и ресурсы будут висеть мертвым грузом до самого окончания работы, причем в лучшем случае заказавшего их процесса, а в худшем случае всей операционной системы. Надо заметить, что теоретически Windows должна следить за своими процессами и сама освобождать по окончании процесса те ресурсы, которые он сам забыл освободить. Однако в системах семейства 95 этот механизм реализован не полностью: скажем, открытый файл она закроет, а вот объекты графического ядра уже не освободит. И даже в NT-системах, где контроль за ресурсами реализован достаточно строго, могут встречаться ситуации, где корректно освободить ресурс может только сам процесс. Еще больше неприятностей могут доставить эксклюзивно используемые ресурсы, работать с которыми одновременно может только один процесс или поток. Если такой ресурс вовремя не освободить, им не сможет пользоваться вообще никто!

Еще раз обращу внимание на стандартную библиотеку C. Она не только сама заказывает некоторые ресурсы при запуске потока/процесса, но еще и устроена так, что должна отслеживать запуск/завершение каждого потока в процессе. Поэтому поток должен завершаться так, чтобы стандартная библиотека правильно отработала это событие.

Наконец, если свой код вы знаете и контролируете, то вряд ли кто сможет предсказать, какие возникнут побочные эффекты, если поток будет уничтожен во время вызова API-функции. Впрочем даже если ваш рабочий поток не обращается к системе, добиться, чтобы его аварийная остановка не вызывала побочных эффектов обойдется вам значительно дороже, чем просто использовать штатный механизм завершения потока.

Как же все-таки правильно завершить поток? В Platform SDK сказано, что для этого он сам должен вызвать API-функцию ExitThread. Правда здесь, как и в случае с CreateThread, оказывается, что на самом деле вместо нее следует использовать ее эквивалент из стандартной библиотеки _endthreadex (которая внутри себя вызовет ExitThread). Но, пожалуй, все-таки самый надежный способ завершить поток – это просто дать функции потока завершиться и вернуть управление системе. Как и в случае с WinMain, исполнение потока начинается с некоего системного кода, которой уже в свою очередь вызывает функцию, указатель на которую вы передали _beginthreadex (или непосредственно CreateThread, если вы не пользуетесь стандартной библиотекой). Как только ваша функция завершит работу, системный код вызовет _endthreadex (или соответственно сразу ExitThread) автоматически. Почему же я, тем не менее, не советую явно вызывать _endthreadex (хотя и ни в коем случае не утверждаю, что так делать нельзя)? Не забывайте, что перед завершением поток должен освободить все занятые ресурсы. Что касается ресурсов, используемых стандартной библиотекой, их освободит _endthreadex. Но практически любая программа сама использует ресурсы, и за их освобождение ответственность несете вы сами. В большинстве случаев во избежание путаницы освобождать ресурсы удобно в той же самой функции, в которой они были выделены. Поэтому если _endthreadex будет вызвана в одной из вложенных функций, то ресурсы, выделенные в вызывающих функциях, останутся не освобожденными. И не говорите, что вы точно знаете, что сейчас там у вас никаких ресурсов не выделяется! С развитием программы необходимость в этом вполне может появиться. А программировать всегда надо стараться так, чтобы потом не пришлось все переделывать. Поэтому лично я и считаю явное использование _endthreadex дурным тоном.

Кстати, при программировании на C++ освобождение ресурсов и прочая «чистка» чаще всего происходит в деструкторах. Это удобно, поскольку деструкторы локальных переменных вызываются автоматически при выходе из процедуры, в которой они были созданы. Но если в ней будет вызвана _endthreadex, этого не произойдет! Поэтому с этой функцией стоит быть аккуратным даже в процедуре самого верхнего уровня.

Обратите внимание, что корректно завершиться поток может лишь самостоятельно. Он должен сам вызвать ExitThread (неважно, сделает он это явно или неявно), предварительно освободив ресурсы и т.п. Таким образом, если, скажем, у вас есть набор рабочих потоков, которые необходимо остановить перед выходом из приложения, вы должны позаботиться о механизме, с помощью которого управляющий, «главный» поток передаст рабочим потокам сигнал о том, что «пора закругляться». Например, для этого может оказаться достаточным просто сделать специальную глобальную переменную (флаг «остановиться»), которую рабочие потоки будут периодически проверять в цикле (надо заметить, редкий рабочий поток обходится без цикла). По моему опыту, часто удобно бывает использовать «событие» (event). Почему, я расскажу в третьей части, когда речь пойдет об используемых для синхронизации объектах ядра и о событиях в частности. Там же я расскажу, каким образом главный поток может убедиться, что все рабочие потоки завершились, прежде чем заканчивать работу приложения.

В заключение должен упомянуть функцию CloseHandle. Иногда начинающие ошибочно полагают, что эта функция может остановить поток или процесс. Нет, эта функция предназначена всего лишь для того, чтобы закрывать описатели или «хэндлы», возвращаемые функциями CreateThread, CreateProcess и некоторыми другими. Хэндлы как потока, так и процесса, остаются в силе даже посте того, как поток или процесс был завершен. Как мы увидим, это дает возможность легко проверить из другого потока, работает ли еще поток или уже завершился, и даже точно отследить момент его завершения. Поэтому для того, чтобы освободить системные ресурсы, хэндл потока должен быть закрыт явным образом. Для этого и нужна функция CloseHandle. Впрочем, если вы вызовете ее еще до завершения потока, вы всего лишь лишитесь описателя, но никак не повлияете на сам поток.

Все что касается завершения потока можно буквально слово в слово повторить и про процесс. Хотя есть функция API ExitProcess и соответствующая ей библиотечная exit, самый надежный способ корректно закончить процесс – это просто дать завершиться всем потокам процесса.

Таким образом, при работе, как с отдельными потоками, так и с процессами в целом необходимо уделять внимание, чтобы их запуск и остановка производились корректно. Для этого, во-первых, необходимо использовать специальные функции RTL. Во-вторых, корректно завершиться поток или процесс может только самостоятельно. Поэтому к аварийной остановке потоков и процессов следует прибегать только в случае крайней необходимости.

Дата добавления: 2014-01-15