Кэширование выходного значения Intel TBB input_node задерживает высвобождение ресурсов. Идеи обходного пути?

Я новичок в Intel Threading Building Blocks и играю с компонентом потокового графа. До сих пор это работало в основном хорошо. Мои сообщения между узлами имеют тип shared_ptr, поэтому они легко копируются, легковесны, а базовый ресурс удаляется в конце цикла графа...

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

Это кажется неудобным/несовместимым с остальной частью API. Есть мысли как с этим бороться? Думаю, я мог бы написать свой собственный узел, но я бы не хотел. Должен ли я просто использовать try_put? Если да, то как мне сообщить графику, когда я закончу ввод данных, чтобы wait_for_all не закончилось раньше?


person aggieNick02    schedule 15.07.2020    source источник


Ответы (1)


Простой обходной путь состоит в том, чтобы input_node генерировал сообщение, которое не использует типы shared_ptr, и немедленно передает сообщение function_node, чьи выходные данные используют любые типы shared_ptr, которые вы хотите распространить и которые были собраны после завершения распространения. Это выглядит немного глупо, но работает хорошо. Помимо input_node могут быть узлы, которые выполняют кэширование, но я использую function_node, multifunction_node и indexer_node без каких-либо признаков кэширования, которое выполняет input_node.

Кроме того, меня всегда немного пугает, когда я гуглю проблему и в конечном итоге отвечаю на один из своих вопросов в stackoverflow, и прошло достаточно много времени, чтобы я не помню, чтобы публиковал вопрос. Когда я не вижу ответа, это добавляет к эмоциям еще и некоторое разочарование. ;-)

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

person aggieNick02    schedule 25.04.2021