Qeventloop occupy cpu, would QWaitCondition will release cpu and also be waked？

[QtTester]

Hi, guys:
I have multi thread application.
in qthread we use following code to wait a signal:

{
  QEventLoop loop;
  connect(sender,&Sender::signal,&loop,&QEventLoop::quit);
  loop.exec();
}

Everything works fine. except, the cpu occupation is up to 80% and more.
So i wonderling if we can use follow code to replace the QEventLoop:

{
  QWaitCondition cond;
  cond.wait(mutex);
}

so that every thread will suspend until it's be waked up. the cpu occupation will drop down to a very low level.
I suspect QEventLoop still do the message dispatch , so the thread still consume cpu and not suspended.
question is : when using QWaitCondition , the thread can still receive a signal or not (need to wake up the wait condition)?

[JonB]

@QtTester said in Qeventloop occupy cpu, would QWaitCondition will release cpu and also be waked？:

Everything works fine. except, the cpu occupation is up to 80% and more.

I suspect QEventLoop still do the message dispatch , so the thread still consume cpu and not suspended.

First, I assume in your first case you have loop.exec() in that function after the connect(), but just don't show it? Else your code does nothing at all (does not wait for any signal, exits immediately).....

In addition to the recommendation not to do this anyway. I tested under Ubuntu 22.04, Qt 5.15, because I was interested and as I expected QEventLoop::exec() (in a thread) does not use 80% or indeed any significant CPU time at all? Indeed I would be surprised if it did. Are you sure it does for you??

Note: the one thing which would use a lot of CPU would be calling processEvents() a lot; you don't have anything like

while (true)
    loop.processEvents()

do you?

[Christian Ehrlicher]

@QtTester said in Qeventloop occupy cpu, would QWaitCondition will release cpu and also be waked？:

in qthread we use following code to wait a signal:

Fix your code, don't use such an event loop

[JonB]

@QtTester said in Qeventloop occupy cpu, would QWaitCondition will release cpu and also be waked？:

Everything works fine. except, the cpu occupation is up to 80% and more.

I suspect QEventLoop still do the message dispatch , so the thread still consume cpu and not suspended.

First, I assume in your first case you have loop.exec() in that function after the connect(), but just don't show it? Else your code does nothing at all (does not wait for any signal, exits immediately).....

In addition to the recommendation not to do this anyway. I tested under Ubuntu 22.04, Qt 5.15, because I was interested and as I expected QEventLoop::exec() (in a thread) does not use 80% or indeed any significant CPU time at all? Indeed I would be surprised if it did. Are you sure it does for you??

Note: the one thing which would use a lot of CPU would be calling processEvents() a lot; you don't have anything like

while (true)
    loop.processEvents()

do you?

[QtTester]

@JonB
you are right, I have used a delay func like this:

void OperationBase::simpleWait(const int32_t &ms)
{
    if(ms <= 0)
        return;

        if(m_delayTimer == nullptr){
            m_delayTimer = new QTimer();
            m_delayTimer->setTimerType(Qt::PreciseTimer);
            m_delayTimer->setSingleShot(true);
        }
        m_delayTimer->start(ms);
        while(m_delayTimer->remainingTime() > 0)
            QCoreApplication::processEvents(QEventLoop::ExcludeUserInputEvents);
   
}

I surely know QThread::mslee() will release cpu, but it is not enough real-time for my app. msleep will drift depend on the OS( for me it is windows).
Is there another way to implement a delay function with precise tick?

[JonB]

@QtTester said in Qeventloop occupy cpu, would QWaitCondition will release cpu and also be waked？:

    while(m_delayTimer->remainingTime() > 0)
        QCoreApplication::processEvents(QEventLoop::ExcludeUserInputEvents);

You are "crazy"! ;-) No wonder your CPU time is at ~ 80%, you did not post this code first time! This is incredibly frequent/busy, you are essentially calling processEvents() more or less continuously without break.

You are supposed to start your precise timer and then "do nothing" (be in the main Qt event loop) till it signals timeout, not constantly check remainingTime() till that reaches 0.

I don't know about your real-time needs. But I really think that having a "wait", with (or without) processEvents(), is the wrong approach for Qt/an event-driven system. You really need to move whatever you would like to do after this wait over to a slot on timer timeout and do it there.