How effective are Qt QThreads running on a single core embedded target?
-
Problem:
We have a target with hardware video decoders. The particulars of the hardware are abstracted from us by the OEM's drivers. When we call the drivers from our Qt program to start playing a sound file, it appears to block our attempts to display animation for about a second and a half.What can be done:
We were thinking of calling the hardware drivers within their own QThread. But I am having doubts. Again and again the QThread documentation talks about multiple core processors capable of running multiple threads. Does QThreads require multiple cores? If not, exactly how does QThreads interrupt a blocking (if that is what this is) driver call such as to not totally block our animation?Target:
We are running on a Unix (Linux) target. It is a 500MHz single core MIPS processor.Better ideas:
Perhaps QThreads is not the answer here. Please speak up if there are alternatives. The only requirement I'm going to place on any solution is that the Qt program displaying the animation knows exactly when the sound file starts playing. Down to about +/-50ms.-thanks
-
afaik, QThread is control object over a single thread..
thus this is not relevant to number of cores,
because multiple threads can exist even with single core.i don't have a similar experience like you,,, media player thing,,,,
but when i built desktop software for data acquisition via tcp,,
i used QThread in some case and QtConcurrent/QFuture for another cases,this is because data parsing,saving,.. blocks main gui from being updated smoothly,.
belows are articles for QThread, QtConcurrent,, from which i have got many helps.
i think that's a very good materials, so if you don't have been there,, take a look ."Threads, Events and QObjects":http://qt-project.org/wiki/Threads_Events_QObjects
"Thiago Macieira's presentation ":http://qt-project.org/videos/watch/enhancing_your_qt_application_with_multiple_threads -
[quote author="st2000" date="1346853485"]Again and again the QThread documentation talks about multiple core processors capable of running multiple threads. Does QThreads require multiple cores? [/quote]No, but without multiple physical cores your threads will be executed sequentially, not parallel.
[quote author="st2000" date="1346853485"]If not, exactly how does QThreads interrupt a blocking (if that is what this is) driver call such as to not totally block our animation?[/quote]It doesn't, the operating system does. It alternately schedules processing power to the main thread (which does the animation) and the secondary thread (which does the busy waiting for the blocking call).
[quote author="st2000" date="1346853485"]Perhaps QThreads is not the answer here. Please speak up if there are alternatives.[/quote]There really isn't if the call is blocking.
Make sure it is actually the call to the driver which is blocking and not the driver itself. If the driver hogs processing power (and thus preventing a context switch) you are out of luck, even with multiple threads.
-
bq. It doesn’t, the operating system does. It alternately schedules processing power to the main thread (which does the animation) and the secondary thread (which does the busy waiting for the blocking call).
I take it then there is little difference between this and forking off a new processes? So no need to go down that extreem path?
Or, maybe this is a good way to test if this is a blocking or processor intensive event. That is, it would be simple to run an animation in the background and start another program mid way through the animation to see of the Linux OS can handle the sharing of the processor w/o stopping the animation.
-
Both are valid approaches. Which one to take depends a lot on your needs. A thread is more lightweight, communication between threads is simple. A process has way better isolation though.
Browsers tend to go for the latter nowadays, stuffing the rendering into a separate process for security reasons. Applications where security is less of a concern tend to use threads. Both can address your problem -- provided that it is not the driver blocking in kernel space, then you are out of luck.