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

[Mandeep Sandhu]

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