Время выполнения параллелизма VS2010 и unbounded_buffer<shared_ptr <T >>, какие подводные камни?

Question

Я хочу передать кучу выделенных объектов из DLL. Очевидно, память должна управляться правильно. Кто-нибудь видит проблему со следующей хитрой схемой, которую я разработал:

unbounded_buffer<shared_ptr<T>> buf;

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

Answer 1

Вот что я получил от MSFT по этому вопросу:

1. Да, вы можете использовать блоки сообщений (например, unbounded_buffer) в потоке, которые создаются вручную с помощью CreateThread.

2. Сообщения не могут пересекать границы dll в том смысле, что их размещение и удаление должны происходить в одной и той же dll. Некоторые блоки сообщений, такие как преобразователь, выделяют новые сообщения. Так что они страдают от той же проблемы. unbounded_buffer> идеально подходит для использования, за исключением того, что не решает вышеуказанную проблему. Аргумент шаблона типа ссылается на тип полезной нагрузки в сообщении (то есть сообщении). Это не тип конверта.

3. В устойчивом состоянии пропускная способность сети передачи данных очень хорошая. Основным источником снижения производительности является связывание и отсоединение блоков сообщений при настройке сети. В Visual Studio 2010 команды запуска сообщений, такие как send и asend, пострадали от этого снижения производительности. Мы решили эту проблему в следующем выпуске Visual Studio. Не планируется переносить исправление на VS2010. Возможный обходной путь - реализовать простой блок сообщений ISource, который всегда подключен к сети потока данных. Используйте этот блок для инициирования сообщений в сеть (_Originator в agents.h является примером для блока ISource).