Не отрабатывает QTimer::timeout()

[Racheengel]

Правильнее было бы потоку спать до момента появления необходимости работать ближайшему воркеру. Но кто его будет будить?

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

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

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

[Old]

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

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

[Racheengel]

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

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

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

[Igors]

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

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

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

[Old]

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

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

[Racheengel]

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

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

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

[xokc]

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

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

[Old]

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

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

[xokc]

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

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

[Racheengel]

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

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

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

[Igors]

Хотелось бы, чтобы диспетчеризацией кто-нибудь другой занимался, типа ОС . По предложенному:
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);
}

[kuzulis]

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

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

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

[Racheengel]

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

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

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

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

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

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

[xokc]

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

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

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

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

[xokc]

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

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

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

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

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

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