Если интерфейс в вашем вопросе является интерфейсом COM, подход, предложенный Quassnoi, может быть недостаточным. Вы должны обратить внимание на модель потоков используемого COM-объекта. Если вторичный поток присоединится к отдельной COM-квартире из той, в которой был создан ваш COM-объект, и если этот объект не является apartment-agile , вам потребуется маршалировать этот указатель интерфейса, чтобы вторичный поток получает прокси, а не прямой указатель на объект.
COM-объект обычно превращается в квартиру с помощью специальной реализации IMarshal. Самый простой подход состоит в агрегировании Free Threaded Marshaler.
Несколько полезных ссылок ...
Обновление: о маршалере со свободной резьбой ...
Из комментариев на эту тему видно, что некоторые люди рекомендуют никогда не трогать FTM. Хотя «Эффективный COM» - отличная книга, я думаю, что некоторые из ее рекомендаций открыты для толкования. Пункт 33 гласит: «Берегись FTM»; это не говорит "Никогда не используйте FTM". Очень мудро советует проявлять осторожность, особенно когда ваш объект, динамичный по квартире, содержит ссылки на другие объекты, потому что они могут не быть гибкими по квартире. Таким образом, на самом деле совет таков: тщательно продумайте, когда строите гибкие объекты, используют ли они FTM для достижения своей ловкости. Если вы уверены, что можете построить объект, способный к быстрым квартирам, я не вижу причин, по которым вы бы не использовали FTM для этого.