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

Вы могли бы попытаться сделать все свойства и методы своих классов безопасными в отношении многопоточного выполнения, однако осуществить это чрезвычайно трудно с технической точки зрения и расточительно с точки зрения производительности. В конце концов, весь код вашего приложения оказался бы испещренным множеством самых различных критических разделов и бесчисленным количеством всевозможных объектов, используемых в качестве семафоров совместно с критическими разделами. Код такого типа чрезвычайно трудно проектировать и тестировать; кроме того, он характеризуется повышенными накладными расходами, обусловленными необходимостью осуществления проверок, обеспечивающих безопасность многопоточности, и чрезмерно сериализованным выполнением. Ни в .NET Framework, ни в .NET Compact Framework попытки решения этой задачи не делаются; вместо этого в обеих средах используется подход, основанный на тщательном документировании всех возможностей, и явное объявление того, какие операции безопасны в отношении многопоточного выполнения, а какие таковыми не являются. Предполагается, что разработчики внимательно ознакомятся с документацией и будут ею руководствоваться при использовании классов, свойств и методов. Метод класса, не являющийся безопасным в указанном смысле, не должен вызываться для параллельного выполнения из других потоков. Вместо этого, следует либо создать два различных экземпляра класса, либо сериализовать вызов не являющегося безопасным метода, поместив его в критический раздел. Именно таким способом обеспечивается доступ ко всему, что является необходимым и безопасным, а что таковым не является — документируется.

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

// К ДАННОЙ <���ПЕРЕМЕННОЙ/СВОЙСТВУ/МЕТОДУ> ДОСТУП ИЗ НЕСКОЛЬКИХ ПОТОКОВ

// ОСУЩЕСТВЛЯТЬСЯ НЕ ДОЛЖЕН!!!

// Предполагается, что этот метод будет использоваться

// <���высокоприоритетным/фоновым> потоком для ...

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

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