Создал экземпляр QThread для асинхронного выполнения действий из основных потоков. У этого объекта есть два сигнала:




started надо дождаться перед запуском основных потоков, а finished- перед выдачей сообщения об окончании обработки.

Конечно, можно каждый из этих сигналов связать со слотами с помощью connect. Но это сильно уродует код (надо весь основной код помещать в один слот, а в другой слот помещать код завершения обработки). Код получается сгруппирован не по функциональности, а по "сигнально- слотовой" необходимости ...

Есть какой- то метод, который "усыпляет" текущий поток до момента появления нужного сигнала?

MasterZivТвой подход в корне неверный. Сигналы и слоты -- это событийно-управляемое программирование.
А ты хочешь что-то ждать в главном потоке.
Ты должен соединиться с сигналом и ждать, когда он придёт, тогда в слоте что-то делать.

Это первый слой непонимания.

Спасибо за участие в беседе!
А какая разница ждать в основном потоке или ждать в слоте? А если в программе будет 10 различных вспомогательных объектов, то на каждый создавать свой слот и как-то ждать когда все они сработают (например, через 10 переменных типа bool, совокупность значений которых анализировать в каждом слоте) ?

MasterZivВторой -- что для фоновых задач нужно создавать поток.
Это тоже неправильно, потоки создавать достаточно дорого,
и так их направо налево создавать негоже.

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

MasterZivАльтернатива -- использовать потоки и много задачность из STD.
(я бы именно так и делал)

Если окажется, что Qt не позволяет дождаться сигнала без извращения всего кода, то так и сделаю. Эта оптимизация мне нужна на 10 уровней ниже по стеку, и совсем не хочется из-за этого переписывать все 10 уровней вверх по стеку: потом ведь никто не поймет зачем эти извращения прикручены.

Похоже выход нашелся:
1. Для ожидания запуска вспомогательного потока:


2. Для ожидания завершения вспомогательного потока:

MasterZivА какая разница ждать в основном потоке или ждать в слоте?

В слоте не надо ждать. Его автоматом вызовут, когда надо будет.

Хорошо, будем ждать, пока не вызовется слот. Ожидание никуда не уйдет, потому что оно определяется не нами, а фактом поступления внешнего события.

MasterZivЭто не выход, это эпик фейл.
Buisy wait называется.
Антипаттерн многозадачного программирования.

Не согласен: любая библиотека многопоточного программирования имеет явные или неявные примитивы ожидания выполнения потоков. Например, в классическом С++ у потоков есть метод join(), который выполняет эту функцию.

К 4 основным потокам приделал 5-ый поток с приоритетом Idle для асинхронной записи на диск (у меня 4-ех ядерный Haswell). В итоге с помощью Vtune Amplifier получил такие цифры (до /после), сек:
Время работы: 387 / 312
Время CPU: 1012 / 1241

Видно, что время работы обработки хорошо упало. Рост времени CPU произошел из- за того, что сон пятого асинхронного потока система также учла, так что на это значение внимание обращать не стоит. Другими словами, раньше коэффициент многопоточности был ~2.6, а стал 3.24.

Я доволен, если учесть, что обработка имеет очень большой ввод / вывод: чтение 40 ГБ (с ssd) и запись 16 ГБ на HDD (7200 оборотов).