C ++ / C # обратный вызов продолжен

Question

Задав этот вопрос и, видимо, поставив людей в тупик, как насчет этого? Могу ли я передать буфер из приложения C # в dll C ++, а затем получить событие синхронизации в C #, просто скопировать содержимое буфера вышло? Таким образом, я избегаю любых задержек, вызванных обратным вызовом, которые, очевидно, происходят. Будет ли это работать, или маршаллинг будет препятствовать такому доступу к буферу? Или я должен был бы перейти в небезопасный режим, и если я это сделаю или нет, какие бы волшебные слова заставили его работать?

Напомним из этого другого вопроса:

• У меня есть драйвер, написанный на C ++, и приложение, написанное на C #.
• Мне нужно получить данные из драйвера в стиле предварительного просмотра.
• Приложения C ++ прекрасно взаимодействуют с DLL C ++; Приложение C # имеет большую задержку для копирования данных.
• Задержка, по-видимому, не вызвана различиями в выпуске / отладке на стороне C #
• Мне нужно обойти задержку. Может ли эта предложенная схема буфера работать? Может ли приложение C # потреблять из буфера, записанного в DLL C ++, или мне нужно сделать что-то еще?

Answer 1

Если вы хотите

1. Использование данных из неуправляемого кода в управляемом коде
   Тогда у вас возникнет проблема, если вы не используете его как указатель байтов (небезопасный код) или не возьмете копию (что для вас сделает маршалинг). Вероятно, это последнее, которое замедляет вас (но не догадайтесь отметка ).

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

Звучит так, как будто вы хотите сделать 1. Вы измеряли задержку? Если это копирование (насколько большой буфер не интересует), то можете ли вы изменить свой код C # для взаимодействия с буфером в качестве байтового указателя (и длины)?
Если у вас есть доступ к C ++ / CLI, вы часто можете обходить его более аккуратно, поскольку легче иметь неуправляемые части кода (работающие с необработанным буфером), а управляемые части просто работают с его подразделами (только копирование что абсолютно необходимо)

Answer 2

По главной причине PInvoke работает медленно и что нужно использовать для решения этой проблемы см. SuppressUnmanagedCodeSecurityAttribute .

Answer 3

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

Answer 4

Да, вы можете передать буфер (например, byte []) из C # в C ++. Я озадачен вашей первоначальной проблемой. Я использую обратные вызовы из моего собственного кода C ++ в C #, и я никогда не замечал проблем с производительностью - хотя я стараюсь не выполнять обратные вызовы на каждой итерации цикла, так как я ожидаю некоторой дополнительной нагрузки на маршалинг.