Добрынин В.Ю. Технологии компонентного программирования
Подождите немного. Документ загружается.
аргументом является ссылка nextSink на конец имеющейся в данный момент цепочки перехватчиков. В данной
реализации этого метода формируется экземпляр класса
MyCallTraceServerContextSink, который будет прокомментирован ниже. Ссылка на этот экземпляр ( новый
перехватчик) и возвращается как результат вызова
GetServerContextSink.
Данный метод вызывается средой выполнения в случае, когда в новый контекст добавляется новое свойство
контекста, которое при этом реализует интерфейс
IContributeServerContextSink, сигнализируя о том, что нужно
добавить новый перехватчик вызовов.
{ Последний метод (LogMessage) класса MyCallTraceAttribute является внутренним для сборки и будет вызываться из
класса
MyCallTraceServerContextSink. Данный метод обеспечивает запись переданной в качестве аргумента строки
в конец файла с именем, хранящемся в поле
_logFileName свойства типа
MyCallTraceAttribute с именем MyCallTrace текущего контекста. Объекты, живущие в данном контексте, могут
вызывать этот метод явно в своем коде, получив ссылку на это свойство контекста по его имени. Однако в данном
примере будет продемонстрировано использование свойства контекста в стиле аспектно-ориентированного
программирования. Поэтому метод
LogMessage будет в нашем случае вызываться перехватчиком, а не самим
объектом, получившим вызов.
Реализации метода
LogMessage весьма не эффективна. При каждом вызове этого метода файл открывается для записи
в конец, производится запись и файл закрывается. Для обеспечения потокобезопасности весь метод включается в
критическую секцию, препятствующую параллельному выполнению этого метода несколькими потоками. Для этого
методу приписан атрибут [MethodImpl(MethodImplOptions.Synchronized)].
Цикл
while (logFile == null) {
logFile = File.AppendText(_logFileName);
}
обеспечивает выполнение повторных попыток открытия файла до тех пор, пока очередная такая попытка не
увенчается успехом. Не смотря на то, что операции открытия и закрытия файла выполняются в рамках одной
критической секции, в силу асинхронности этих операций открытие файла может произойти с некоторой задержкой
после успешного выполнения команды закрытия файла.
4.
Комментарий к коду класса MyCallTraceContextSink
{ Данный внутренний класс реализует интерфейс IMessageSink и, следовательно, реализует некоторый перехватчик.
{ Поле _nextSink будет хранить ссылку на следующий перехватчик в той цепи перехватчиков, в конец которой будет
добавлен данный перехватчик.
{ Поле _property предназначено для хранения ссылки на свойство контекста типа MyCallTraceAttribute. Перехватчик
порождается благодаря методу
GetPropertiesForNewContext, реализованного этим свойством контекста. Однако
сейчас нам это свойство важно тем, что именно его метод
LogMessage будет вызываться перехватчиком при перехвате
нового вызова.
{ Поле _replyMsg типа IMessage будет хранить ответ вызванного метода, полученный данным перехватчиком от
перехватчика
_nextSink.
{ Конструктор данного класса принимает два аргумента:
property
Это ссылка на свойство контекста, метод которого
LogMessage будет вызываться данным перехватчиком.
nextSink
Это ссылка на следующий перехватчик в цепи перехватчиков.
Данные значения присваиваются соответственно полям
_property и _nextSink.
{ Виртуальный метод SyncProcessMessage объявлен в интерфейсе IMessageSink. Этот метод реализует обработку
синхронных вызовов, т.е. вызовов, после инициализации которых клиенты блокируются до получения ответа.
Единственный аргумент данного метода - сообщение
reqMsg ( request message ), содержащее вызов, полученный от
клиента и уже, возможно, обработанный перехватчиками, находящимися в цепочке ближе к клиенту.
Прежде всего выясняется тип полученного сообщения. Если это сообщение типа
IMethodMessage, то это сообщение
представляет собой именно вызов некоторого метода, который и должен перехватить наш перехватчик. При
получении сообщения другого типа данный перехватчик пропускает его дальше без какой-либо обработки.
Обработка вызова состоит в том, что перехватчик выводит с помощью
LogMessage информацию о типе, о методе и о
входных (
[IN]) аргументах. Пример (слегка отредактированный для удобства просмотра) выводимой информации в
случае вызова метода
Notify экземпляра класса News приведен ниже:
===SPbU.AOP_NET.News, MyServer, Version = 0.0.0.0,
Culture = neutral, PublicKeyToken = null
Notify
<<<IN>>> parameters: (
msg = new Account operation : +5
)
В процессе обработки перехваченного вызова сообщение reqMsg приводится к типу IMethodMessage и блокируется
свойство контекста
_property. Эта блокировка позволит при записи информации в файл посредством вызова
LogMessage группировать все строки, относящиеся к одному вызову, вместе, т.е. не допускать в файле с именем
_logFileName чередования строк, относящихся к различным вызовам.
После завершения обработки перехваченного вызова данный перехватчик передает неизменное сообщение reqMsg
следующему в цепочке перехватчику (перехватчику, находящемуся ближе к серверу). Для этого вызывается метод
SyncProcessMessage перехватчика _nextSink.
После получения сообщения
_replyMsg, содержащего ответ сервера (возможно обработанный перехватчиками,
находящимися ближе к серверу), наш перехватчик в свою очередь обрабатывает это сообщение, если его тип есть
IMethodReturnMessage. В процессе обработки полученное сообщение приводится к типу
IMethodReturnMessage, после чего проверяется, не было ли в процессе выполнения данного вызова инициировано
неперехваченное ранее исключение.
При наличии неперехваченного исключения на консоль сервера выводится соответствующее сообщение и метод
возвращает полученный ответ без какой-либо обработки. В противном случае выполняется процесс, аналогичный
описанному ранее (обработка вызова). Блокируется свойство контекста
_property и посредством вызова метода
_property.LogMessage выводится информация о типе, о вызванном методе, список выходных [out] аргументов.
Ниже приведен пример для ответа на вызов метода
Notify класса News:
===SPbU.AOP_NET.News, MyServer, Version = 0.0.0.0,
Culture = neutral, PublicKeyToken = null
Notify
<<<OUT>>> parameters: (
)
И, наконец, возвращается без изменений сообщение _replyMsg.
{ Виртуальный метод AsyncProcessMessage объявлен в интерфейсе IMessageSink и обязательно должен быть
реализован в данном классе. Этот метод предназначен для обработки асинхронных вызовов, т.е. вызовов, после
инициализации которых клиент не блокируется, а продолжает свою работу.
Данный метод имеет два аргумента:
msg - сообщение типа IMessage, содержащее вызов.
replySink - ссылка на перехватчик, на который надо отсылать результат. Именно этот перехватчик
ответственен за уведомление клиента о полученном результате.
Атрибут
MyCallTraceAttribute не предусматривает обработку асинхронных вызовов, в связи с чем при вызове
данного метода генерируется исключение, уведомляющее об ошибочной операции.
{ Свойство (только для чтения) NextSink также объявлено в интерфейсе IMessageSink и должно быть реализовано в
данном классе. Здесь просто возвращается значение
_nextSink.
Клиентское приложение
Клиентское приложение для рассматриваемого примера почти не отличается от клиентского приложения MyApp.cs из
предыдущей главы. Добавлен вывод на консоль клиента идентификатора контекста клиента, хеш потока и его тип.
using System;
using SPbU.AOP_NET;
using System.Threading;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using System.Net;
public class MyApp {
public static void Main() {
HttpChannel c = new HttpChannel();
ChannelServices.RegisterChannel(c);
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 от
ECMA), нельзя проводить какие-либо эксперименты, заменив атрибут
SynchronizationAttribute из .NET кодом из файла synchronizeddispatch.cs. Однако можно полагать, что семантика данного
атрибута в .NET и в SSCLI одна и та же.
Как и в .NET, в SSCLI атрибут
SynchronizationAttribute определен в пространстве имен System.Runtime.Remoting.Contexts.
Реализация данного атрибута представлена следующими классами:
z SynchronizationAttribute
z WorkItem
z SynchronizedServerContextSink
z SynchronizedClientContextSink
z AsynсReplySink
Можно надеяться, что после знакомства с атрибутом
MyCallTraceAttribute читатель догадывается о семантике почти всех из
упомянутых классов. Экземпляры класса
WorkItem представляют отдельные поступившие вызовы, сохраняемые в очереди работ.
Синхронизация обеспечивается последовательным извлечением и выполнением работ из этой очереди.
Рассмотрим заголовок класса
SynchronizationAttribute:
SynchronizationAttribute : ContextAttribute,
IContributeServerContextSink, IContributeClientContextSink
Уже отсюда видно, что данный атрибут должен обеспечивать двух перехватчиков. Один будет встроен в цепочку перехватчиков,
перехватывающих все поступающие в контекст вызовы, а другой в цепочку, перехватывающих все исходящие за пределы
контекста вызовы.
Прежде всего необходимо остановиться на трех понятиях:
z Домен синхронизации
До сих пор мы говорили, что объекты с одинаковыми запросами к множеству доступных автоматических сервисов
располагаются в одном контексте. На самом деле это не всегда так. Примером является именно атрибут синхронизации.
Домен синхронизации состоит из одного или нескольких контекстов. Однако даже в случае нескольких контекстов при
входе какого-либо
потока в любой контекст домена синхронизации доступ для всех остальных потоков в любой контекст
данного домена синхронизации заблокирован. Иными словами, все объекты из одного домена синхронизации, даже если
они живут в разных контекстах, используют один и тот же сервис синхронизации.
Естественен вопрос - почему нельзя поместить все эти объекты в один
контекст? Причина в том, что возможность
активации некоторого объекта в некотором старом контексте (в том контексте, в котором выполняется поток,
активирующий новый объект), определяется соотношением набора запросов к сервисам со стороны нового объекта и
набора сервисов, имеющихся в старом контексте. Старый контекст может быть контекстом синхронизации, новый объект
также может требовать
синхронного доступа к своим методам. Однако этот новый объект может требовать
дополнительного сервиса, например, трассировки вызовов, которого не было в старом контексте. Следовательно, новый
объект должен быть активирован в новом контексте, который также должен быть контекстом синхронизации.
Если старый и новый контексты синхронизации независимы, то возможно параллельное обращение к двум
объектам из
этих двух контекстов. Однако возможны ситуации, когда это недопустимо и необходимо обеспечить синхронный доступ к
объектам, принадлежащим разным контекстам.
Например, в случае продажи общего дома семейной парой нельзя параллельно договариваться о продажи дома и с мужем, и
с женой, т.к. общий ресурс - дом имеется только в одном экземпляре
. Если объекты, представляющие мужа и жену, живут в
различных контекстах, то вызов метода
ПродатьДом на объекте муж должен блокировать вызов этого же метода на объекте
жена.
z Вложенные вызовы
Получив внешний вызов, пересекающий границу любого контекста домена синхронизации, этот домен синхронизации
блокируется. Однако возможна ситуация, когда для некоторых новых внешних вызовов блокировка домена синхронизации
должна быть снята. Это так называемые вложенные вызовы. При выполнении некоторого внешнего вызова
X, поступившего
в некоторый контекст домена синхронизации, может быть сделан вызов
X1 за пределы этого контекста. При выполнении
вызова
X1 где-то в другом домене может быть сделан вызов X2 опять в некоторый контекст данного домена синхронизации.
Нельзя блокировать выполнение вызова X2 до завершения выполнения вызова X, т.к. последний ожидает выполнения
вызова
X1, который в свою очередь ожидает выполнения вызова X2. Вся эта цепочка вложенных вызовов образует один так
называемый логический вызов, имеющий уникальный идентификатор. По этому идентификатору домен синхронизации
распознает вновь пришедший вызов как вложенный вызов и не блокирует его выполнение.
z Реентерабельность
Предположим, что домен синхронизации блокирован на время выполнения вызова
X. Пусть в процессе выполнения X был
сделан вызов
X1 за пределы домена синхронизации. Обычно ни один поток не может выполнить какой-либо работы в
данном домене синхронизации пока не будет получен ответ или не придет вложенный вызов для вызова
X1. Однако в ряде
случаев можно разрешить принимать во время ожидания другие внешние вызовы, никак не связанные с вызовом
X. В этом
случае домен синхронизации называется реентерабельным (reentrant). Естественно, только разработчик некоторого класса
может указать, что экземпляры данного класса могут жить в реентерабельном домене синхронизации. Разработка таких
классов способствует повышению эффективности проектируемой системы.
Теперь обратимся к конструктору класса
SynchronizationAttribute. Для этого класса имеется четыре конструктора.
Рассмотрим прежде четвертый конструктор, т.к. первые три делегируют вызов четвертому.
public SynchronizationAttribute(int flag, bool reEntrant)
: base(PROPERTY_NAME) {
_bReEntrant = reEntrant;
switch (flag) {
case NOT_SUPPORTED:
case SUPPORTED:
case REQUIRED:
case REQUIRES_NEW:
_flavor = flag;
break;
default:
throw new ArgumentException(
Environment.GetResourceString(
"Argument_InvalidFlag"),
"flag");
}
}
Первый параметр flag принимает одно из четырех возможных значений:
z NOT_SUPPORTED (== 0x00000001)
Данный флаг означает, что экземпляр класса, которому приписан атрибут синхронизации с соответствующим флагом в
конструкторе, не должен активироваться в каком-либо контексте синхронизации.
z SUPPORTED (== 0x00000002)
Данный флаг означает, что разработчик не заботится о том, в каком именно контексте (синхронизации или нет) будет
активирован экземпляр его класса.
z REQUIRED (== 0x00000004)
Данный флаг означает, что экземпляр класса с соответствующим атрибутом всегда должен активироваться в контексте
синхронизации.
z REQUIRES_NEW (== 0x00000008)
Данный флаг означает необходимость создания нового контекста синхронизации для нового экземпляра класса.
Если аргумент
flag содержит какое-либо иное значение, генерируется соответствующее исключение.
Второй логический аргумент равен
true, если экземпляр класса, которому приписан данный атрибут, может жить в
реентерабельном контексте. В противном случае второй аргумент равен
false.
В конструкторе класса
SynchronizationAttribute вызывается конструктор базового класса ContextAttribute с аргументом
PROPERTY_NAME (строковой константой равной "Synchronization"). Именно так называется свойство синхронизации в SSCLI.
Остальные конструкторы определяются через рассмотренный выше:
public SynchronizationAttribute()
: this(REQUIRED, false) {}
public SynchronizationAttribute(bool reEntrant)
: this(REQUIRED, reEntrant) {}
public SynchronizationAttribute(int flag)
: this(flag, false) {}
Теперь рассмотрим важнейший для правильного понимания и использования атрибута синхронизации вопрос - реализацию
методов
IsContextOK и GetPropertiesForNewContext.
Начнем с виртуального метода
IsContextOK, объявленного в интерфейсе IContextAttribute и реализованного в классе
ContextAttribute. В рассматриваемом коде из SSCLI этот метод переопределяется следующим образом:
public override bool IsContextOK(Context ctx,
IConstructionCallMessage msg) {
if (ctx == null)
throw new ArgumentNullException("ctx");
if (msg == null)
throw new ArgumentNullException("msg");
bool isOK = true;
if (_flavor == REQUIRES_NEW) {
isOK = false;
}
else {
SynchronizationAttribute syncProp =
(SynchronizationAttribute) ctx.GetProperty(PROPERTY_NAME);
if ( ( (_flavor == NOT_SUPPORTED)&&(syncProp != null) )
|| ( (_flavor == REQUIRED)&&(syncProp == null) )
) {
sOK = false;
}
if (_flavor == REQUIRED) {
_cliCtxAttr = syncProp;
}
}
return isOK;
}
Таким образом контекст ctx признается непригодным для жизни экземпляра класса описанного с атрибутом синхронизации в
следующих случаях:
1. В конструкторе атрибута был задан флаг
REQUIRES_NEW
2. В контексте
ctx имеется свойство контекста с именем "Synchronization"
типа
SynchronizationAttribute, а в конструкторе атрибута был явно задан флаг NOT_SUPPORTED
3. В контексте
ctx нет свойства контекста с именем "Synchronization" типа SynchronizationAttribute, но при вызове
конструктора атрибута был выбран (явно или неявно) флаг
REQUIRED.
Во всех остальных случаях возвращается
true, т.е. заданный контекст признается пригодным для жизни объекта.
Эти правила определяют условия размещения нового объекта в старом контексте или необходимость формирования нового
контекста. Однако остается вопрос о домене синхронизации. Когда новый контекст, если он был построен, будет включен в тот
домен синхронизации, в который входит контекст
ctx?
Обратим внимание на строки
if (_flavor == REQUIRED) {
_cliCtxAttr = syncProp;
}
Переменная syncProp равна null или ссылке на свойство контекста ctx с именем "Synchronization" типа
SynchronizationAttribute. Таким образом, при заданном флаге REQUIRED в поле _cliCtxAttr типа
SynchronizationAttribute в текущем экземпляре атрибута синхронизации сохраняется ссылка на одноименное свойство
контекста
ctx. Это подготовка к включению нового контекста (если он понадобится) в домен синхронизации, в который уже
входит контекст
ctx. Подробнее этот вопрос будет изложен при комментировании кода метода GetPropertiesForNewContext.
Теперь обратимся к методу
GetPropertiesForNewContext:
public override void GetPropertiesForNewContext(
IConstructionCallMessage ctorMsg) {
if ( (_flavor==NOT_SUPPORTED) || (_flavor==SUPPORTED) ||
(null == ctorMsg) ) {
return ;
}
if (_cliCtxAttr != null) {
ctorMsg.ContextProperties.Add(
(IContextProperty)_cliCtxAttr);
_cliCtxAttr = null;
}
else {
ctorMsg.ContextProperties.Add((IContextProperty)this);
}
}
Метод GetPropertiesForNewContext вызывается системой в том случае, когда старый контекст не пригоден для жизни нового
объекта.
Единственный аргумент
ctorMsg типа IConstructionCallMessage должен быть сообщением, передаваемым со стороны клиента
на сторону сервера и содержащим необходимую информацию об активируемом объекте. Роль рассматриваемого метода состоит в
добавлении в это сообщение дополнительной информации. Именно, добавляется ссылка на объект типа
IContextProperty,
который будет играть роль свойства cсинхронизации нового контекста (свойство типа
SynchronizationAttribute с именем
"Synchronization").
Из приведенного кода видно, что исходное сообщение
ctorMsg никак не меняется, если при задании атрибута был выбран флаг
NOT_SUPPORTED или SUPPORTED, иными словами, если активируемый объект не должен жить в контексте синхронизации или
р
азработчику все равно. В противном случае возможны два варианта:
z _cliCtxAttr == null
Этот случай возникает, когда либо старый контекст не поддерживает сервис синхронизации, либо атрибут синхронизации
был задан с флагом REQUIRES_NEW. В этом случае в качестве ссылки на свойство синхронизации в сообщение ctorMsg
включается ссылка на новый экземпляр атрибута синхронизации, который активируется системой еще до активации нового
объекта. Таким образом получается новый контекст синхронизации, никак не связанный с каким-либо из ранее созданных
контекстов синхронизации. Этот новый контекст синхронизации образует и новый домен синхронизации.
z _cliCtxAttr != null
В этом случае
_cliCtxAttr является ссылкой на свойство синхронизации старого контекста и именно эта ссылка
включается в сообщение
ctorMsg как ссылка на свойство синхронизации нового контекста. Таким образом оба контекста
синхронизации (старый и новый) имеют одно и то же свойство синхронизации. В этом случае говорят, что оба контекста
принадлежат одному домену синхронизации.
Теперь уместно отметить одну особенность домена синхронизации, связанную с реентерабельностью. Предположим, что
активируется экземпляр
o1 некоторого класса, описанного с атрибутом
[Synchronization(REQUIRIES\_NEW, true)]}.
В этом случае формируется новый контекст синхронизации, который начинает собой и новый домен синхронизации. До
активации объекта
o1 активируется новый экземпляр атрибута синхронизации. В процессе выполнения его конструктора в поле
_bReEntrant атрибута синхронизации сохраняется значение true. Таким образом, созданный контекст синхронизации является
реентерабельным контекстом.
Предположим теперь, что при выполнении некоторого метода объекта
o1 активируется экземпляр o2 некоторого класса,
описанного с атрибутом
[Synchronization()]. Это означает, что объект o2 должен жить в контексте синхронизации (флаг
REQUIRED), но не допускается реентерабельность. В зависимости от других атрибутов, приписанных классам, экземплярами
которых являются объекты
o1 и o2, эти объекты будут жить в одном контексте, либо в различных контекстах, но в одном домене
синхронизации. Это определяется тем, что реентерабельность никак не учитывается при определении границ домена
синхронизации. В связи с тем, что все контексты одного домена синхронизации имеют одно на всех свойство контекста с именем
"Synchronization", а это свойство
в рассматриваемом примере разрешает реентерабельность, объект o2 против желания его
разработчика оказывается в реентерабельном контексте, что может привести к ошибке.
Аналогичная проблема возникает, когда первый контекст домена синхронизации формируется под объект, который не должен
жить в реентерабельном контексте. В этом случае весь домен синхронизации будет нереентерабельным, и работа с живущими в
нем реентерабельными объектами будет менее эффективной,
чем это могло бы быть при активации реентерабельных объектов в
реентерабельном контексте.
Из этого анализа следует, что в методы
IsContextOK и
GetPropertiesForNewContext нужно внести изменения, касающиеся реентерабельности. В результате в один домен
синхронизации должны помещаться только реентерабельные, либо только нереентерабельные объекты.
Теперь остановимся на том сервисе, который обеспечивает свойство контекста синхронизации (свойство синхронизации).
Изложение носит описательный характер, но оно основано на изучении кода атрибута синхронизации.
При поступлении вызова в домен синхронизации (в
форме сообщения типа IMessage) это сообщение перехватывается
перехватчиком входящих вызовов, определенном в свойстве синхронизации данного домена синхронизации.
Вызов может быть как синхронным, так и асинхронным. В обоих случаях перехватчик входящих вызовов формирует
соответствующую данному вызову работу (экземпляр класса
WorkItem) , в которой сохраняется:
z Само сообщение
z Идентификатор контекста (данного домена синхронизации), в который пришел вызов
z Контекст логического вызова
z Ссылка на перехватчик входящих вызовов, которому нужно передать сообщение для дальнейшей обработки
z Перехватчик результатов, на который нужно послать результат (для асинхронного вызова)
Дальнейшая судьба работы определяется ее типом и наличием в домене синхронизации других работ, ожидающих выполнения:
z Если домен синхронизации нереентерабельный и работа представляет собой вложенный вызов (для синхронного вызова,
который сейчас выполняется в данном домене), то данная работа сразу же выполняется без какого-либо ожидания.
Заведомо известно, что в данный момент в данном домене синхронизации не выполняется ни один другой поток.
z Если вызов синхронный и не вложенный, а очередь работ, поддерживаемая свойством синхронизации данного домена,
пуста и домен синхронизации не блокирован, то такой вызов также сразу же начинает выполняться. При этом домен
блокируется для выполнения каких-либо других работ (кроме вложенных вызовов). Все вновь пришедшие во время
блокировки домена работы записываются в
очередь.
z Асинхронный вызов всегда записывается в очередь (даже если она пуста и домен не блокирован).
Работы извлекаются из очереди, если в домене нет исполняемой работы (например, предыдущая работа завершена).
В случае синхронного вызова на всех этапах как до постановки соответствующей работы в очередь, так и после ее извлечения из
очереди выполняется один
и тот же поток. В случае асинхронного вызова при извлечении работы из очереди выполняется
выделенный системой свободный рабочий поток из пула рабочих потоков.
Если в процессе выполнения вызова делается новый вызов из контекста синхронизации за его пределы, этот вызов
перехватывается перехватчиком исходящих вызовов. В случае реентерабельного домена синхронизации этот перехватчик
уведомляет свойство синхронизации о том, что домен свободен для выполнения новой работы из очереди работ или вновь
пришедшего вызова в случае пустой очереди.
Важный
практический вывод. Различие между синхронными и асинхронными вызовами состоит в том, что в случае синхронного
вызова клиент блокируется в ожидании ответа, а в случае асинхронного не ожидает ответа (его уведомление о результате вызова
возлагается на специальный перехватчик). Таким образом разработчик может надеяться на то, что синхронные вызовы могут
обрабатываться в
домене синхронизации в приоритетном порядке по отношению к асинхронным. Однако в случае реализации
атрибута синхронизации в рамках SSCLI это не так - попавшие в очередь (единую для всего домена синхронизации) работы
извлекаются из нее в порядке очереди, и тип работы (синхронный или асинхронный вызов) не влияет на этот порядок.
Эксперименты
Эксперименты с вышеописанным кодом должны продемонстрировать работу сервисов синхронизации и трассировки вызовов.
Все компоненты размещаются в одном контексте
Первый эксперимент не требует какой-либо модификации кода клиента и сервера. Каждому компоненту (Account, Tax, News)
приписаны два атрибута:
[Synchronization()]
[MyCallTrace("LogFile")]
Таким образом, все три компонента требует одного и того же набора сервисов и их экземпляры размещаются в одном контексте.
Запустив серверное приложение и параллельно два клиентские приложения, мы увидим на консоли сервера информацию о том,
что все три компонента выполняются в контексте 1.
Ниже приведены несколько первых строк с консоли сервера
Server is listening
News context = 1 News constructor thread = 3 IsPoolThread = True
Tax context = 1 Tax constructor thread = 3 IsPoolThread = True
Account context = 1 Account constructor thread = 3 IsPoolThread = True
Tax notification : new Account operation : +5
Tax Notify thread = 3 IsPoolThread = True
News notification : new Account operation : +5
News Notify thread = 3 IsPoolThread = True
News notification : direct notification from Account
News Notify thread = 3 IsPoolThread = True
Account Add thread = 3 IsPoolThread = True
Tax notification : new Account operation : +5
Tax Notify thread = 65 IsPoolThread = True
News notification : new Account operation : +5
News Notify thread = 65 IsPoolThread = True
News notification : direct notification from Account
News Notify thread = 65 IsPoolThread = True
Account Add thread = 65 IsPoolThread = True
Tax notification : new Account operation : +5
Tax Notify thread = 3 IsPoolThread = True
News notification : new Account operation : +5
News Notify thread = 3 IsPoolThread = True
News notification : direct notification from Account
News Notify thread = 3 IsPoolThread = True
Account Add thread = 3 IsPoolThread = True
. . . . .
Еще одно замечание, связанное с консолью сервера - конструкторы компонентов выполняются в одном рабочем потоке, а далее
эти компоненты вызываются двумя рабочими потоками. Эти потоки, конечно, никак не связаны с клиентами. Можно
модифицировать код клиента и сервера, передавая при вызове метода
Add не только сумму вклада, но и идентификатор процесса,
в котором исполняется клиент, сделавший вызов. После этого можно заметить, что оба рабочих потока выполняют вызовы
клиентов не зависимо от процесса клиента. Да и число рабочих потоков не связано напрямую с числом клиентов.
Модификация кода сервера (
MyServer.cs) связана с добавлением интерфейса IAccumulatorNew:
. . . . .
namespace SPbU.AOP_NET {
public interface IAccumulatorNew{
void Add(int sum, int clientProcessId);
}
. . . . .
public class Account: ContextBoundObject, IAccumulator,
IAudit, IAccumulatorNew{
. . . . .
public void Add(int sum, int clientProcessId){
_sum += sum;
_tax.Notify("new Account operation : +" + sum);
_tax.news.Notify("direct notification from Account");
Console.WriteLine("Account Add thread = " +
Thread.CurrentThread.GetHashCode() +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread +
" clientProcessId ="+ clientProcessId);
}
. . . . .
Необходимая модификация клиента (MyApp.cs) представлена ниже
. . . . .
using System.Diagnostics;
public class MyApp {
public static void Main() {
HttpChannel c = new HttpChannel();
ChannelServices.RegisterChannel(c);
Process p = Process.GetCurrentProcess();
try{
. . . . .
for (int i=0; i<100; i++) {
a.Add(5, p.Id);
}
. . . . .
}
. . . . .
Вот фрагмент вывода на консоль сервера из которого видно, что клиент никак не связан с рабочим потоком, выполняющим его
вызов на сервере.
Account Add thread = 65 IsPoolThread = True clientProcessId =192
Tax notification : new Account operation : +5
Tax Notify thread = 65 IsPoolThread = True
News notification : new Account operation : +5
News Notify thread = 65 IsPoolThread = True
News notification : direct notification from Account
News Notify thread = 65 IsPoolThread = True
Account Add thread = 65 IsPoolThread = True clientProcessId =192
Tax notification : new Account operation : +5
Tax Notify thread = 3 IsPoolThread = True
News notification : new Account operation : +5
News Notify thread = 3 IsPoolThread = True
News notification : direct notification from Account
News Notify thread = 3 IsPoolThread = True
Account Add thread = 3 IsPoolThread = True clientProcessId =165
Tax notification : new Account operation : +5
Tax Notify thread = 3 IsPoolThread = True
News notification : new Account operation : +5
News Notify thread = 3 IsPoolThread = True
News notification : direct notification from Account
News Notify thread = 3 IsPoolThread = True
. . . . .
Еще стоит обратить внимание на то, что рабочий поток, выполняющий вызов метода Add компонента Account, выполняет и
вызовы метода
Notify для компонентов Tax и News, инициированные из компонента Account. Причина в том, что в рамках
данного эксперимента все три компонента находятся в одном контексте синхронизации, и поток, вошедший в этот контекст, не
выходит из него, пока не будут сделаны все вышеупомянутые вызовы. Только после этого другой поток может войти в данный
контекст и начать выполнение метода
Add.
Просмотрев файл
LogFile, в который выполняется запись данных о перехваченных вызовах, можно заметить, что трассируются
только вызовы к компоненту
Account. Это объясняется тем, что именно компонент Account получает вызовы извне контекста (от
клиентов), и эти вызовы перехватываются перехватчиком входящих вызовов атрибута трассировки. Вызовы, которые делаются к
компонентам
Tax и News, идут от компонентов Account и Tax и не пересекают границу контекста. Именно поэтому они и не
перехватываются. Первые строки файла
LogFile представлены ниже:
===SPbU.AOP_NET.Account, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
.ctor
<<<IN>>> parameters: (
)
===SPbU.AOP_NET.Account, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
.ctor
<<<OUT>>> parameters: (
)
===System.MarshalByRefObject, mscorlib, Version=1.0.3300.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089
InitializeLifetimeService
<<<IN>>> parameters: (
)
===System.MarshalByRefObject, mscorlib, Version=1.0.3300.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089
InitializeLifetimeService
<<<OUT>>> parameters: (
)
===clr:SPbU.AOP_NET.Account, MyServer
Add
<<<IN>>> parameters: (
sum= 5
,
clientProcessId= 192
)
===clr:SPbU.AOP_NET.Account, MyServer
Add
<<<IN>>> parameters: (
sum= 5
,
clientProcessId= 165
)
===clr:SPbU.AOP_NET.Account, MyServer
Add
<<<OUT>>> parameters: (
)
===clr:SPbU.AOP_NET.Account, MyServer
Add
<<<OUT>>> parameters: (
)
===clr:SPbU.AOP_NET.Account, MyServer
Add
<<<IN>>> parameters: (
sum= 5
,
clientProcessId= 192
)
===clr:SPbU.AOP_NET.Account, MyServer
Add
<<<OUT>>> parameters: (
)
Компоненты размещаются в двух контекстах, но в одном домене синхронизации
Закомментируем атрибут Synchronization(), приписанный классу Account. Теперь, просматривая вывод на консоль сервера,
можно заметить, что компонент
Account размещается в контексте 1, а компоненты Tax и News в контексте 2:
Server is listening
News context = 2 News constructor thread = 9 IsPoolThread = True
Tax context = 2 Tax constructor thread = 9 IsPoolThread = True
Account context = 1 Account constructor thread = 9 IsPoolThread = True
. . . . .
Просматривая файл LogFile видим, что теперь перехватываются вызовы к компонентам Tax и News, поступающие от компонента
Account:
===SPbU.AOP_NET.Tax, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
.ctor
<<<IN>>> parameters: (
)
===SPbU.AOP_NET.Tax, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
.ctor
<<<OUT>>> parameters: (
)
===SPbU.AOP_NET.Tax, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
Notify
<<<IN>>> parameters: (
msg= new Account operation : +5
)
===SPbU.AOP_NET.Tax, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
Notify
<<<OUT>>> parameters: (
)
===SPbU.AOP_NET.Tax, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
get_news
<<<IN>>> parameters: (
)
===SPbU.AOP_NET.Tax, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
get_news
<<<OUT>>> parameters: (
)
===SPbU.AOP_NET.News, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
Notify
<<<IN>>> parameters: (
msg= direct notification from Account
)
===SPbU.AOP_NET.News, MyServer, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null
Notify
<<<OUT>>> parameters: (
)
В рамках данного эксперимента мы покажем, что оба контекста синхронизации размещаются в одном домене синхронизации.
Для этого необходимо показать, что ссылка на свойство синхронизации во втором контексте указывает на свойство
синхронизации первого контекста, т.е. оба контекста совместно используют одно свойство синхронизации (одну очередь работ и
т.д.).
Внесем в код
сервера следующие дополнения:
namespace SPbU.AOP_NET {
. . . . .
public class Account: ContextBoundObject, IAccumulator,
IAudit, IAccumulatorNew{
. . . . .
public Account() {
. . . . .
SynchronizationAttribute syncProperty =
(SynchronizationAttribute)
Thread.CurrentContext.GetProperty(
"Synchronization");
Console.WriteLine(
"Account syncProperty == Tax syncProperty "+
Object.ReferenceEquals(syncProperty, _tax.syncProperty));
}
. . . . .
}
. . . . .
public class Tax : ContextBoundObject{
. . . . .
private SynchronizationAttribute _syncProperty;
public Tax(){
. . . . .
_syncProperty =
(SynchronizationAttribute)
Thread.CurrentContext.GetProperty(
"Synchronization");
. . . . .
}
. . . . .
internal SynchronizationAttribute syncProperty{
get { return _syncProperty;}
}
. . . . .
}
. . . . .
Просматривая консоль сервера убеждаемся, что ссылки на свойство синхронизации в обоих контекстах (в контексте, в котором
живет компонент
Account и в контексте, в котором живут компоненты Tax и News) указывают на один объект - свойство
синхронизации домена синхронизации:
Server is listening
News context = 2 News constructor thread = 9 IsPoolThread = True
Tax context = 2 Tax constructor thread = 9 IsPoolThread = True
Account context = 1 Account constructor thread = 9 IsPoolThread = True
Account syncProperty == Tax syncProperty True
. . . . .
Компоненты размещаются в трех контекстах и в двух доменах синхронизации
Заменим атрибут синхронизации, приписанный компоненту News следующей его версией:
[Synchronization(0x00000008)]
Задание данного атрибута означает, что компонент News будет располагаться в новом контексте (3), причем этот контекст
образует и новый домен синхронизации. Компоненты
Account и Tax должны располагаться в различных контекстах (1 и 2), но эти
контексты должны входить в один домен синхронизации.
Для проверки этих утверждений внесем еще несколько дополнений в код сервера:
. . . . .
namespace SPbU.AOP_NET {
. . . . .
public class Tax : ContextBoundObject{
. . . . .
public Tax(){
. . . . .
Console.WriteLine(
"Tax syncProperty == News syncProperty "+
Object.ReferenceEquals(_syncProperty,
_news.syncProperty));