Логика работы многопоточности Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[RazrFalcon]

Я так понимаю, надо просто пробовать разные варианты, и замерять общее время. Ну а потом уже выбирать лучший для данной задачи вариант?

[Litkevich Yuriy]

вообще второй поток, кроме первого нужен только для того чтобы первый не замирал при длительных операциях.

Исключения составляют если ты жёстко пишешь под конкретную железку, например с 4 процами. А иначе пользователь запустит на однопроцессорной машине твою программу и увидит её заторможенность.

[RazrFalcon]

Вроде понял, в основном запуска обработку половины изображений всех, и одновременно стартую 2-й поток который обрабатывает вторую половину.
Результат на лицо:
1-н поток 36 сек
2-а потока 20 сек
~50% прирост, как и читал, что прирост будет не в 2-а раза а в 1.5
PS: у меня вывод в консоль через qDebug, вроде выводит по очереди, с этим вообще могут быть проблемы? Так как что запись в один файл не лучшая идея.

[Алексей1153]

~50% прирост

это как раз за счёт того, что у тебя два ядра

[Iron Bug]

и эти два вторичных буду по очереди работать + затраты на их переключение

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

логичнее сделать какие-то сигналы о том, что поток освободился. по получению сигнала, главный поток выдаёт свободному потоку очередную задачу. а сам собирает результаты. но это, опять же, если не нужно соблюдать FIFO при обработке заданий. а если нужно, то тогда распараллеливание будет менее эффективно и нужно будет ставить какую-то доп проверку на "порядковые номера" готовых заданий.

Сообщение отредактировал Iron Bug - 9.12.2010, 9:00

[RazrFalcon]

Как правильно определить что потоки завершились, а то сыпятся ошибки вида

QThread destroyed while thread is still running

Рабочий вариант пока только такой:

void MyThread::run()
{
    match(1,15);
    flag=true;
}

void MyThread2::run()
{
    match(16,29);
    flag2=true;
}

а в конце main

    while (th.isRunning())
    {
        if (flag==true && flag2==true) return 0;
        wait();
    }

[BRE]

RazrFalcon, попробуй вначале разобраться и поэкспериментировать с простыми потоками.
Сделай класс Thread, который будет выводить на консоль один символ нужное количество раз, символ и количество итераций должно передаваться в параметрах конструктора объекта. Создай один, два, три, ... экземпляра этого объекта. Разберись когда создается и завершается проект. Добавь к нему возможность преждевременного завершения потока. Потом попробуй добавить очереди, из которых потоки будут выбирать задания (символ/количество итераций) и выполнять их и т.д.
Короче постепенно. Потом, ты сам увидишь как туда добавить свою задачу.

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

[RazrFalcon]

Да просто я до этого запускал пол обработки в главном потоке, а вторую половину в дополнительном.
И когда понадобилось что бы дополнительный работал чуть дольше, вылезла такая ошибка.
Я понимаю, что просто главный завершился уже, и убивает дополнительный. Просто когда сделал два дополнительных потока, а главный только запускал их, то прога рушилась сразу, мне надо как то не дать завершатся главному потоку пока остальные не закончат работу.
А то что я написал тоже криво работает, и проц еще больше жрет
Я понимаю что потоки - это не на один день, но все равно.
Что то с isFinished ()