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

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

Тем не менее, иногда задают вопрос: "Если на вычислительном устройстве установлено несколько процессоров, то стоит ли использовать в приложении несколько потоков для ускорения вычислений?" На этот вопрос следует ответить так же, как и при проектировании приложений для однопроцессорных устройств: "Вероятно, не стоит. Использовать несколько потоков следует тогда, когда это делается в интересах асинхронного выполнения некоторых операций". Даже в случае многопроцессорных систем, на которых установлена операционная система, поддерживающая параллельные вычисления, многопоточное выполнение еще не является гарантией лучшей производительности. На то есть две причины:

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

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

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

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

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

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

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