Интернет-журнал "Домашняя лаборатория", 2007 №6
Шрифт:
[Synchronization(REQUIRIES\_NEW, true)]}.
В этом случае формируется новый контекст синхронизации, который начинает собой и новый домен синхронизации. До активации объекта o1 активируется новый экземпляр атрибута синхронизации. В процессе выполнения его конструктора в поле _bReEntrant атрибута синхронизации сохраняется значение true. Таким образом, созданный контекст синхронизации является реентерабельным контекстом.
Предположим теперь, что при выполнении некоторого метода объекта o1 активируется экземпляр о2
Аналогичная проблема возникает, когда первый контекст домена синхронизации формируется под объект, который не должен жить в реентерабельном контексте. В этом случае весь домен синхронизации будет нереентерабельным, и работа с живущими в нем реентерабельными объектами будет менее эффективной, чем это могло бы быть при активации реентерабельных объектов в реентерабельном контексте.
Из этого анализа следует, что в методы IsContextOK и GetPropertiesForNewContext нужно внести изменения, касающиеся реентерабельности. В результате в один домен синхронизации должны помещаться только реентерабельные, либо только нереентерабельные объекты.
Теперь остановимся на том сервисе, который обеспечивает свойство контекста синхронизации (свойство синхронизации). Изложение носит описательный характер, но оно основано на изучении кода атрибута синхронизации.
При поступлении вызова в домен синхронизации (в форме сообщения типа IMessage) это сообщение перехватывается перехватчиком входящих вызовов, определенном в свойстве синхронизации данного домена синхронизации.
Вызов может быть как синхронным, так и асинхронным. В обоих случаях перехватчик входящих вызовов формирует соответствующую данному вызову работу (экземпляр класса WorkItem), в которой сохраняется:
• Само сообщение
• Идентификатор контекста (данного домена синхронизации), в который пришел вызов
• Контекст логического вызова
• Ссылка на перехватчик входящих вызовов, которому нужно передать сообщение для дальнейшей обработки
• Перехватчик результатов, на который нужно послать результат (для асинхронного вызова)
Дальнейшая судьба работы определяется ее типом и наличием в домене синхронизации других работ, ожидающих выполнения:
• Если домен синхронизации нереентерабельный и работа представляет собой вложенный вызов (для синхронного вызова, который сейчас выполняется в данном домене), то данная работа сразу же выполняется без какого-либо ожидания. Заведомо известно, что в данный момент в данном домене синхронизации не выполняется ни один другой поток.
• Если вызов синхронный и не вложенный, а очередь работ, поддерживаемая свойством
• Асинхронный вызов всегда записывается в очередь (даже если она пуста и домен не блокирован).
Работы извлекаются из очереди, если в домене нет исполняемой работы (например, предыдущая работа завершена).
В случае синхронного вызова на всех этапах как до постановки соответствующей работы в очередь, так и после ее извлечения из очереди выполняется один и тот же поток. В случае асинхронного вызова при извлечении работы из очереди выполняется выделенный системой свободный рабочий поток из пула рабочих потоков.
Если в процессе выполнения вызова делается новый вызов из контекста синхронизации за его пределы, этот вызов перехватывается перехватчиком исходящих вызовов. В случае реентерабельного домена синхронизации этот перехватчик уведомляет свойство синхронизации о том, что домен свободен для выполнения новой работы из очереди работ или вновь пришедшего вызова в случае пустой очереди.
Важный практический вывод. Различие между синхронными и асинхронными вызовами состоит в том, что в случае синхронного вызова клиент блокируется в ожидании ответа, а в случае асинхронного не ожидает ответа (его уведомление о результате вызова возлагается на специальный перехватчик). Таким образом разработчик может надеяться на то, что синхронные вызовы могут обрабатываться в домене синхронизации в приоритетном порядке по отношению к асинхронным. Однако в случае реализации атрибута синхронизации в рамках 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