Практическое применение потоков

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

Та часть библиотеки визуальных компонентов (VCL), которая связана с пользовательским интерфейсом, базируется на предположении, что в любой момент времени к ней может получить доступ только один поток, поэтому принципиально невозможно организовать управление интерфейсом пользова­теля со стороны нескольких потоков. VCL требует, чтобы все управление поль­зовательским интерфейсом происходило в контексте основного потока прило­жения (исключение составляет только поток TCanvas).

В любом деле важно не переборщить. И особенно в случае с потоками. Не­смотря на то, что потоки оказывают помошь в решении одних проблем, они приносят с собой целый набор новых проблем. Предположим, например, что вы создаете интегрированную среду разработки и хотите, чтобы компилятор рабо­тал в своем собственном потоке, а программист мог продолжать работу с при­ложением во время компиляции программы. Здесь могут возникнуть проблемы вот какого плана. Что будет, если внести изменения в файл, который компили­руется в данный момент? Можно предложить несколько вариантов решения этой проблемы: например, создавать временную копию файла в момент его компиляции или делать недоступными для редактирования файлы, компиляция которых еще не завершена. Все дело в том, что потоки не являются панацеей. Решая те или иные проблемы разработки, они неминуемо порождают новые, чреватые появлением ошибок, которые очень трудно поддаются отладке. Раз­работка и реализация кода, обеспечивающего устойчивую работу потоков, — задача не из легких, поскольку в этом случае приходится учитывать гораздо больше факторов, чем при разработке однопоточного приложения.

Основы работы объекта tThread

Класс TThread является прямым потомком класса TObject и, следовательно, не является компонентом. Нетрудно заметить, что метод TThread.Execute абстрактный. Это значит, что класс TThread сам является абстрактным, и вы никогда не сможете создать экземпляр самого класса TThread. Вам можно создавать только экземпляры потомков класса TThread.

Для создания функционального потомка класса TThread надо переопределить единственный метод - Execute.

Единственный логический параметр, который передается в конструктор Create класса TThread, называется CreateSuspended и показывает, начинать ли поток в приостановленном состоянии. Если этот параметр равен False, ме­тод Execute этого объекта будет автоматически вызван без промедления. Если этот параметр равен True, то для действительного начала работы потока в оп­ределенной точке приложения нужно воспользоваться методом Resume, кото­рый приведет к вызову метода Execute. Обычно параметр CreateSuspended устанавливаемся равным True в случае, когда перед работой потока нужно ус­тановить дополнительные свойства для потокового объекта. Установка же свойств после запуска потока может привести к возникновению проблем.