Блог

QtConcurrent чрезвычайно удобен в качестве высокоуровневого интерфейса для многопоточной обработки в моем приложении с большим объемом данных / CPU. В обновлениях Qt6 смутно упоминаются «Обновленные API параллелизма», но я не увидел особых изменений, кроме ссылки на возможность передачи пользовательского QThreadPool.

Это заставило меня задуматься… возможно ли расширить QThreadPool до класса, который управляет потоками / задачами на других машинах, а не только на хост-машине? Или это слишком далеко от его первоначального дизайна? Или есть другой класс Qt, который может управлять распределенной обработкой?

Не связывайте меня с решениями, отличными от Qt. Суть этого вопроса не в этом.

К сожалению, QtConcurrent не справляется ни с чем из этого.

В самом общем подходе вам нужно только несколько рабочих компьютеров в сети и способ подключения к ним через ssh (если они Unix) или через учетные данные Windows (в сети Windows). В этот момент вы можете отправить двоичный файл рабочему и выполнить его. Выполнение этого в Qt, конечно, возможно, но для этого вам нужно будет обернуть некоторые другие библиотеки (например, Samba для вызовов RPC или openssh).

Независимо от того, может ли программное обеспечение «распространяться само по себе» или иным образом установлено на рабочих компьютерах, оно работает на нескольких машинах. Теперь им приходится общаться, причем один из них является хозяином, а другой — рабом. Основной выбор может быть выполнен с помощью аргументов командной строки или даже с помощью двух двоичных файлов: workers, которые включают в себя только внутреннюю функциональность, и front end, который включает в себя оба (и имеет какой-то пользовательский интерфейс).

На этом этапе вы можете использовать удаленные объекты Qt, идея заключается в том, что вы бы «распространяли» QObject те объекты, которые работают в слотах, и возвращают результаты либо через возвращаемое значение слота, либо путем отправки сигнала. Это не так удобно, как прямое использование QtConcurrent, но в целом нет способа прозрачно распределять работу без некоторого самоанализа, который C пока не совсем обеспечивает.

Я знаю, что OpenMPI не является решением на основе Qt, оно, безусловно, работает и упрощает жизнь, и наверняка оно может взаимодействовать с кодом Qt — вы даже можете распространять методы и лямбды таким образом (с некоторыми хитростями).

Если вы управляете рабочими объектами, инкапсулированными как QObject s, не так уж сложно распределить работу, например, циклическим способом. Затем у вас может быть интерфейс QObject , который действует как прокси: вы отправляете ему всю работу, и он передает все результаты, но внутренне он вызывает слоты на удаленных QObject серверах.

Вас заинтересует демонстрация? Я мог бы написать его, если бы был достаточный спрос 🙂