Поскольку ОС Windows не имеет встроенных средств понимания формата компоновочных блоков .NET, полезно знать, что происходит в фоновом режиме, когда активизируется выполняемый компоновочный блок. В ОС Windows XP основными шагами будут следующие (вспомните из главы 11, что все компоновочные блоки .NET содержат информацию заголовка Win32).
1. ОС Windows загружает выполняемый двоичный файл в память.
2. ОС Windows читает встроенный заголовок WinNT, чтобы определить (по флагу IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR), является ли двоичный файл компоновочным блоком .NET.
3. Если образ является компоновочным блоком .NET, загружается mscoree.dll.
4. Затем mscoree.dll загружает одну из двух реализаций CLR (mscorwks.dll или mscorsvr.dll).
5. В этот момент ответственность за выполнение "принимает на себя" среда CLR, выполняющая все связанные с .NET задачи (поиск внешних компоновочных блоков, выполнение проверок безопасности, обработка CIL-кода, сборка мусора и т.д.).
Итак, mscoree.dll - это не сама CLR (как говорилось в предыдущих главах). Хотя вполне возможно идентифицировать mscoree.dll с реальной CLR, на самом деле указанный двоичный файл – это "развилка" на пути к одной из двух возможных реализаций CLR. Если соответствующая машина использует один процессор, загружается mscorwks.dll. Если машина поддерживает мультипроцессорный режим, в память загружается mscorsvr.dll (это версия CLR, оптимизированная для работы на машинах с несколькими процессорами).
Параллельное выполнение CLR
"Копнув" чуть глубже, мы увидим, что платформа .NET поддерживает параллельное выполнение, т.е. на одной машине можно установить несколько версий платформы .NET (во время создания этой книги были доступны версии 1.0.1.1 и 2.0). Сам файл mscoree.dll размещается в подкаталоге System32 каталога установки Windows. Например, на моей машине mscoree.dll "проживает" в каталоге C:WINDOWSsystem32 (рис. 13.11).
Рис. 13.11. Файл mscoree.dll находится в каталоге system32
После загрузки mscoree.dll по реестру системы Win32 (да, по реестру этой системы) выясняется номер последней из установленных версий и путь установки .NET Framework (используется ветвь HKEY_LOCAL_MACHINESoftwareMicrosoft.NETFramework, рис. 13.12).
Рис. 13.12. Выяснение версии и пути установки платформы .NET
После определения версии и пути установки платформы .NET в память загружается нужная версия mscorwks.dll/mscorsvr.dll. На моей машине корневым путем установки платформы .NET является C:WINDOWSMicrosoft.NETFrаmеwork. В указанном каталоге есть специальные подкаталоги для .NET версии 1.0.1.1 и (на время создания книги) текущей версии 2.0 (см. рис. 13.13, ваши номера версий могут быть другими).
Загрузка конкретной версии CLR
Когда mscoree.dll определяет (с помощью реестра системы), какую версию mscorwks.dll/mscorsrv.dll загрузить, читается также раздел Policy (Политика) ветви HKEY_LOCAL_MACHINESoftwareMicrosoft.NETFramework реестра. В этот раздел записывается информация обновлений CLR, которые могут выполняться с безопасностью. Например, если запускается компоновочный блок, который был построен с использованием .NET версии 1.0.3.705, mscoree.dll узнает из файла политики, что вполне безопасно загрузить версию 1.1.4322.
Рис. 13.13. Файл mscorwks.dll версии 2.0
Все это происходит незаметно в фоновом режиме и только тогда, когда известно, что обновление обеспечивает правильное выполнение. В редких случаях возникает необходимость заставить mscoree.dll загрузить конкретную версию CLR, и тогда вы можете использовать для этого файл *.config клиента.
‹?xml version="l.0" encoding="utf-8"?›
‹configuration›
‹startup›
‹requiredRuntime version ="1.0 .3705"/›
‹/startup›
‹/configuration›
Здесь элемент ‹requiredRuntime› указывает, что для загрузки данного компоновочного блока следует использовать только версию 1.0.3705. Поэтому, если на целевой машине нет полной инсталляции .NET версии 1.0.3705, конечный пользователь увидит окно с информацией об ошибке среды выполнения, показанное на рис. 13.14.
Рис. 13.14. Элемент ‹requiredRuntime› порождает сообщение об ошибке среды выполнения, если указанная версия CLR не установлена[2]
Дополнительные хосты CLR
Только что описанный процесс обозначил основные шаги, предпринимаемые операционной системой Windows для хостинга CLR по умолчанию, когда запускается выполняемый компоновочный блок. Но Microsoft предлагает множество приложений, которые могут действовать в обход используемого по умолчанию поведения, используя программную загрузку CLR. Например. Microsoft Internet Explorer может загружать своими встроенными средствами пользовательские элементы управления Windows Forms (управляемый эквивалент теперь уже устаревших элементов управления ActiveX). Последняя версия Microsoft SQL Server (с кодовым названием Yukon и официальным названием SQL Server 2005) также способна осуществлять непосредственный хостинг CLR.
Наконец. Microsoft определила набор интерфейсов, позволяющих разработчикам строить их собственные пользовательские хосты CLR. Это можно сделать, используя соответствующий программный код C/C++ или библиотеку COM-типа (mscorеe.tlb). Хотя сам процесс построения пользовательского хоста CLR исключительно прост (особенно при использовании библиотеки COM-типа), эта тема выходит за рамки нашего обсуждения. Если вам нужна дополнительная информация по данному вопросу, в Сети вы можете найти множество статей на эту тему (просто выполните поиск по ключу "CLR hosts").
Резюме
Целью этой главы было выяснение того, как обрабатывается выполняемый образ .NET. Вы имели возможность убедиться в том, что уже привычное понятие процесса Win32 было внутренне изменено с тем, чтобы адаптировать его к требованиям CLR. Отдельный процесс (которым можно программно управлять с помощью типа System.Diagnostiсs.Process) теперь компонуется из множества доменов приложения, имеющих изолированные и независимые границы в рамках этого процесса. Один процесс может содержать множество доменов приложения, каждый из которых может обрабатывать и выполнять любое число связанных компоновочных блоков.
Кроме того, каждый домен приложения может содержать любое число контекстов. Используя этот дополнительный уровень изоляции типов, среда CLR может гарантировать, что объекты со специальными требованиями будут обработаны корректно. Глава завершается рассмотрением деталей того, как сама CLR обрабатывается операционной системой Win32.
ГЛАВА 14. Создание многопоточных приложений
В предыдущей главе мы рассмотрели взаимосвязь между процессами, доменами приложения и контекстами. В этой мы выясним, как в рамках платформы .NET строить многопоточные приложения и как в условиях множества потоков гарантировать целостность совместно используемых ресурсов.
Наше обсуждение снова начнется с рассмотрении типа делегата .NET, чтобы прийти к пониманию его внутренней поддержки асинхронных вызовов методов. Вы увидите, что такой подход позволяет автоматически вызвать метод во вторичном потоке выполнения. Затем мы исследуем типы пространства имен System.Тhreading. Будет рассмотрено множество типов (Thread.ThreadStart и т.д.), позволяющих с легкостью создавать дополнительные потоки. Конечно, сложность разработки многопоточных приложений заключается не в создании потоков, а в гарантии того, что ваш программный код будет иметь надежные средства обработки конфликтов при конкурентном доступе к общедоступным ресурсам. Поэтому завершается глава рассмотрением различных примитивов синхронизации, предлагаемых каркасом .NET Framework.
Взаимосвязь процессов, доменов приложений, контекстов и потоков
В предыдущей главе обсуждалось понятие потока, который был определен, как путь исполнения в рамках выполняемого приложения. И хотя многие приложения .NET имеют только один поток и, тем не менее, оказываются очень полезными, первичный поток компоновочного блока (порождаемый средой CLR при выполнении Main()) может создавать вторичные потоки для решения дополнительных задач. Реализуя дополнительные потоки, вы можете строить приложения с лучшим откликом на действия пользователя (но не обязательно более быстро выполняющие свои задачи).
Пространство имен System.Threading содержит различные типы, позволяющие создавать многопоточные приложения. Основным типом здесь можно считать класс Thread, поскольку он представляет данный поток. Чтобы программно получить ссылку на поток, выполняющий данный член в текущий момент, просто вызовите статическое свойство Thread.CurrentThread.
private static void ExtractExecutingThread() {
// Получение потока, выполняющего
// в данный момент данный метод.
Thread currThread = Thread.CurrentThread;
}
Для платформы .NET не предполагается прямого однозначного соответствия между доменами приложения и потоками. Напротив, домен приложения может иметь множество потоков, выполняющихся в рамках этого домена в любой момент времени. Кроме того, конкретный поток не привязан к одному домену приложения в течение всего времени существования потока. Потоки могут пересекать границы домена приложения, подчиняясь правилам потоков Win32 и целесообразности CLR.
