• Если вызов синхронный и не вложенный, а очередь работ, поддерживаемая свойством синхронизации данного домена, пуста и домен синхронизации не блокирован, то такой вызов также сразу же начинает выполняться. При этом домен блокируется для выполнения каких-либо других работ (кроме вложенных вызовов). Все вновь пришедшие во время блокировки домена работы записываются в очередь.

• Асинхронный вызов всегда записывается в очередь (даже если она пуста и домен не блокирован).

Работы извлекаются из очереди, если в домене нет исполняемой работы (например, предыдущая работа завершена).

В случае синхронного вызова на всех этапах как до постановки соответствующей работы в очередь, так и после ее извлечения из очереди выполняется один и тот же поток. В случае асинхронного вызова при извлечении работы из очереди выполняется выделенный системой свободный рабочий поток из пула рабочих потоков.

Если в процессе выполнения вызова делается новый вызов из контекста синхронизации за его пределы, этот вызов перехватывается перехватчиком исходящих вызовов. В случае реентерабельного домена синхронизации этот перехватчик уведомляет свойство синхронизации о том, что домен свободен для выполнения новой работы из очереди работ или вновь пришедшего вызова в случае пустой очереди.

Важный практический вывод. Различие между синхронными и асинхронными вызовами состоит в том, что в случае синхронного вызова клиент блокируется в ожидании ответа, а в случае асинхронного не ожидает ответа (его уведомление о результате вызова возлагается на специальный перехватчик). Таким образом разработчик может надеяться на то, что синхронные вызовы могут обрабатываться в домене синхронизации в приоритетном порядке по отношению к асинхронным. Однако в случае реализации атрибута синхронизации в рамках 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 не только сумму вклада, но и идентификатор процесса, в котором исполняется клиент, сделавший вызов. После этого можно заметить, что оба рабочих потока выполняют вызовы клиентов не зависимо от процесса клиента. Да и число рабочих потоков не связано напрямую с числом клиентов.