"flag");
}
}
Первый параметр flag принимает одно из четырех возможных значений:
• NOT_SUPPORTED (== 0x00000001)
Данный флаг означает, что экземпляр класса, которому приписан атрибут синхронизации с соответствующим флагом в конструкторе, не должен активироваться в каком-либо контексте синхронизации.
• SUPPORTED (== 0x00000002)
Данный флаг означает, что разработчик не заботится о том, в каком именно контексте (синхронизации или нет) будет активирован экземпляр его класса.
• REQUIRED (== 0x00000004)
Данный флаг означает, что экземпляр класса с соответствующим атрибутом всегда должен активироваться в контексте синхронизации.
• 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, который будет играть роль свойства синхронизации нового контекста (свойство типа SynchronizationAttribute с именем "Synchronization").
Из приведенного кода видно, что исходное сообщение ctorMsg никак не меняется, если при задании атрибута был выбран флаг not_supported или supported, иными словами, если активируемый объект не должен жить в контексте синхронизации или разработчику все равно.
В противном случае возможны два варианта:
• _cliCtxAttr == null
Этот случай возникает, когда либо старый контекст не поддерживает сервис синхронизации, либо атрибут синхронизации был задан с флагом REQUIRES_NEW. В этом случае в качестве ссылки на свойство синхронизации в сообщение ctorMsg включается ссылка на новый экземпляр атрибута синхронизации, который активируется системой еще до активации нового объекта. Таким образом получается новый контекст синхронизации, никак не связанный с каким-либо из ранее созданных контекстов синхронизации. Этот новый контекст синхронизации образует и новый домен синхронизации.
• _cliCtxAttr!= null
В этом случае cliCtxAttr является ссылкой на свойство синхронизации старого контекста и именно эта ссылка включается в сообщение ctorMsg как ссылка на свойство синхронизации нового контекста. Таким образом оба контекста синхронизации (старый и новый) имеют одно и то же свойство синхронизации. В этом случае говорят, что оба контекста принадлежат одному домену синхронизации.
Теперь уместно отметить одну особенность домена синхронизации, связанную с реентерабельностью. Предположим, что активируется экземпляр o1 некоторого класса, описанного с атрибутом
[Synchronization(REQUIRIES\_NEW, true)]}.
В этом случае формируется новый контекст синхронизации, который начинает собой и новый домен синхронизации. До активации объекта o1 активируется новый экземпляр атрибута синхронизации. В процессе выполнения его конструктора в поле _bReEntrant атрибута синхронизации сохраняется значение true. Таким образом, созданный контекст синхронизации является реентерабельным контекстом.
Предположим теперь, что при выполнении некоторого метода объекта o1 активируется экземпляр о2 некоторого класса, описанного с атрибутом [synchronization ()]. Это означает, что объект о2 должен жить в контексте синхронизации (флаг required), но не допускается реентерабельность. В зависимости от других атрибутов, приписанных классам, экземплярами которых являются объекты o1 и о2, эти объекты будут жить в одном контексте, либо в различных контекстах, но в одном домене синхронизации. Это определяется тем, что реентерабельность никак не учитывается при определении границ домена синхронизации. В связи с тем, что все контексты одного домена синхронизации имеют одно на всех свойство контекста с именем "Synchronization", а это свойство в рассматриваемом примере разрешает реентерабельность, объект о2 против желания его разработчика оказывается в реентерабельном контексте, что может привести к ошибке.