Маршалинг взаимодействия

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

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

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

Вызов неуправляемого кода и модели взаимодействия COM

Среда CLR предоставляет два механизма взаимодействия с неуправляемым кодом.

• Вызов неуправляемого кода, позволяющий управляемому коду вызывать функции, экспортированные из неуправляемой библиотеки.
• COM-взаимодействие, позволяющее управляемому коду взаимодействовать с COM-объектами с помощью интерфейсов.

Вызовы платформы и com-взаимодействия используют маршалинг взаимодействия для точного перемещения аргументов метода между вызывающим и вызывающим и обратно, если это необходимо. Как показано на схеме ниже, за исключением использования функций обратного вызова метод вызова неуправляемого кода всегда вызывается в направлении от управляемого к неуправляемому коду, а не наоборот. Хотя вызовы неуправляемого кода могут выполняться только от управляемого к неуправляемому коду, данные могут передаваться в обоих направлениях в виде параметров ввода или вывода. Вызовы метода COM-взаимодействия могут проходить в обоих направлениях.

На самом низком уровне оба механизма используют одну и ту же службу маршалинга взаимодействия; однако некоторые типы данных поддерживаются исключительно вызовом COM-взаимодействия или платформы. Дополнительные сведения см. в разделе "Поведение маршаллинга по умолчанию".

Маршаллинг и com-квартиры

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

COM также имеет маршализатор, который маршалирует данные между квартирами COM или различными процессами COM. При вызове управляемого и неуправляемого кода в одной квартире COM маршализатор взаимодействия является единственным маршаллировщиком. При вызове управляемого кода и неуправляемого кода в другой com-квартире или другом процессе задействованы маршализатор взаимодействия и маршализатор COM.

Клиенты COM и управляемые серверы

Для экспортированного управляемого сервера с библиотекой типов, зарегистрированной с помощью средства регистрации сборок (Regasm.exe), существует запись реестра ThreadingModel со значением Both. Это значение показывает, что данный сервер можно активировать как в однопотоковом подразделении (STA), так и в многопотоковом подразделении (MTA). Как показано в таблице ниже, серверный объект создается в том же подразделении, что и вызывающий объект.

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

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

Управляемые клиенты и COM-серверы

По умолчанию для управляемого клиента используется многопотоковое подразделение, однако тип приложения клиента .NET может изменить эту настройку. Например, для клиента Visual Basic настроено однопотоковое подразделение. Для проверки и изменения настройки подразделения для управляемого клиента можно использовать атрибут System.STAThreadAttribute, атрибут System.MTAThreadAttribute, свойство Thread.ApartmentState или свойство Page.AspCompatMode.

Автор компонента настраивает сходство потоков COM-сервера. В таблице ниже показаны сочетания параметров подразделения для клиентов .NET и COM-серверов. В нем также показаны полученные требования к маршалингу для сочетаний.

Когда управляемый клиент и неуправляемый сервер находятся в одной квартире, служба маршаллинга взаимодействия обрабатывает все данные маршалинга. Однако при инициализации клиента и сервера в разных квартирах также требуется маршализация COM. На следующем рисунке показаны элементы вызова между подразделениями.

Для маршаллинга между квартирами можно выполнить следующие действия:

• Примите расходы на маршаллинг между квартирами, что заметно только при наличии большого количества вызовов через границу. Чтобы вызовы успешно пересекали границу подразделения, необходимо зарегистрировать библиотеку типов COM-компонента.

• Изменить основной поток, выбрав для клиентского потока однопотоковое или многопотоковое подразделение. Например, если клиент C# вызывает множество com-компонентов STA, можно избежать маршаллинга между квартирами, установив основной поток на STA.

  Примечание.

  После установки потока клиента C# вызовы к com-компонентам MTA потребуют маршаллинга между квартирами.

Инструкции по выбору модели подразделения в явном виде см. в разделе Управляемые и неуправляемые потоки.

Маршаллирование удаленных вызовов

Как и при маршаллингах между квартирами, маршалирование COM участвует в каждом вызове управляемого и неуправляемого кода всякий раз, когда объекты находятся в отдельных процессах. Например:

• Клиент COM, обращающийся к управляемому серверу на удаленном компьютере, использует DCOM.
• Управляемый клиент, обращающийся к СОМ-серверу на удаленном компьютере, использует DCOM.

На следующем рисунке показано, как маршалирование взаимодействия и маршалирование COM обеспечивают каналы связи между процессами и границами узлов:

Сохранение идентификаторов

Среда CLR сохраняет идентификаторы управляемых и неуправляемых ссылок. На схеме ниже показан поток прямых неуправляемых ссылок (верхняя строка) и прямых управляемых ссылок (нижняя строка) через границы между процессами и узлами.

На этой схеме:

• Неуправляемый клиент получает ссылку на COM-объект от управляемого объекта, получившего эту ссылку от удаленного узла. Механизмом удаленного взаимодействия является DCOM.

• Управляемый клиент получает ссылку на управляемый объект от COM-объекта, получившего эту ссылку от удаленного узла. Механизмом удаленного взаимодействия является DCOM.

  Примечание.

  Экспортированная библиотека типов управляемого сервера должна быть зарегистрирована.

Число границ процессов между вызывающим и вызываемым объектами несущественно; одни и те же прямые ссылки используются для вызовов, входящих в процессы и исходящих из них.

Управляемое удаленное взаимодействие

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

Удаленные вызовы между брандмауэрами с помощью SOAP или класса TcpChannel

Некоторые неуправляемые вызовы, например вызовы между обслуживаемыми COM-компонентами, могут проводиться через SOAP.

См. также

Справочные материалы

System.Runtime.InteropServices