Strange QTimer behaviour in multithreaded system

[sysmaniac]

Hi,

I found an interessting behaviour in QTimer that I believe is in contradiction to what the documentation says. It seems like QTimer is racing to make up for lost timer ticks instead of discarding them.

My system has 2 threads. Thread 1 is responsible for the communication and uses a 100ms timer to send and receive data from a microcontroller. Thread 2 does the heavy processing that take up to several seconds. If now Thread 2 uses all CPU time for it's processing Thread 1 should afterwards continue to send/receive every 100ms even if some timer ticks were lost due to the CPU being unavailable. This is also what the documentation of QTimer says:

"Timers will never time out earlier [...].
If Qt is unable to deliver the requested number of timer clicks, it will silently discard some."

On my system this is not the case. I am seeing timer ticks emitted every 20-30ms for some time after the heavy processing until the rate stabilizes again at the nominal 100ms. It seems like QTimer is trying to make up for the lost timer ticks.

I found a workaround though that I can recommend if anybody has a similar issue. Instead of using a QTimer I am now using a forever-loop that calls the send/receive method and uses msleep() for the 100ms delay. On my embedded linux platform that works.

What is your take on this? Did I miss any configuration options on QTimer? Anybody had the same problem before?

[wysota]

How do you know what is the real interval of timer timeouts? Where are you "seeing" those ticks?

[sysmaniac]

How do you know what is the real interval of timer timeouts? Where are you "seeing" those ticks?

I started seeing it because the microcontroller that I am communicating with started to complain about timing violations. To verify it I am using the output of a separate QTime.

It looks like this:

QTime *debug_time;  //used for measuring elapsed time between two ticks
QTimer *tx_timer;      //used to trigger the periodic send/receive	
 
void TxThread::run() {
  debug_time->start();
  tx_timer = new QTimer();
  tx_timer->setInterval(SEND_INTERVAL);
  connect(tx_timer, SIGNAL(timeout()), this, SLOT(send_receive()));
  tx_timer->start();
  exec();
}
 
void TxThread::send_receive() {
  qDebug() << "SR: " << debug_time->elapsed() << "ms";
  //here comes the actual TX/RX part via SPI
}

QTime *debug_time;  //used for measuring elapsed time between two ticks
QTimer *tx_timer;      //used to trigger the periodic send/receive	

void TxThread::run() {
  debug_time->start();
  tx_timer = new QTimer();
  tx_timer->setInterval(SEND_INTERVAL);
  connect(tx_timer, SIGNAL(timeout()), this, SLOT(send_receive()));
  tx_timer->start();
  exec();
}

void TxThread::send_receive() {
  qDebug() << "SR: " << debug_time->elapsed() << "ms";
  //here comes the actual TX/RX part via SPI
}

To copy to clipboard, switch view to plain text mode 

[wysota]

But you are not measuring timer intervals but rather slot call intervals which are done across threads in your case. The timer is happily ticking at 100ms but since the other thread does heavy calculations, there is a buildup of pending slot calls that are executed independent of when the timer ticks.