Russian Qt Forum

Qt 5.5, Windows 8/Server 2012.
Имею следующий код в наследнике QThread:

C++ (Qt)
void Thread::step()
{
    if (!m_printed) {
        m_printed = true;
        qDebug() << "step()" << QThread::currentThreadId();
    }
}
 
void Thread::run()
{
    qDebug() << "run()" << QThread::currentThreadId();
    m_printed = false;
 
    QTimer idle;
    connect(&idle, &QTimer::timeout, this, &Thread::step);
    idle.start(1);
    QThread::run();
}

На "обычных" (i7, i5, виртуалки) компах код работает ожидаемо - сколько потоков создано, столько же и отрабатываний в step(), причем вне зависимости от количества созданных потоков n (проверял для n <= 20). На серверных же двухпроцессорных Xeon с общим количеством ядер = 40 уже начиная с 16 потоков количество вызовов step() становится на 3-4 раза меньше, чем запущено потоков. Что это может быть?

1. Почему таймер создается как локальная переменная?
2. Зачем нужен вызов QThread::run(); ?
3. Какой таймаут у таймера? Предположение - таймер разрушается раньше, чем успевает эмитировать сигнал.

Почему - нет? Зачем ему быть переменной класса или чем-то ещё?
Для запуска цикла обработки событий внутри потока.
Таймаут 1 мс. Таймер не разрушается - он существует пока выполняется QThread::run(), то есть на протяжении всего времени жизни самого Thread.

А почему нет? :)
Таймер будет жить все время работы нитки (выполнения run), а потом автоматически разрушиться.

Он запускает обработку очереди событий.

1 мс.

Как уже писал выше, таймеры живут все время работы нитки.

Дуплет. :)

А нитки, в которых не сработали потоки, продолжают работать?

Причём, почти дословный :)
Да, работают нормально. Да и те, которые "корявые" работают тоже - другие события они обрабатывают. Только таймерные не хотят.

Попробуйте устанавливать интервал и запускать таймер раздельно:

C++ (Qt)
setInterval( 1 );
start();
 

Я имел в виду последнюю строку в void Thread::run() . Там у вас QThread::run () что запускает? Просто всего кода не видно.
Hyperthreading активен, кстати?

Он запускает QThread::exec().

http://blog.debao.me/2013/08/how-to-use-qthread-in-the-right-way-part-1/

Посмотрите Usage 1-2 , кажется, там похожая проблема решается.

Ожидаемо не помогло :(

В чем смысл? По хорошему надо бы переопределить run () и стартовать через exec (), а не наоборот.

Нитка стартует через start, exec запускает eventloop.

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

Не заморачивайся. Можно заменить QThread::run() на exec() ничего не изменится, суть проблемы не в этом:

C++ (Qt)
void QThread::run()
{
    (void) exec();
}

А увеличивать таймаут пробовали, для проверки?

Пробовал. start(10) почти работает - периодически "залипает" одна из ниток, start(100) работает гарантированно. Но меня такой интервал не устраивает.

Я так понимаю, вы хотите вызывать step сразу после запуска eventloop.
Попробуйте вместо таймера использовать QMetaObject::invokeMethod c Qt::QueueConnect.

Мне, в целом, нужно максимально часто выполнять определенный код в тот момент когда очередь событий потока пуста. Собственно, исходил из этого посыла в документации:
To make your application perform idle processing (i.e. executing a special function whenever there are no pending events), use a QTimer with 0 timeout.
start(0) для меня чрезмерен - комп начинает "пожирать" самого себя. Может есть другие способы, особенно учитывая следующее предложение оттуда же?
More sophisticated idle processing schemes can be achieved using processEvents().

Вот invokeMethod для этого хорошо подходит.
В методе step просто добавляйте вызов его же самого через invokeMethod+QueueConnection и таймер не понадобиться.

step() должен вызываться всякий раз когда нитке больше "нечего делать". В приведенном примере его полезная нагрузка опущена. Пробовал заменить QTimer на timerEvent - результат ровно тот же. С invokeMethod попробую.

Вроде бы с invoke, на первый взгляд, заработало. Old, спасибо большое. Завтра на свежую голову проверю тщательнее. Но, в любом случае, поведение, на мой взгляд, странное. Особенно с учётом того, что этот таймерный нюанс проявляется только в мультипроцессорных конфигурациях.

Неясно в какой нитке выполняется QThread::step. Если в главной, то все вполне объяснимо - события таймера игнорируются если в данный момент выполняется обработка предыдущего

Тут остается только сожалеть.  ::)

В своей собственной - в той же, которая "run()", именно для проверки этого факта выводился currentThreadId

Эта версия теоретически имеет право на жизнь, но почему эффект не проявляется на "бытовых" ПК, а только на "серверных"?

Вот сейчас подумалось. Для такого поведения, возможно удобней будет в ните запустить step как основное задание, а в перерывах обрабатывать накопившиеся события.

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

Тогда варианты почему это происходит:

1) Нитка загружена постоянно т.е. в ее EventLoop все время есть события - а события таймера помещаются в  EventLoop только если там никого нет. Это можно проверить отключив нагрузку

2)  EventLoop еще не запущен когда таймаут истек. Ну опять-таки неясно, ведь будут еще события таймера.

Используется DirectConnection, слоты вызываются напрямую, никаких событий таймера в очередь не кладется.

Меня самого эта корявость архитектуры несколько гложет. Суть в том, что Thread - это пул воркеров и полезный код нагрузки выглядит примерно так:

C++ (Qt)
void Thread::step()
{
    for (bool flag = true; flag;) {
        flag = false;
        for (Worker *worker : m_workers) {
            if (worker->isStepReady()) {
                worker->step();
                yieldCurrentThread();
                flag = true;
            };
        }
    }
}
 

Особенность воркеров такова, что у них потребность в работе возникает в среднем 10 раз в секунду, а продолжительность выполнения одного шага воркера достаточно мала, так что забивать комп бесконечной проверкой "не созрел ли кто для работы" тоже не хочется. С другой стороны, при достаточно большом количестве воркеров (до 1024) текущая схема тоже не выглядит идеальной. Правильнее было бы потоку спать до момента появления необходимости работать ближайшему воркеру. Но кто его будет будить? Снова таймер?

Проверял без нагрузки - разницы нет.
И опять таки:

Вариант отличия ПО сервера и десктопа вами рассматривается?
Вполне возможно, что какой нить хитрый механизм оптимизации имеет место быть.
Как то ограничение на количество одновременных потоков для приложения и выделяемых мощностей.

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

Ну или ещё вариант на мутексах сделать. Никакие таймеры не нужны будут.

Проверял на виртуалке Windows Server в десктопе - все работает как надо

Где я тут писал про сотню страдающих фигней потоков? Мои потоки (их ровно половина от имеющихся вычислительных ядер) и играют роль того самого менеджера. "Фигней страдают" воркеры - так на то они и воркеры, чтобы фигней страдать.

На каких мьютексах? У меня нет общего ресурса, который нужно защищать мьютексами!

Напрямую "от кого"? События таймера приходят от OC, не крутим EventLoop - нет и этих событий

Ну если 10 раз в секунду, то чем не устраивает избитая схема QWaitCondition::wait и wakeOne?

Edit: впечатление что таймер здесь - явно "не то"

И все таки... что там с гипертридингом?
Иногда бывают с ним проблемы, не раз замечено.... и именно ка ксеонах.

Мутексом можно блочить ресурс, а можно использовать его в качестве контролирующего элемента. Тот же QWaitCondition на этом работает, вроде.

Не от какой ОС ничего не приходит.
Прошел или нет заданный интервал времени определяется в eventloop, и если прошло активируется слот.
А если объект слота получателя находиться в том же потоке, то это сводится к прямому колу.

В общем виде цикл обработки событий обрабатывает таймеры, опрашивает внешние события и обрабатывает сами события из очереди.

Кто wakeOne вызывать будет и по какому поводу?
Можно было бы просто ориентироваться на ближайший из просыпающихся воркеров и будить нитку по соответствующему таймауту в QWaitCondition::wait. Но при большом количестве воркеров не будет ли у меня система только и заниматься тем, что засыпать и просыпаться?

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

Никаких таймеров, это страшно. :)
Используйте очередь заданий с условной переменной QWaitCondition, и все будет работать как часы.
На форуме есть несколько тем, где я приводил код таких очередей. Не найдете, пишите наберу еще раз, там пара десятков строк.

Тот кто будет новую работу добавлять для воркеров.

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

Вот это место "осветите" - как (или откуда) появляется собственно "задание"

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

Подобные вещи я делаю так. Каждый воркер имеет свой внутренний таймер, запущенный с заданным интервалом. При срабатывании - делаем работу.

Хм. Что-то с таймерами мне больше не хочется иметь дела.

А как без них время засекать? Крутить свой цикл с проверкой сколько крутим - будет еще хуже. :)
Тем более там у вас интервалы будут в секундах.

Хм.. а чем не устраивает вариант, после того как воркер отрабатывает, отправлять его в слип на 10мс, к примеру? Проснулся - сделал работу - уснул.

Для маленких интервалов (< 1 сек) - еще ничего, а для больших начинаются неприятности при завершении работы нитки. Вы сказали останавливайся, а остановиться он реально после того как закончится sleep, если это несколько секунд - уже заметно.

Это понятно, но разве это не то, что хочет автор? Чтобы воркеры спали определенное время после завершения?

А если так: завести еще "нитку 2"

1) нитка с воркрами делает ту самую пробежку и посылает "сигнал2" нитке 2
2) получив "сигнал2" нитка 2 спит заданное время если время ни одного из воркеров еще не пришло -  иначе сразу посылает "сигнал1" нитке с воркерами
3) получив "сигнал1" нитка с воркерами обслуживает готовых и возвращается к пункту 1

Хочет этого, но наверное и завершаться быстро тоже хочет.

Ну, мы это решаем просто: воркер в run () проверяет флаг завершения и флаг наличия работы. Если сказано завершиться, умираем. Если работать, работаем. Иначе короткий сон и все повторить.

Спать придется всей нитке. Во время её сна не будут приниматься события. Если воркеров будет достаточно много, оверхед на процессы засыпания/побудки не получится слишком большим?

Я про это говорил чуть выше, это ручная эмитация работы таймера QTimer. :)

Хотелось бы, чтобы диспетчеризацией кто-нибудь другой занимался, типа ОС :). По предложенному:
1. Нитка 1 после 1-го пункта спит по QWaitCondition::wait?
2. Нитка 2 посылает сигнал по wakeOne?

Да, но облегченный вариант, никаких объектов таймера и сигналов :)

1) Нет, тупо sleep.
2) Нет, просто проснулась - шлет сигнал с QueuedConnect и опять повисает на своем EventLoop

Да, это самопальный таймер, но с той разницей что ОС не может его "задвинуть взад" как он любит делать. Если время sleep значительно - порезать, напр

C++ (Qt)
while (sleepMs > 0) {
 int step = qMin(sleepMs, sleepStep);
 sleepMs -= step;
 if (abortFlag) ...
 sleep(step);
}

1. А не пробовали менять тип таймера http://doc.qt.io/qt-5/qt.html#TimerType-enum?

2. Вероятно что в ядре серверной ОС есть какие-то различия, если в десктопной работает -  а в серверной - нет. Я не уверен что qt-цы тестят свою поделку Qt на серверных ОС (надо глянуть как-нить для интереса на список ихних CI).

А таймер вообще работает в серверной ОС, если не использовать потоки? Проверял кто-нить просто стартануть таймер и посмотреть что оно скажет? Мож баг какой?  ::)

В смысле всей нитке? Если каждый воркер - это отдельная нитка, то спать и просыпаться будет только он сам.

Насчет оверхеда - это вряд ли, по крайней мере я такого на наших проектах не замечал. Оверхед заметен при создании и запуске тредов, но после того, как тред запущен - не думаю, что это как-то скажется на производительности. Да, еще коннект сигнал-слотов и их активация - тоже не бесплатна, к слову.

У нас другая неприятность как-то была - по-разному отрабатывали треды, созданные через QThread, и треды, созданные через WinAPI, в разных осях (в 7 и 8 ), насколько я помню.

И все-таки, Hyperthreading пробовали выключить?

Каждый воркер - НЕ отдельная нитка. В одной нитке до 256 воркеров.

Не, не пробовал. Слишком жирно будет ради этого HT убирать. Да и потом, на i7 с включенным HT всё работает предсказуемо.

Не пробовал, думаю что не поможет. Если настаиваете - попробую. Просто всё "разломал" уже: от таймеров избавился и переделал на invokeMethod, там всё работает более предсказуемо.

На Windows Server пробовал в виртуалке на десктопном железе - работает нормально.

"Просто" работает. Даже в моём варианте из 20 ниток 17 стартуют нормально .

Вы ток не путайте "я запустил серверную ос на десктопе в виртуалке", это не равняется "работает на серверной ОС с многоядерными процессорами".

Та же ОС меняет подход в зависимости от проца, так что тут нужно брать и дебажить именно на реальном железе.

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


Ну, ради эксперимента-то можно один раз попробовать. Я лично наблюдал проблему с включенным HT на 2-процессорном ксеоне.

А где это-то я утверждал подобное?

Воркеры - внутри одного пула (нитки) работают последовательно и независимо друг от друга. Идея в существовании нескольких таких таких пулов, выполняемых параллельно.

Если руки дойдут - попробую.

А, не, скорее всего не попробую. Отключать НТ в БИОСе надо, а доступа к IPMI или консоли у меня нет. Возможно, когда буду рядом с железом, эта возможность и  появится, но не факт, что к тому времени проблемный код с таймерами всё ещё будет в наличии.