Еще несколько слов о процессах, доменах приложения и контекстах

К этому моменту вы должны лучше понимать, как среда CLR обрабатывает компоновочные блоки .NET. Вот на что следует обратить внимание.

• Процесс .NET может содержать один или несколько доменов приложения. Каждый домен приложения может принять любое число связанных компоновочных блоков .NET и независимо загружаться и выгружаться средой CLR (или программистом с помощью типа System.AppDomain).

• Любой домен приложения состоит из одного или нескольких контекстов. Используя контексты, среда CLR может поместить объект со "специальными требованиями" в логический контейнер, чтобы гарантировать выполнение этих требований в среде выполнения.

Если предыдущее обсуждение кажется вам слишком сложным и далеким от практики, не волнуйтесь. По большей части среда выполнения .NET автоматически разрешает вопросы процессов, доменов приложений и контекстов, не требуя вашего вмешательства. Тем не менее представленная здесь информация обеспечивает "твердую основу" для понимания принципов многопоточного программирования в рамках платформы .NET. Но перед тем, как перейти к изучению пространства имен System.Threading, мы попытаемся выяснить, как сама среда CLR обрабатывается операционной системой Win32.

Хостинг общеязыковой среды выполнения

Для конечного пользователя запуск выполняемого блока .NET доступен с помощью простого двойного щелчка на соответствующем файле *.exe в окне программы Проводник (или активизации соответствующего ярлыка). Но вы должны помнить из главы 1, что каркас .NET Framework (пока что) не интегрирован непосредственно в ОС Windows, а опирается на ОС. Во время установки Visual Studio 2005 (или .NET Framework 2.0 SDK) на вашу машину устанавливается и окружение среды выполнения .NET (включая все необходимые библиотеки базовых классов). Также напомним, что Microsoft предлагает свободно доступную программу установки (dotnetfx.exe) среды выполнения .NET, позволяющую настроить машину конечного пользователя на поддержку компоновочных блоков .NET.

Поскольку ОС 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, оптимизированная для работы на машинах с несколькими процессорами).