[Qt-interest] QThread vs QTimer for polling

[Mandeep Sandhu]

On Sat, Feb 27, 2010 at 10:52 PM, Jason H <scorp1us at yahoo.com> wrote:
> You have failed to describe a reason to use a thread.

Well, I  thought I did! :)

Let me explain again.

I have my QT app running on some custom embedded h/w. My app, in it's
course of work, issues some commands to the h/w and waits for the
result of the command before it can give the next one (the prev cmd
must succeed before the next one can be given).

I have a 3rd party lib, through which I can access the h/w (give cmd,
check for status etc).

So, after my app issues a cmd, it is required to wait till the results
of the cmd are known. To this effect, in one approach, I was thinking
of using a thread which when started would poll the h/w for the
results and then inform the main app when the results are available.
It can take anywhere from 500 msec to ~3sec for the results to be
available.

Thats why, I wanted to know if thread approach would be better or the
main app using a timer to monitor the status?

Thanks,
-mandeep


>
> -J
>
>
> On Feb 27, 2010, at 2:45 AM, Mandeep Sandhu <mandeepsandhu.chd at gmail.com> wrote:
>
> Hi All,
>
> I'm using Qt on an embedded platform.
>
> My application is required to poll a particular h/w component for
> status changes/monitoring. Basically my application wants to get the
> status of a certain commands given to the h/w (these commands don't
> have immediate effect and hence the need for polling). Polling must be
> done till the time the requested status is achieved OR the maximum
> number of retires have been exceeded. Once the app gets the status, no
> more polling is needed till it issues another command.
>
> I can think of 2 ways of achieving this:
>
> * QThread: Start a thread to monitor the h/w status changes and inform
> my application using signals. This thread is started in the beginning
> and runs forever, till explicitly stopped by the application. When the
> application has not requested for polling, it simply sleeps (on maybe,
> a semaphore or some wait condition).
>
> * Qtimer: Start a single-shot timer when polling is needed. Each time
> the timer function runs, it checks the status requested, if it's met,
> it signals the app, else it fires another single-shot timer and checks
> again later.
>
> My question is that which one of these approaches has better
> performance, considering I'm running in an embedded environment and
> would like to load the CPU as little as needed. Or maybe there's a
> third approach? Is firing a timer repeatedly more "expensive" (in
> terms of CPU cycles) than say waking up a thread (at similar
> intervals)?
>
> Any suggestions?
>
> Thanks,
> -mandeep
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>
>
>
>
>