ContextBoundObject. Изоляция приложений.
Класс Broker (Брокер) должен быть производным от класса ContextBoundObject, чтобы во время выполнения можно было определить, требуется ли установить новый контекст. Если бы класс Broker (Брокер) не был производным от класса ContextBoundObject, то мы опять получили бы конфликт при организации поточной обработки: оба клиента смогли бы зарезервировать один и тот же единственный последний номер гостиницы. Это произошло бы даже несмотря на то, что класс был бы помечен атрибутом Synchronization (Синхронизация). А объект, не являющийся производным от ContextBoundObject, сможет работать в любом контексте (подвижной объект).
Поскольку другие контексты работают с заместителями или ссылками на реальный объект, вызовы из одного контекста в другой необходимо преобразовывать (приспосабливать) во время выполнения. Поэтому ContextBoundObject является производным от MarshalByRefObject. MarshalByRefObject – это базовый класс для объектов, которые нужно адресовать по ссылке.
Одно из преимуществ технологии синхронизации с использованием мониторов Monitor (Монитор), состоит в том, что Monitor (Монитор) может быть вызван из любого контекста. С другой стороны, потенциальный недостаток автоматической синхронизации – падение производительности из-за использования маршалинга и заместителей, по сравнению с работой с реальными объектами.
Как выяснится далее при обсуждении прикладных областей, благодаря тому, что объект клиента не зависит от контекста, именно он, а не заместитель, является тем реальным объектом, к которому осуществляется доступ. Он может быть скопирован в любой контекст внутри одной и той же прикладной области.
Изоляция приложений
При написании приложений часто возникает ситуация, когда необходимо изолировать части приложения так, чтобы сбой в одной из частей не приводил к отказу в остальной части приложения. В Windows изоляция приложений происходит традиционно на уровне процессов. Другими словами: если один из процессов останавливается или терпит крах, остальные процессы продолжают работать. Один процесс не может непосредственно адресовать память в адресном пространстве другого процесса. Однако существует несколько механизмов взаимодействия процессов.
К сожалению, использование отдельных процессов с целью достижения изоляции частей приложения – дорогое удовольствие для отдельного приложения. Для переключения от одного процесса к другому должен быть сохранен, а впоследствии восстановлен контекст (информация о состоянии процесса). Такое действие включает в себя переключение между потоками и процессами. Для переключения между потоками требуется сохранить регистры центрального процессора, такие как стек вызовов и указатель команд.
Необходимо также загружать информацию для нового потока и обновлять информацию для планирования потоков. Переключение между процессами требует дополнительного сохранения буферов ввода/вывода, учетной информации, а также привилегий процессора для предыдущего процесса, и восстановления этих данных для следующего процесса.