Qt multi-thread application freezes and several threads wait for the same mutex

[anda_skoa]

It is strange that both thread's stack claim that the execution started in main() and that both are inside the main application event processing.

Are those additional threads using QThread?
If yes, are you using the method of reimplementing run(), per-thread event loop or both?

Cheers,
_

[gzh]

It is strange that both thread's stack claim that the execution started in main() and that both are inside the main application event processing.

Are those additional threads using QThread?
If yes, are you using the method of reimplementing run(), per-thread event loop or both?

Cheers,
_

Thanks.

I create a QObject( show as SystemEventImp class in backtrace), and use movetoThread() to run it in an independent thread created by QThread.
In SystemEventImp, I register some event handler and maintain an event queue.

I did not reimplementing run(). Besides SystemEventImp Object, I created another Object named EventManager, which will call movetoThread()
to move to the same QThread object SystemEventImp are running. EventManager::ProcessQueue() will be called to start a infinite loop to process
those events maintained by SystemEventImp.

[anda_skoa]

Ok, so kind of a hybrid approach: using moveToThread() like in the case of an event loop based thread but running your own loop like in a subclassed thread.

How to you start your own loop?
Do you register your event handlers in the secondary thread context?

Cheers,
_

[gzh]

Hi, anda_skoa

> Do you register your event handlers in the secondary thread context?
When I create SystemEventImp Object, I register my event handlers, indeed, SystemEventImp have a member variable of map type to record <event, handler> pairs.
The registration was done before moveToThread().

>How to you start your own loop?
It seems that the loop started by calling EventManager::ProcessQueue() directly from main thread.
It is a legacy source code, I am not very sure about it.
Can this can explain your first question, i.e. "It is strange that both thread's stack claim that the execution started in main() "?

[anda_skoa]

It seems that the loop started by calling EventManager::ProcessQueue() directly from main thread.

Hmm, what does that method do?
Its name sounds like it would do the actual event processing, i.e. the loop you mentioned earlier.
But it doesn't make sense to move the object to another thread and then still let the main thread to the work.

Do you call start() on the thread object?

What kind of technique are you using to make the secondary thread call the worker objects methods?

Can this can explain your first question, i.e. "It is strange that both thread's stack claim that the execution started in main() "?

No, not yet.

I don't quite yet understand the setup you are using.
Very uncommon to call a method on an object that has been moved to another thread.

Cheers,
_

[gzh]

Hi, anda_skoa,

Sorry, I have to revise what I said about event processing in my application. Indeed, It works like the followings.

1) I did not create event loop for those threads besides main thread, all threads are using the eventloop in main thread.

2) When SystemEventImp object created, map of <event, handler> pairs will be initialized. there are many types of event, but handler
is only SystemEventImp object, one of its member variable is a list of handler.

3) I create QThread instance, e.x. named subThread, Besides call SystemEventImp->moveToThread(subThread), subThread::start() will launch a
periodic timer, that timer will create timer event to force screen redraw periodically in main thread.

4) Besides those two threads I mentioned, there are other threads that will use call QCoreApplication:ostEvent() to append event to main event queue.
when the event's handler is SystemEventImp object, it will be handled in the subThread I created.

I am not familiar with QThread and its scheduling policy, I want know whether my event processing method will run into a race condition and incur that freeze as I showed on my question.

[Cruz]

Hi,

I don't understand the details of the constellation gzh described, but the most common reason for this deadlock to occur is when a mutex is never unlocked. After several days of running, this could happen imho when a thread segfaults or throws an exception, or is coded in a way that it is possible for it to bypass the thread unlock. Wouldn't it be easier to approach this problem from a code analysis perspective? So far, no source has been shown...

[anda_skoa]

3) I create QThread instance, e.x. named subThread, Besides call SystemEventImp->moveToThread(subThread), subThread::start() will launch a
periodic timer, that timer will create timer event to force screen redraw periodically in main thread.

How is it launching that timer and why is the subThread doing that when the timer needs to trigger work on the main thread?

Which method of the SystemEventImp is being called by the subThread and how?

I am not familiar with QThread and its scheduling policy, I want know whether my event processing method will run into a race condition and incur that freeze as I showed on my question.

I doubt this is a matter of scheduling policy and that is handled by the operating system anyway.

It is far more likely that you are dealing with a situation where things are not executed by the thread you think they are.

For example you say that the main thread is executing EventManager::ProcessQueue() but you also say you have moved the object to another thread.

What does the other thread use the object for? Which of its methods does it call?

Cheers,
_