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

[Bepec]

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

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

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

[xokc]

Вариант отличия ПО сервера и десктопа вами рассматривается?

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

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

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

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

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

[Igors]

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

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

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

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

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

[Racheengel]

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

[Bepec]

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

[Old]

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

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

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

[xokc]

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

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

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

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

[Old]

Но кто его будет будить? Снова таймер?

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

[Old]

Кто wakeOne вызывать будет и по какому поводу?

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

[xokc]

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

[Igors]

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

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

[xokc]

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

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

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

[Old]

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

[xokc]

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

[Old]

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

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