Добрынин В.Ю. Технологии компонентного программирования
Подождите немного. Документ загружается.
Остановимся на некоторых вопросах, связанных с делегатами, имеющими отношение к асинхронным вызовам.
Делегаты
sum и mult являются экземплярами ненаследуемых классов, производных от класса System.MulticastDelegate.
Система автоматически формирует эти классы, и, в том числе, реализации их методов
Invoke, BeginInvoke и EndInvoke.
Рассмотрим, для примера, сигнатуры этих методов для делегата
sum:
z public bool Invoke(int, int, out int)
Данный метод может использоваться для синхронного вызова метода
Server::Sum. Первые два аргумента используются
для передачи по значению суммируемых величин, последний - для передачи по ссылке результата, возвращаемое значение
говорит об отсутствии переполнения.
В нашем случае этот метод будет вызван инфраструктурой асинхронных вызовов после инициирования вызова метода
Sum
клиентом.
z public IAsyncResult BeginInvoke(int, int, out int,
AsyncCallback, Object)
Данный метод используется для инициирования асинхронного вызова метода
Server::Sum клиентом.
Смысл первых трех параметров описан в предыдущем пункте.
Четвертый параметр служит для передачи ссылки на делегат типа
AsyncCallback, который будет использоваться
инфраструктурой асинхронных вызовов для вызова callback функции на стороне клиента для уведомления последнего о
завершении вызова. Этот параметр может быть задан как null. В этом случае клиент может использовать другие способы
получения уведомления о завершении вызова.
Последний параметр задает ссылку на некоторый объект, которая будет доступна из объекта, полученного как результат
инициирования асинхронного метода. В данном случае мы будем тут задавать ссылку на делегат
sum. Это позволит клиенту
в рамках callback функции
SumCallback получить доступ к делегату sum и завершить асинхронный вызов, вызвав метод
EndInvoke. Если callback функция не используется, этот параметр можно задать равным null.
Возвращаемое значение типа
IAsyncResult дает клиенту ссылку на объект, который может использоваться последним для
получения информации о выполнении асинхронного вызова. В частности, свойство
bool Completed {get; } интерфейса IAsyncResult может использоваться клиентом для опроса инфраструктуры
асинхронных вызовов - возвращаемое значение равно
true, если вызов завершен. Это один из способов получить
информацию о завершении асинхронного вызова без использования callback функции.
z public bool EndInvoke(out int, IAsyncResult)
Данный метод вызывается клиентом для завершения асинхронного вызова
Server::Sum и получения результатов. В нашем
случае вызов этого метода выполняется в callback функции
SumCallback.
Первый параметр - результат операции сложения, возвращаемое логическое значение равно
true, если в процессе
вычислений не произошло переполнения.
Последний параметр типа
IAsyncResult задается клиентом. Это ссылка, полученная клиентом в результате инициирования
асинхронного вызова путем вызова метода
BeginInvoke.
Клиент. Обработка уведомления о завершении асинхронного вызова
Теперь, обсудив механизм инициирования асинхронного вызова, следует рассмотреть вопрос о обработке уведомления о его
завершении. Остановимся для примера на методе
private static void SumCallback(IAsyncResult ar) { . . . }
Этот метод вызывается инфраструктурой асинхронных вызовов по завершении асинхронного вызова, инициированного в
Client::Main следующим образом:
IAsyncResult arSum = sum.BeginInvoke(3, 4,
out sumResult, sumCallback, sum);
В результате в качестве единственного параметра в SumCallback передается ссылка arSum на объект типа IAsyncResult,
содержащий необходимую клиенту информацию о выполненном асинхронном вызове.
Прежде всего клиент использует полученную ссылку для получения ссылки на делегат
sum:
HardFunction2Args sum =
(HardFunction2Args)ar.AsyncState;
Далее клиент получает результаты завершенного асинхронного вызова
bool result = sum.EndInvoke(out z, ar);
и выводит их на консоль
if (result) Console.WriteLine(
"SumCallback: Sum = " + z);
else Console.WriteLine(
"SumCallback: Bad arguments for Server.Sum");
Все завершается увеличением на 1 статического счетчика workCount, служащего для подсчета числа выполненных асинхронных
вызовов.
Клиент. Что он делает полезного во время ожидания
Вернемся снова к коду в Client::Main. Непосредственно после строк, инициирующих асинхронные вызовы, идет следующий
код:
while (workCount < 2) {
Console.WriteLine("Client thread: count = "+
count++);
Thread.Sleep(100);
}
Именно тут клиент выполняет некоторую работу в ожидании завершения обоих асинхронных вызовов. До тех пор, пока счетчик
числа завершенных асинхронных вызовов
workCount не достигнет значения 2, клиент выводит на консоль очередное
положительное целое с интервалом в 100 mc.
Результаты приведены ниже:
Client thread =16; PoolThread = False
Client thread: count = 0
Server (Sum method) thread =25; PoolThread = True
Client thread: count = 1
Client thread: count = 2
Client thread: count = 3
Client thread: count = 4
Client thread: count = 5
Server (MultBy2 method) thread =27; PoolThread = True
Client thread: count = 6
Client thread: count = 7
Client thread: count = 8
Client thread: count = 9
Client thread: count = 10
SumCallback: Sum = 7
Client thread: count = 11
Client thread: count = 12
Client thread: count = 13
Client thread: count = 14
Client thread: count = 15
MultCallback: MultBy2 = 10
Bye!
Обсуждение результатов:
z Видно, что клиентский поток не является потоком из пула рабочих потоков.
z Серверные методы (Sum и MultBy2) выполняются асинхронно в различных рабочих потоках.
z Во время выполнения асинхронного вызова (от его инициирования до вызова соответствующей callback функции должно
пройти 1000 mc) клиент успевает вывести на консоль 10 строк с очередными значениями переменной
count.
z Завершается основной поток по завершении последнего асинхронного вызова. Это обеспечивается за счет подсчета числа
завершенных вызовов. Заметим, что рабочий поток не может пережить основной поток. Если бы основной поток не
контролировал завершение рабочих потоков и завершился бы раньше, то не завершенные рабочие потоки были бы
уничтожены.
z Выполнение второго асинхронного вызова начинается с некоторой задержкой. Это связано с тем, что при наличии непустой
очереди работ новый рабочий поток формируется через 500 mc после возникновения необходимости в нем. Ранее
созданный поток уничтожается, если он никому не понадобился в течении 30 c. Общее число потоков в пуле не должно
превышать 25 (на один процесс).
Немного про контекст вызова
Понятие логического вызова связано с цепочкой вызовов, инициирующих друг друга. Эта цепочка может пересекать границы
между контекстами, доменами приложений, процессами и машинами. Все вызовы в этой цепочке связаны одним
идентификатором - идентификатором логического вызова, что позволяет системе отличать вызовы, относящиеся к различным
логическим цепочкам.
С каждым вызовом обычно связана передача некоторых входных
и выходных параметров и возвращаемого значения. Кроме того,
с вызовом можно связать дополнительный набор свойств, передаваемый от вызывающей стороне вызываемой стороне и обратно -
от вызываемой стороны вызывающей стороне. Этот набор свойств называется контекстом вызова. Использование контекста
вызова позволяет клиенту и серверу обмениваться данными, не объявленными явно в сигнатуре вызываемого метода.
При
определенных условиях контекст вызова может пересекать границы между контекстами, доменами приложений, процессами и
машинами, сопровождая логический вызов. На каждом этапе можно добавлять в контекст вызова новые свойства, получать их
значения и/или удалять старые свойства.
Свойство контекста вызова состоит из пары (имя свойства, значение свойства). Имя свойства должно иметь
тип System.String,
а в качестве его значения можно задать ссылку на любой объект (производный от
System.Object). Если предполагается передача контекста вызова через границу контекста, домена приложения, процесса,
машины, значение каждого передаваемого свойства должно быть экземпляром класса, определенного с атрибутом
Serializable
и производного от
ILogicalThreadAffinative. Определение интерфейса ILogicalThreadAffinative не содержит никаких методов и
данный интерфейс используется просто как маркер классов, допускаемых для передачи в контексте вызова за пределы контекста,
домена приложения и т.п.
Реально контекст вызова передается через ранее упомянутые границы в форме сообщения типа IMessage. В связи с этим и
требуется сериализуемость всех передаваемых объектов (т.е. возможность их передачи по значению).
Ниже представлен пример, демонстрирующий применение контекста вызова, пересекающего границу между процессами. За
основу взят многократно рассмотренный пример, связанный с перечислением 5 условных единиц со стороны клиента на счет,
поддерживаемый сервером.
Рассмотрим прежде всего код
сервера.
Сервер
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using System.Threading;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Messaging;
using System.Reflection;
namespace MyServer {
[Serializable]
public class MyCallContextUserName :
ILogicalThreadAffinative {
private String _userName;
public MyCallContextUserName() {
_userName = Environment.UserName;
}
public String UserName {
get { return _userName;}
}
}
[Serializable]
public class MyCallContextServerName :
ILogicalThreadAffinative {
private Assembly _assembly;
private String _serverName;
public MyCallContextServerName() {
_assembly = Assembly.GetExecutingAssembly();
_serverName = _assembly.FullName;
}
public String ServerName {
get { return _serverName;}
}
}
public interface IAccumulator{
void Add(int sum);
}
public interface IAudit{
int Total();
}
[Synchronization()]
public class Account: ContextBoundObject,
IAccumulator, IAudit{
protected int sum = 0;
public void Add(int sum){
this.sum += sum;
MyCallContextUserName userName =
(MyCallContextUserName)CallContext.GetData(
"UserName");
Console.WriteLine("UserName = " +
userName.UserName);
CallContext.SetData("ServerName",
new MyCallContextServerName());
}
public int Total(){
return this.sum;
}
}
public class AccountApp {
public static void Main(){
HttpChannel myChannel = new HttpChannel(8080);
ChannelServices.RegisterChannel(myChannel);
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(Account), "Account",
WellKnownObjectMode.Singleton);
Console.WriteLine("Server is listening");
Console.ReadLine();
Console.WriteLine("Bye");
}
}
}
Относительно этого кода можно сделать следующие комментарии.
В методе
Add наш сервер будет не только получать очередной вклад и зачислять его на счет, но и работать с контекстом вызова.
Во-первых, предполагается, что клиент перед вызовом метода
Add добавил в контекст вызова свойство с именем UserName.
Соответствующее значение содержит учетные данные пользователя, от имени которого было запущено клиентское приложение.
Значение свойства
UserName задается ссылкой на экземпляр класса
[Serializable]
public class MyCallContextUserName :
ILogicalThreadAffinative { . . . }
Из определения этого класса видно, что его экземпляры могут передаваться в контексте вызова за пределы текущего контекста,
т.к. этот класс определяется с атрибутом сериализации и наследует интерфейс
ILogicalThreadAffinative.
Конструктор данного класса
public MyCallContextUserName() {
_userName = Environment.UserName;
}
сохраняет в строковом поле _userName значение соответствующей переменной среды, получаемой как статическое свойство
UserName класса Environment.
Используя свойство
UserName контекста вызова сервер в методе Add выясняет имя пользователя и выводит его на консоль:
MyCallContextUserName userName =
(MyCallContextUserName)CallContext.GetData("UserName");
Console.WriteLine("UserName = " +
userName.UserName);
Для доступа к нужному свойству используется статический метод GetData класса CallContext, которому в качестве параметра
передается имя свойства. Полученное значение приводится к типу
MyCallContextUserName.
Во-вторых, получив и выведя на консоль имя пользователя, сервер заканчивает выполнение метода
Add, включая в контекст
вызова свою информацию. Эту новую информацию сможет получить клиент, дождавшийся возврата из метода
Add.
Итак, сервер добавляет в контекст вызова новое свойство с именем
ServerName:
CallContext.SetData("ServerName",
new MyCallContextServerName());
Класс MyCallContextServerName определяется аналогично классу
MyCallContextUserName.
Основная функциональность этого класса определяется его конструктором:
public MyCallContextServerName() {
_assembly = Assembly.GetExecutingAssembly();
_serverName = _assembly.FullName;
}
Здесь мы получаем ссылку на исполняемую сборку (т.е. на сборку сервера) и сохраняем в _serverName ее полное имя.
Остальная часть кода сервера не претерпела каких-либо изменений.
Клиент
using System;
using MyServer;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using System.Net;
using System.Runtime.Remoting.Messaging;
public class MyApp {
public static void Main() {
HttpChannel c = new HttpChannel();
ChannelServices.RegisterChannel(c);
try{
Account a = (Account)Activator.GetObject(
typeof(Account),
"http://localhost:8080/Account",
WellKnownObjectMode.Singleton);
CallContext.SetData("UserName",
new MyCallContextUserName());
a.Add(5);
Console.WriteLine("5 is sent to " +
((MyCallContextServerName)CallContext.GetData(
"ServerName")).ServerName);
Console.WriteLine("Total = " +a.Total());
}
catch(WebException e){
Console.WriteLine(e.Message);
}
catch(Exception e){
Console.WriteLine(e.Message);
}
finally{
Console.WriteLine("Bye");
}
}
}
Все отличие данного кода клиента от рассмотренных ранее примеров представлено в следующих строках
CallContext.SetData("UserName",
new MyCallContextUserName());
a.Add(5);
Console.WriteLine("5 is sent to " +
((MyCallContextServerName)CallContext.GetData(
"ServerName")).ServerName);
Перед вызовом метода Add клиент добавляет в контекст вызова уже рассмотренное свойство UserName. В результате, при
выполнении вызова
Add, сервер получает доступ к учетным данным пользователя, от имени которого было запущено клиентское
приложение, и может принимать решение о выполнении данного вызова.
По завершении вызова метода
Add клиент получает из свойства контекста значение свойства ServerName, добавленное в контекст
вызова сервером при выполнении
Add. В результате клиент получает информацию о сборке, содержащей код сервера,
выполнившего вызов.
Результаты
Ниже приведен вывод на консоль сервера. Видно, что сервер получил информацию о том, что клиентское приложение было
запущено Администратором.
Server is listening
UserName = Администратор
Bye
А вот и вывод на консоль клиента:
5 is sent to MyServer, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null
Total = 5
Bye
Возвращаемся к классу WorkItem
Конструктор
Конструктор в качестве входных параметров принимает вызов в форме сообщения (reqMsg), ссылку на следующий перехватчик,
которому будет переадресован данный вызов после того, как он отстоит всю очередь (
nextSink) и ссылку на перехватчик для
результатов асинхронного вызова (
replySink). В случае синхронного вызова последний параметр задается равным null.
Ниже приведен код конструктора:
internal WorkItem(IMessage reqMsg, IMessageSink nextSink,
IMessageSink replySink) {
_reqMsg = reqMsg;
_replyMsg = null;
_nextSink = nextSink;
_replySink = replySink;
_ctx = Thread.CurrentContext;
_callCtx = CallContext.GetLogicalCallContext();
}
Судя по приведенному коду, этот конструктор вызывается в том контексте, в котором в последствии будет выполняться вызов,
инкапсулируемый в данный момент в экземпляр класса
WorkItem. Об этом говорят строки, в которых присваиваются значения
полям
_ctx и _callContext. Вызов Thread.CurrentContext возвращает текущий контекст (ссылку на экземпляр класса Context),
а вызов
CallContext.GetLogicalCallContext возвращает контекст логического вызова (ссылку на экземпляр класса
LogicalCallContext), соответствующие текущим контексту и потоку. Здесь следует отметить, что в .NET Framework класс
CallContext не реализует метод GetLogicalCallContext.
Итак, конструктор класса
WorkItem должен вызываться в перехватчике, ассоциированном со свойством синхронизации, и этот
перехватчик должен выполняться в том контексте и в потоке с таким контекстом вызова, в котором и с которым будет
выполняться сам перехваченный вызов.
Флаги
В течении своей жизни работа, представляющая некоторый вызов, может находиться в одном из несколькольких состояний. Эти
состояния задаются наборами флагов :
private const int FLG_WAITING = 0x0001;
private const int FLG_SIGNALED = 0x0002;
private const int FLG_ASYNC = 0x0004;
private const int FLG_DUMMY = 0x0008;
Флаг FLG_WAITING означает, что работа поставлена в очередь, флаг
FLG_SIGNALED указывает на то, что первая в очереди работа начинает исполняться, флаг FLG_ASYNC помечает асинхронные работы
(работы, представляющие асинхронные вызовы), и, наконец, флаг
FLG_DUMMY помечает работу-заглушку. Этот флаг помечает
фиктивную работу, формируемую для представления результата внешнего вызова, сделанного при выполнении текущего вызова.
Подробнее об этом будет говориться далее.
Текущая комбинация флагов сохраняется в поле
internal int _flags, для задания и чтения которого используются следующие
методы:
internal virtual void SetWaiting() {
_flags |= FLG_WAITING;
}
internal virtual bool IsWaiting() {
return (_flags&FLG_WAITING) == FLG_WAITING;
}
internal virtual void SetSignaled() {
_flags |= FLG_SIGNALED;
}
internal virtual bool IsSignaled() {
return (_flags & FLG_SIGNALED) == FLG_SIGNALED;
}
internal virtual void SetAsync() {
_flags |= FLG_ASYNC;
}
internal virtual bool IsAsync() {
return (_flags & FLG_ASYNC) == FLG_ASYNC;
}
internal virtual void SetDummy() {
_flags |= FLG_DUMMY;
}
internal virtual bool IsDummy() {
return (_flags & FLG_DUMMY) == FLG_DUMMY;
}
Выполнение работы
Самый важный метод класса WorkItem - это метод Execute, обеспечивающий выполнение текущей работы. Этот метод
вызывается в тот момент, когда подошла очередь выполнения этой работы.
internal virtual void Execute() {
ContextTransitionFrame frame = new ContextTransitionFrame();
Thread.CurrentThread.EnterContext(_ctx, ref frame);
LogicalCallContext oldCallCtx =
CallContext.SetLogicalCallContext(_callCtx);
if (IsAsync()) {
_nextSink.AsyncProcessMessage(_reqMsg, _replySink);
}
else if (_nextSink != null) {
_replyMsg = _nextSink.SyncProcessMessage(_reqMsg);
}
CallContext.SetLogicalCallContext(oldCallCtx);
Thread.CurrentThread.ReturnToContext(ref frame);
}
Метод Execute может выполняться в различных контекстах и потоках, поэтому прежде всего нужно восстановить ту среду, в
которой находился вызов в момент его перехвата и инкапсулирования в работу типа
WorkItem.
Для этого формируется фрейм, сохраняющий некоторую информацию о переходе их одного контекста в другой контекст (эта
информация позже используется для возвращения в контекст, в котором началось исполнение метода
Execute) и выполняется
переход из текущего контекста в контекст, сохраненный в поле
_ctx:
ContextTransitionFrame frame = new ContextTransitionFrame();
Thread.CurrentThread.EnterContext(_ctx, ref frame);
Отметим, что в .NET Framework нет класса ContextTransitionFrame, а в сигнатуре класса Thread нет метода EnterContext.
Далее сохраняется текущий контекст вызова в
oldCallContext, а с текущим потоком связывается тот контекст вызова, который
был сохранен в поле
_callContext :
LogicalCallContext oldCallCtx =
CallContext.SetLogicalCallContext(_callCtx);
К сожалениею, в сигнатуре класса CallContext в .NET Framework нет метода SetLogicalCallContext.
Теперь все готово для обработки вызова, который до сих пор хранился в экземпляре класса
WorkItem. Как уже говорилось ранее,
вся функциональность свойства синхронизации сводится к поддержанию очереди работ. Для текущей работы функция свойства
синхронизации исчерпана. Работа отстояла в очереди и пришло время отправить инкапсулированный в ней вызов дальше, т.е.
следующему перехватчику.
Интерфейс
IMessageSink объявляет два метода, реализующие обработку соответственно синхронных и асинхронных вызовов.
Это
SyncProcessMessage и AsyncProcessMessage.
Таким образом, в зависимости от типа текущей работы (инкапсулированного в ней вызова), необходимо вызвать один из
упомянутых вызовов на следующем перехватчике:
if (IsAsync()) {
_nextSink.AsyncProcessMessage(_reqMsg, _replySink);
}
else if (_nextSink != null) {
_replyMsg = _nextSink.SyncProcessMessage(_reqMsg);
}
Вызов IsAsync возвращает true если текущая работа асинхронна. В этом случае на следующем перехватчике _nextSink
вызывается
AsyncProcessMessage и в качестве параметров передаются исходный вызов _reqMsg и ссылка на перехватчик для возвращения
результата
_replySink.
В случае синхронной работы вызывается
SyncProcessMessage. Параметром является вызов, возвращаемое значение сохраняется
в поле
_replyMsg.
Говоря про синхронные и асинхронные работы стоит напомнить, что в случае синхронной работы текущий поток блокируется до
возврата из метода
SyncProcessMessage, т.е. до завершения прохождения вызова по всем остальным перехватчикам, собственно
его выполнения и возвращения результата по той же цепочки перехватчиков. В случае асинхронной работы текущий поток не
ожидает завершения вызова.
И, наконец, текущий поток должен вернуться в старый контекст и связаться со старым контекстом вызова:
CallContext.SetLogicalCallContext(oldCallCtx);
Thread.CurrentThread.ReturnToContext(ref frame);
Завершая обсуждение класса WorkItem осталось упомянуть свойство
ReplyMessage, с помощью которого можно получить ответ, возвращенный для синхронного вызова:
internal virtual IMessage ReplyMessage {
get {return _replyMsg;}
}
Извлечение работы из очереди и ее выполнение
Напомним, что вызовы, перехваченные перехватчиком, ассоциированным со свойством синхронизации, инкапсулируются в
р
аботу (экземпляр класса WorkItem) и записываются в очередь работ (_workItemQueue). Эта очередь поддерживается свойством
синхронизации, и мы уже говорили об ее инициализации как составной части процесса инициализации свойства синхронизации в
целом. Тогда же говорилось о том, что в пуле рабочих потоков регистрируется делегат callBackDelegate типа
WaitOrTimerCallBack, который будет вызываться и выполняться некоторым рабочим потоком всякий раз, когда будет
установлено в состояние signaled событие
_asyncWorkEvent.
Забегая вперед можно сказать, что это событие будет устанавливаться в состояние signaled всякий раз, когда можно будет
начинать выполнение очередной работы из очереди работ, причем эта работа должна имееть асинхронный тип (инкапсулирует
асинхронный вызов). В этом случае свободный или вновь сгенерированный рабочий поток начнет выполнять данную
асинхронную работу путем вызова упомянутого
делегата.
Делегат
callBackDelegate содержит ссылку на функцию
DispatcherCallBack :
WaitOrTimerCallback callBackDelegate =
new WaitOrTimerCallback(this.DispatcherCallBack);
и именно эта функция будет выполняться в рабочем потоке, обрабатывая очередную асинхронную работу.
Кстати, эта же функция будет вызываться и в том случае, когда очередная работа имеет синхронный тип (инкапсулирует
синхронный вызов). Правда, в этом случае она будет выполняться в потоке вызова, а не в произвольном рабочем потоке из пула
потоков
, как было при асинхронном вызове. Но об этом позже.
Код функции
DispatcherCallBack представлен ниже:
private void DispatcherCallBack(Object stateIgnored,
bool ignored) {
WorkItem work;
lock (_workItemQueue) {
work = (WorkItem) _workItemQueue.Dequeue();
}
ExecuteWorkItem(work);
HandleWorkCompletion();
}
В соответствии с определением типа WaitOrTimerCallBack функция
DispatcherCallBack имеет два параметра. Входной параметр типа Object (третий параметр при вызове
ThreadPool.RegisterWaitForSingleObject, в нашем случае null) используется для задания подлежащей обработке
информации. Выходной параметр типа
bool принимает значение true в том случае, если вызов зарегистрированного в пуле
рабочих потоков соответствующего делегата (в нашем случае
callBackDelegate) произошел по причине истечения времени
ожидания (в нашем случае это значение поля
_timeOut). Если же вызов упомянутого делегата произошел в связи с тем, что
зарегистрированное в этом же пуле событие типа
AutoResetEvent (в нашем случае _asyncWorkEvent) перешло в состояние
signaled, то второй параметр принимает значение
false. В нашем случае оба эти параметра не учитываются.
Выполнение вызова DispatcherCallBack начинается с входа в критическую секцию, доступную при успешной блокировке
объекта
_workItemQueue. В результате, при работе в данной критической секции с очередью работ, поддерживаемой текущим
свойством синхронизации, никакой другой код не сможет заблокировать эту очередь и параллельно начать с ней работать.
Единственной операцией, выполняемой в данной критической секции, является извлечение из очереди работ очередной работы (с
удалением из очереди). Здесь предполагается, что
все необходимые для этого условия уже выполнены. О том, каковы эти
условия, мы будем говорить позже.
После выхода из критической секции (освобождающего очередь работ для других потоков), вызываются последовательно
ExecuteWorkItem(work) и HandleWorkCompletion().
Реализация метода
ExecuteWorkItem в рассматриваемом классе
SynchronizationAttribute очень проста:
internal void ExecuteWorkItem(WorkItem work) {
work.Execute();
}
Тут все сводится к уже рассмотренному методу Execute класса WorkItem. Иными словами, исполняющий этот метод поток
переходит в тот контекст, где должен будет выполняться вызов, с этим потоком связывается тот самый контекст вызова, который
сопровождал этот вызов до его перехвата. После этого вызов передается следующему перехватчику, который будет его
обрабатывать в зависимости от типа вызова (синхронный или асинхронный). В случае
асинхронного вызова сразу же после этого
происходит возврат потока в исходный контекст и восстанавливается его связь с исходным контекстом вызова. В случае
синхронного вызова происходит тоже самое, но только после возврата ответа.
Вызов метода
HandleWorkCompletion() должен выполнить некоторую подготовительную работу к выполнению следующей
работы из очереди работ. Мы рассмотрим этот метод позже. Сейчас же следует начать с начала, т.е. рассмотреть весь процесс
перехвата вызова и включения его в очередь (или, в некоторых случаях, исполнения без включения в очередь).
Перехват входящего вызова
Формирование перехватчика входящих вызовов
Класс SynchronizationAttribute реализует интерфейс
IContributeServerContextSink. Благодаря этому факту, при формировании нового контекста синхронизации (в новом или в
старом домене синхронизации) автоматически вызывается метод
GetServerContextSink, объявленный в данном интерфейсе, для
формирования перехватчика входящих вызовов для данного контекста. Ниже приводится код этого метода из Rotor:
public virtual IMessageSink GetServerContextSink(
IMessageSink nextSink) {
InitIfNecessary();
SynchronizedServerContextSink propertySink =
new SynchronizedServerContextSink(
this,
nextSink);
return (IMessageSink) propertySink;
}
Единственным входным параметром является ссылка на перехватчик, последний на данный момент в цепочке перехватчиков
входящих вызовов для данного контекста. Возвращаемое значение является ссылкой на новый перехватчик, который будет
добавлен в эту цепочку.
Прежде всего выполняется инициализация свойства синхронизации, если это необходимо. Метод
InitIfNeccessary был
рассмотрен ранее. Реально он будет выполнять инициализацию свойства синхронизации только в том случае, когда текущий
контекст является первым контекстом домена синхронизации. В противном случае свойство синхронизации уже было
инициализировано ранее.
Далее формируется экземпляр класса
SynchronizedServerContextSink, который будет рассмотрен позже. Этот объект и будет
выступать в роли перехватчика входящих вызовов. Ему передаются два параметра:
z this - ссылка на свойство синхронизации (экземпляр данного класса SynchronizationAttribute) - новое или ранее
сформированное, живущее в первом контексте домена синхронизации
z nextSink - ссылка на следующий в цепочке перехватчик.
И, наконец, возвращается полученная ссылка на новый перехватчик.
Таким образом, хотя свойство синхронизации одно на весь домен синхронизации, для каждого контекста в этом домене
формируется свой перехватчик, имеющий ссылку на это свойство синхронизации.
Как перехватчик обрабатывает синхронные вызовы
Теперь рассмотрим класс SynchronizedServerContextSink:
internal class SynchronizedServerContextSink
: InternalSink, IMessageSink { . . . . . }
Мы видим, что данный класс наследует классу InternalSink и реализует интерфейс IMessageSink. Класс InternalSink
отсутствует в .NET. Интерфейс
IMessageSink объявляет методы, которые должны быть реализованы перехватчиками всех типов.
Класс
SynchronizedServerContextSink содержит два поля данных:
internal IMessageSink _nextSink;
internal SynchronizationAttribute _property;
Первое содержит ссылку на следующий перехватчик, а второе - на свойство синхронизации текущего домена синхронизации.
Единственный конструктор инициирует эти поля:
internal SynchronizedServerContextSink(
SynchronizationAttribute prop,
IMessageSink nextSink) {
_property = prop;
_nextSink = nextSink;
}
Каждый перехватчик должен обеспечить обработку как синхронных, так и асинхронных вызовов. Соответствующие методы
объявлены в интерфейсе
IMessageSink. Это SyncProcessMessage и AsyncProcessMessage.
В данном перехватчике обработка синхронных вызовов осуществляется следующим образом:
public virtual IMessage SyncProcessMessage(IMessage reqMsg) {
WorkItem work = new WorkItem(reqMsg,
_nextSink,
null);
_property.HandleWorkRequest(work);
return work.ReplyMessage;
}
Собственно вызов в форме сообщения типа IMessage передается как единственный входной параметр. Возвращаемое значение
(также типа
IMessage) содержит результат, полученный данным перехватчиком от следующего в цепочки перехватчика после того, как вызов
пройдет через всю цепочку перехватчиков до сервера, будет обработан на сервере, а ответ от него пройдет через всю цепочку
перехватчиков в обратном направлении до данного перехватчика. Тут надо заметить, что на этом пути в каком-либо
промежуточном перехватчике вызов может быть преобразован в асинхронную форму.
Роль данного перехватчика состоит в инкапсуляции вызова в объект типа
WorkItem и его сохранении в очереди работ. Для этого
вызывается конструктор
WorkItem(reqMsg, _nextSink, null), первые два параметра которого задают вызов в форме сообщения
и ссылку на следующий перехватчик. Третий параметр используется только в случае асинхронных вызовов. По умолчанию
инкапсулирующая вызов работа
work относится к синхронному типу.
После инкапсуляции вызова соответствующая работа передается свойству синхронизации:
_property.HandleWorkRequest(work);
Метод HandleWorkRequest класса SynchronizationAttribute ответственен за запись инкапсулированного вызова в очередь
работ, за своевременное извлечение его из очереди и передачу следующему перехватчику, и, наконец, за получение ответа. Ответ
доступен через свойство ReplyMessage работы, инкапсулирующей вызов. Значение этого свойства и возвращается как результат
вызова метода
SyncProcessMessage.
Как свойство синхронизации обрабатывает инкапсулированный синхронный
вызов, полученный от перехватчика
Теперь временно прервем процесс изучение класса
SynchronizedServerContextSink и рассмотрим метод HandleWorkRequest класса SynchronizationAttribute. Ниже приведена
часть кода этого метода, которая относится к обработке именно синхронных вызовов:
internal virtual void HandleWorkRequest(WorkItem work) {
bool bQueued;
if (!IsNestedCall(work._reqMsg)) {
if (work.IsAsync()) {
. . . . .
}
else {
lock(work) {
lock(_workItemQueue) {
if ((!_locked) &&
(_workItemQueue.Count == 0)) {
_locked = true;
bQueued = false;
}
else {
bQueued = true;
work.SetWaiting();
_workItemQueue.Enqueue(work);
}
}
if (bQueued == true) {
Monitor.Wait(work);
if (!work.IsDummy()) {
DispatcherCallBack(null, true);
}
else {
lock(_workItemQueue) {
_workItemQueue.Dequeue();
}
}
}
else {
if (!work.IsDummy()) {
work.SetSignaled();
ExecuteWorkItem(work);
HandleWorkCompletion();
}
}
}
}
}
else {
work.SetSignaled();
work.Execute();
}
}
Прежде всего выясняется - является ли инкапсулированный вызов
work._reqMsg вложенным вызовом, т.е. вызовом, инициированным в процессе выполнения выполняемого в данный момент
синхронного или исходящего асинхронного вызова:
if (!IsNestedCall(work._reqMsg)) { . . . . .