Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

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

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

НА ЗАМЕТКУ

В версии NET Framework для настольных компьютеров имеется встроенная поддержка потоковых пулов. В этой модели для передачи выполнения работы ожидающему потоковому пулу используются "асинхронные делегаты". В версии 1 1 .NET Compact Framework поддержка универсальных асинхронных делегатов отсутствует.

Программисты на С/С++ могут рассматривать делегаты как аналоги указателей на функции. Программисты на LISP могут считать их аналогичными оболочкам. Делегаты позволяют задать привязку к методу определенного объекта и впоследствии вызвать этот метод, не ссылаясь на объект или имя конкретного метода. .NET Compact Framework обеспечивает поддержку делегатов. Асинхронные делегаты позволяют выполнять в асинхронном режиме методы, с которыми они связаны, с использованием потока из пула фоновых потоков. Указанный потоковый пул управляется средой времени выполнения. Асинхронные делегаты являются превосходным средством абстрагирования, поскольку освобождают разработчика от необходимости самостоятельного проектирования и тестирования собственных механизмов управления потоковыми пулами. Поскольку .NET Compact Framework с самого начала предназначалась для выполнения на устройствах с ограниченными ресурсами, взаимодействие между потоками для передачи параметров, что требуется при использовании асинхронных делегатов общего назначения, проектным решением для версии 1.1 не предусматривалось. Если вы хотите поддерживать потоковый пул, используя .NET Compact Framework, и выполнять фоновые задачи с использованием управляемых потоков, то можете это осуществить путем явного вызова метода System.Threading.ThreadPool.QueueUserWorkItem().

Вместо поддержки универсальных асинхронных делегатов в NET Compact Framework предусмотрена встроенная поддержка выполнения некоторых часто запрашиваемых задач в асинхронном режиме. В отношении таких задач, как создание HTTP-запроса данных с Web- сервера, поддержка асинхронного режима в .NET Compact Framework и .NET Framework совпадает. Кроме того, поддерживается класс System.Threading.Timer, обеспечивающий выполнение делегатов таймера фоновыми потоками. (Управляет этими потоками среда времени выполнения.) Таким образом, несмотря на то. что универсальные асинхронные делегаты в версии 1.1 NET Compact Framework не поддерживаются, в этой версии реализована поддержка конкретных асинхронных вызовов для большинства наиболее распространенных задач.

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

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

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

Поскольку введение дополнительных потоков значительно усложняет приложение, используйте их только тогда, когда это диктуется вескими причинами. Старайтесь не поддаваться "очарованию потоками".

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

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