Завершение работы потока

Объект потока TThread считается законченным, когда завершается выполне­ние метода Execute. В этом случае вызывается стандартная процедура Delphi EndThread, которая, в свою очередь, вызывает функцию API ExitThread. Эта функция должным образом освобождает стек потока и сам потоковый объект API.

По окончании использования объекта TThread нужно гарантированно раз­рушить соответствующий объект Delphi. Только в этом случае можно быть уверенным в корректном освобождении всей памяти, занимаемой этим объек­том. И хотя это происходит автоматически по завершении процесса, воз­можно, стоит заняться освобождением объекта несколько раньше, чтобы при­ложение во время работы не занимало зря память. Простейший способ гаранти­рованно освободить объект TThread состоит в установке его свойства FreeOnTerminate равным значению True. Причем это можно сделать в любое время до завершения выполнения метода Execute.

Обьект TThread также имеет событие OnTerminate, которое происходит при завершении работы потока. Это событие вызывается в контексте основного по­тока вашего приложения. Последнее означает, что вы можете свободно полу­чать доступ к свойствам и методам VCL внутри обработчика этого события, не прибегая к услугам метода synchronize.

Важно иметь в виду, что метод потока Execute сам несет ответственность за проверку состояния свойства Terminated для определения необходимости в досрочном выходе. Эта деталь архитектуры класса гарантирует, что никакая «нечистая сила» не выдернет коврик из-под ваших ног в самый неподходящий момент и вы всегда успеете выполнить все необходимые очистительные опера­ции по окончании работы потока.

Преимущества однопоточного интерфейса пользователя

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

Кроме того, поскольку VCL может работать при условии доступа к ней толь­ко одного потока в данный момент времени, то становится очевидной необхо­димость создания кода для синхронизации нескольких потоков внутри VCL. Сетевое решение приводит к улучшению общей производительности приложе­ния благодаря более организованной архитектуре.