0

Suppose that timer is a object of QTimer, the timer's interval is iInterval and timer's timeout signal is connected to a slot sltTimeout().

I was just thinking what would happen if iInterval is smaller than the time it takes for sltTimeout() to run. Will multiple threads run sltTimeout() as a result? If so, it seems that could cause problems with unsynchronized access to an object.

Can anyone clarify it?

László Papp
  • 51,870
  • 39
  • 111
  • 135
waterd
  • 603
  • 1
  • 7
  • 23

2 Answers2

6

A QTimer runs on the thread from which it was started. Since it only runs on one thread, it is not possible for it to emit its timeout() signal more than once before the previous slot function has returned.

From the QTimer documentation:

Qt uses the timer's thread affinity to determine which thread will emit the timeout() signal.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • I think this is not what the OP asked for. The OP asked for parallel execution of the slot (sltTimeout), not the timer itself. – László Papp May 20 '14 at 04:11
  • @GregHewgill I read 'Qt uses the timer's thread affinity to determine which thread will emit the timeout() signal'yesterday,but I didn't get it.Now I confirm your answer by comparing threadid. – waterd May 20 '14 at 06:02
  • @JandunCN: it is important to be clear. Greg was lucky here to think the same as you, but your question is unclear, and in my interpretation, it asks where the slot is run in parallel, and not that whether the signal emit is done in different threads. Keep it in mind in the future. If it is just about the thread question for the emit and slot, I would say it is a duplicate, but based on the current text, I do not dare to mark it so. – László Papp May 20 '14 at 06:35
0

Will multiple threads run sltTimeout() as a result?

It will not run automagically so, no. You will need to make sure it is done like that if desired, e.g. if it is doing some computation.

If so, it seems that could cause problems with unsynchronized access to an object.

Yes and no.

It is nothing special in this case, just general thread programming. You would need to use thread sync'ing primitives, like QMutex, QMutexLocker, QSemaphore, and so on.

Another trick you could do is to stop the timer invokation when the slot is processed, but that has the compromise you may not wish to take.

Do not forget that the event would be queued by default, so if you do not depend on the previous run of your sltTimeout in the next run, you could even ignore threading "if you have enough time" to get it done. If there is dependency between subsequent invocations, then yeah, you need to become smart in code.

László Papp
  • 51,870
  • 39
  • 111
  • 135
  • 1
    Actually,I just I want to whether the thread where signal emits and the thread where sltTimeout() runs are the same one or not.Thank you all the same for giving me tips about sync'ing programming. – waterd May 20 '14 at 06:04
  • @JandunCN: that is not what your question is asking. Please try to be clear in the future. – László Papp May 20 '14 at 06:21