Страница 219 из 372
Клиентское приложение
Клиентское приложение для рассматриваемого примера почти не отличается от клиентского приложения MуАрр. cs из предыдущей главы. Добавлен вывод на консоль клиента идентификатора контекста клиента, хеш потока и его тип.
using System;
using SPbU.AOP_NET;
using System.Threading;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Cha
using System.Runtime.Remoting.Cha
using System.Net;
public class MyApp {
public static void Main() {
HttpCha
Cha
try {
Console.WriteLine("Client context = " +
Thread.CurrentContext.ContextID + "n" +
"Client thread = " +
Thread.CurrentThread.GetHashCode () +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread);
Account a = (Account)Activator.GetObject {
typeof (Account),
"http://localhost:8080/Account",
WellKnownObjectMode.Singleton);
a. Add(5);
Console.WriteLine("Current account: {0}",
a. Total());
}
catch(WebException e) {
Console.WriteLine(e.Message);
}
catch(Exception e) {
Console.WriteLine(e.Message);
}
finally!
Console.WriteLine("Bye");
}
}
}
Атрибут синхронизации
Цель данного раздела состоять в частичном объяснении (в той части, которая потребуется для рассматриваемого примера) семантики атрибута SynchronizationAttribute, реализованного в .NET.
Изложение будет основано на коде, опубликованном в рамках SSCLI (файл sscli clr scr bcl system runtime remoting synchronizeddispatch.cs). Целиком этот код здесь приводиться не будет, но читателям рекомендуется самостоятельно разобраться в нем для лучшего понимания этого атрибута.
В связи с тем, что между SSCLI и .NET Framework отсутствует совместимость на уровне реализации (хотя и имеется совместимость на уровне спецификации CLI от ЕСМА), нельзя проводить какие-либо Эксперименты, заменив атрибут SynchronizationAttribute из .NET кодом из файла synchronizeddispatch.cs. Однако можно полагать, что семантика данного атрибута в .NET и в SSCLI одна и та же.
Как и в .NET, в SSCLI атрибут SynchronizationAttribute определен в пространстве имен Ssystem.Runtime.Remoting.contexts. Реализация данного атрибута представлена следующими классами:
• SynchronizationAttribute
• Workltem
• SynchronizedServerContextSink
• SynchronizedClientContextSink
• AsyncReplySink
Можно надеяться, что после знакомства С атрибутом MyCallTraceAttribute читатель догадывается о семантике почти всех из упомянутых классов. Экземпляры класса WorkItem представляют отдельные поступившие вызовы, сохраняемые в очереди работ. Синхронизация обеспечивается последовательным извлечением и выполнением работ из этой очереди.
Рассмотрим заголовок класса SynchronizationAttribute:
SynchronizationAttribute: ContextAttribute, IContгibuteServerContexts ink, IContributeClientContextSink
Уже отсюда видно, что данный атрибут должен обеспечивать двух перехватчиков. Один будет встроен в цепочку перехватчиков, перехватывающих все поступающие в контекст вызовы, а другой в цепочку, перехватывающих все исходящие за пределы контекста вызовы.
Прежде всего необходимо остановиться на трех понятиях:
• Домен синхронизации
До сих пор мы говорили, что объекты с одинаковыми запросами к множеству доступных автоматических сервисов располагаются в одном контексте. На самом деле это не всегда так. Примером является именно атрибут синхронизации.
Домен синхронизации состоит из одного или нескольких контекстов. Однако даже в случае нескольких контекстов при входе какого-либо потока в любой контекст домена синхронизации доступ для всех остальных потоков в любой контекст данного домена синхронизации заблокирован. Иными словами, все объекты из одного домена синхронизации, даже если они живут в разных контекстах, используют один и тот же сервис синхронизации.
Естественен вопрос — почему нельзя поместить все эти объекты в один контекст? Причина в том, что возможность активации некоторого объекта в некотором старом контексте (в том контексте, в котором выполняется поток, активирующий новый объект), определяется соотношением набора запросов к сервисам со стороны нового объекта и набора сервисов, имеющихся в старом контексте. Старый контекст может быть контекстом синхронизации, новый объект также может требовать синхронного доступа к своим методам. Однако этот новый объект может требовать дополнительного сервиса, например, трассировки вызовов, которого не было в старом контексте. Следовательно, новый объект должен быть активирован в новом контексте, который также должен быть контекстом синхронизации.
Если старый и новый контексты синхронизации независимы, то возможно параллельное обращение к двум объектам из этих двух контекстов. Однако возможны ситуации, когда это недопустимо и необходимо обеспечить синхронный доступ к объектам, принадлежащим разным контекстам.
Например, в случае продажи общего дома семейной парой нельзя параллельно договариваться о продажи дома и с мужем, и с женой, т. к. общий ресурс — дом имеется только в одном экземпляре. Если объекты, представляющие мужа и жену, живут в различных контекстах, то вызов метода продать дом на объекте муж должен блокировать вызов этого же метода на объекте жена.
• Вложенные вызовы
Получив внешний вызов, пересекающий границу любого контекста домена синхронизации, этот домен синхронизации блокируется. Однако возможна ситуация, когда для некоторых новых внешних вызовов блокировка домена синхронизации должна быть снята. Это так называемые вложенные вызовы. При выполнении некоторого внешнего вызова X, поступившего в некоторый контекст домена синхронизации, может быть сделан вызов X1 за пределы этого контекста. При выполнении вызова X1 где-то в другом домене может быть сделан вызов Х2 опять в некоторый контекст данного домена синхронизации. Нельзя блокировать выполнение вызова Х2 до завершения выполнения вызова х, т. к. последний ожидает выполнения вызова X1, который в свою очередь ожидает выполнения вызова Х2. Вся эта цепочка вложенных вызовов образует один так называемый логический вызов, имеющий уникальный идентификатор. По этому идентификатору домен синхронизации распознает вновь пришедший вызов как вложенный вызов и не блокирует его выполнение.
• Реентерабельность
Предположим, что домен синхронизации блокирован на время выполнения вызова X. Пусть в процессе выполнения X был сделан вызов X1 за пределы домена синхронизации. Обычно ни один поток не может выполнить какой-либо работы в данном домене синхронизации пока не будет получен ответ или не придет вложенный вызов для вызова xi. Однако в ряде случаев можно разрешить принимать во время ожидания другие внешние вызовы, никак не связанные с вызовом X. В этом случае домен синхронизации называется реентерабельным (reentrant). Естественно, только разработчик некоторого класса может указать, что экземпляры данного класса могут жить в реентерабельном домене синхронизации. Разработка таких классов способствует повышению эффективности проектируемой системы.