[Qt-interest] Prioritizing between main thread and a new QThread

[sarvesh saran]

Hi,

This is interesting......if you want a portable solution using only Qt
library...try using Qt for I/O (QNetworkAccessManager) + make use of Queued
connection to manage image chunks..and because scaling up to more CPU's is
not your aim you won't need a worker thread at all. But then again this is
just me thinking out loud..

thanks,
Sarvesh

On Fri, Mar 18, 2011 at 7:21 PM, Mandeep Sandhu <mandeepsandhu.chd at gmail.com
> wrote:

> Hi All,
>
> While writing a QT app that uses a thread, we came across an
> "apparently" strange behaviour of scheduling of the newly started
> thread on a embedded Linux system (2.6).
>
> This, we later found out, was "expected" behaviour! :) Though we had
> to sub-class QThread to get the results we were expecting.
>
> I'm writing this mail to get your feedback on whether we have taken
> the right approach or not.
>
> A little background of my "issue" first.
>
> We're working on an MIPS based embedded system, running a fairly old
> Linux 2.6.22 kernel (with vendor provided BSP). We write UI
> applications on top of this system using QT. One of the applications
> is a photo-viewer like app which fetches image data from the n/w and
> displays them on the screen in a grid-like manner (using QT model-view
> framework). The app shows images in a "paged" manner, so going from
> one page to another we animate the grid with a new set of images (old
> grid goes out while the new one animates in).
>
> Now the task of decoding the incoming image data is very CPU intensive
> and so is the animation. Consequently, we used to see the animation
> suffer when images (for next page) were being decoded.
>
> So we though of offloading the decoding part to a low priority thread
> similar to how it was shown in this QT labs blog:
>
>
> http://labs.qt.nokia.com/2010/01/21/qt-graphics-and-performance-generating-content-in-threads/
>
> The main thread mostly used to do 2 main operations - animation (CPU
> intensive) and n/w i/o (blocking IO). The decoder thread would only
> decode it's queue of images (only CPU bound). This decoder thread was
> given the lowest priority and the main GUI thread was given the
> highest priority. Now I believe changing priority of a normal QThread,
> which runs with SCHED_OTHER under Linux, has no effect (both min and
> max priorities are 0).
>
> This helped improve the animation, but 2 implementations that we tried
> were giving very different and unexpected results:
>
> 1.Decoder thread always running:
> ===========================
> In our first implementation the decoder thread was always running, i.e
> it was busy-looping even when there was no data to work on. BUT, we
> were observing that it was getting a chance to run _only_ when the
> main thread was idle! So it almost looked like once the main thread
> finished animating (a CPU intensive task) the other thread was getting
> a chance to run and we used to see all the enqueued images decoded in
> a "batch". In this implementation the animation was completely smooth
> as no decoding operation was hampering it.
>
> 2. Decoder thread waits/sleeps on empty job queue:
> =========================================
> In our 2nd implementation,  since busy looping was not a good idea, we
> changed the decoder thread to sleep (blocking on a mutex) when there
> was no job to be done. Surprisingly, in this implementation the
> animation was suffering again. We could see the decoder thread run
> in-between the main thread's run (which was animating the UI) which
> could possibly explain the poor animation performance.
>
> On further investigation, we concluded that in the first
> implementation since the decoder thread was busy-looping, it became a
> CPU-bound task and the OS was penalizing it with a reduced 'nice'
> value.
>
> To further check if this was the cause of the issue, in the 2nd
> implementation, we 'reniced' the decoder thread to a higher value (i.e
> lower priority) from the shell and started seeing improved performance
> of animation, similar to the 1st approach.
>
> To finally solve the issue, we sub-classed QThread an reimplemented
> the run method to set the scheduling priority of the current thread to
> 'SCHED_BATCH'. With this change we saw that the decoder thread would
> only run when the main thread was not running.
>
> This is not a portable solution but works for us since we are
> targeting only 1 platform.
>
> Is there any other way to solve this issue, since priorities don't
> seem to work under Linux?
>
> Thanks,
> -mandeep
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110320/8f19e538/attachment.html