[Interest] rendering thread context switch

K. Frank kfrank29.c at gmail.com
Wed Sep 17 20:55:31 CEST 2014


Hello Manish!

On Tue, Sep 16, 2014 at 5:25 AM, manish sharma <83.manish at gmail.com> wrote:
> Hi,
>
> I have few quick items, each of those items render some data every few milli
> sec. Somewhere in my code i do something like below:-
>
> void renderNewData()
> {
>     item1->update()
>     item2->update()
>     .
>     itemK->update()
>     .
>     .
>     itemN->update()
> }
>
> Is there a possibility of a context switch to rendering thread just after
> itemK update is called and before itemN?

In general, yes.  Your os's thread scheduler could certainly pause the
thread running renderNewData after itemK, and run a different thread
on that processor for a while, before restarting the renderNewData
thread and continuing with itemN.

(The context switch could also, in general, occur during the execution
of itemK->update().)

If your need is that itemK and itemN be consistent (for example,
some sort of consistency is required by downstream processing),
you could use a mutex to make the group of item updates run
"atomically."  (And the consumers of the updated items would
have to use the same mutex.)  But this, in general, would not
prevent a context switch -- it would only insure consistency (for
consumers that also used the mutex).

> My intention is to render all the items together frame by frame.

Standard thread synchronization (e.g., mutexes) might do what
you need, depending on your use case.

If you really need to prevent a context switch, you would need to
bind the thread to its processor somehow.  This would generally
be os specific, and I'm not aware that Qt exposes such functionality
(although Qt experts might know better about this).

If you could provide more details about your use case, we might be
able to suggest some more concrete solutions.

> Regards,
> Manish


Happy Multi-Threaded Hacking!


K. Frank



More information about the Interest mailing list