Выбор техники организации многопотока в QT

[rudireg]

Добрый день.
Хочу написать многопоточное приложение на QT.
Например регистрация аккаунтов в социальной сети, в приложении я могу указать сколько потоков хочу использовать,
и каждый поток будет делать регистрацию аккаунта параллельно с другими потоками.

Думаю схема работы должна быть такой:
Поток UI (он же главный поток) -> Создает поток управление  = дав ему название Master
Далее поток Master должен создать дочерние потоки для выполнения задачи регистраций

Получается такая схема:
UI поток -> Master поток  -> Дочерние потоки от Master

Когда задача выполнилась, потоки должны высвободить память и завершиться.
---------------------------------------------------
Начал читать про методы построения многопоточных приложений в QT
выяснил что можно использовать такие средства как:
1)Использовать классы с унаследованием от QThread
2)Использовать QThreadPool в связке с классами унаследованными от QRunnable
3)Использование QCuncurrent

Подскажите чем отличаются эти методы, и в каких ситуациях нужно прибегать к тому или иному методу
И подскажите какой вариант выбрать мне для реализации сетевой задачи, описание которой выше

[kuzulis]

Лучше использовать "малопотоки" и очереди

[rudireg]

Лучше использовать "малопотоки" и очереди

А можно подробнее?

[Igors]

Ну QtConcurrent здесь ни при чем, он для низкоуровневых расчетов, напр по массиву. Наследование от QThread не ошибка, но необязательно, а иногда и порицается. В принципе любые нитки могут выполнять любые задачи если не связывать их наследованием.

Главное определиться с числом ниток - не будет ли оно (неконтролируемо) возрастать. Ну скажем если Вы уверены что "не более 50 ниток" - то проблем нет. Обычная техника для задач похожих на Вашу - запустить N ниток и пулять в них сигналами с QueuedConnection. Получив сигнал нитка выполняет задачу, отсылает сигнал с результатами и опять засыпает. Это не блещет скоростью но удобно и просто для реализации

[Old]

Ну QtConcurrent здесь ни при чем, он для низкоуровневых расчетов, напр по массиву.

Почему не причем? Это самый простой путь реализовать эту задачу.

2 rudireg: Вы перечислили средства от низкого уровня к высокому. Что выбрать решать вам, чем ниже уровень, тем с большими вещами придется разбираться.

[Igors]

Почему не причем? Это самый простой путь реализовать эту задачу.

Ну если "проще = лучше", то так

Код

C++ (Qt)
#pragma omp parallel for
for (int i = 0; i < account.size(); ++i)
 account[i].register();
 

И вся любовь. Но это если регистрация - достаточно простое действие

[Old]

Но это если регистрация - достаточно простое действие

Почему простое - любое действие.

А вы приверженец такого?

Это не блещет скоростью но удобно и просто для реализации