Qt Thread Priorities Under Linux

[bob2oneil]

When doing some threading experimenting under Windows, I seem to recall an instance where a signal was not being received in the Release build, whereas it worked fine in the Debug build.

Have you ever used any implementation of a signal/slot spy to diagnose these types of problems? I was checking out in the Qt Apps a class implementation called "Conan", that looked to be an interesting signal/slot spy.

Is there any particular signal/slot spy that you would recommend?

[bob2oneil]

wyosata, you were kind enough in another thread to provide source code to a thread safe queue you developed. It is my understanding, that this implemenation implements a monitor object, providing thread safe mutual exclusion to the objects it controls.
What is also nice about this C++ template is that it will throttle the producer until the consumer has freed up some queue space.

In my current application, I have several secondary threads, none of which run exec() loops because I want them to pend. The secondary threads will likely have a higher priority than the main GUI thread.

The secondary thread within its thread context will pass data to the primary GUI thread via your thread safe queue.

Do you see any potential priority inversion condition that could occur wherein the GUI thread, having a lower priority than the producer thread, would be indirectly preempted by the lower priority GUI thread effectively "inverting" the relative priorities of the two tasks?

I was doing some reading on how POSIX threads, and speciifically how the Pthread mutex has a provision to handle this condition via priority inheritence or ceiling. However, in looking through the Qt source code, it is clear that Qt's implementation of QMutex does
not have these provisions.

I was wondering if a simple derivation from QMutex might suffice, or in the case of your fine thread safe template, perhaps a derivation from QSemaphore to ensure that a priority inversion solution is in place.

Do you have any thoughts on this?

[wysota]

I'm not sure what you mean, the following sentence seems to be misedited which makes it lose its sense.

Do you see any potential priority inversion condition that could occur wherein the GUI thread, having a lower priority than the producer thread, would be indirectly preempted by the lower priority GUI thread effectively "inverting" the relative priorities of the two tasks?

GUI thread would be preemptied by the GUI thread? Could you explain what you really meant?