WOW! Infinite loop to just sleep and process events. Why not just start a timer of PreciseTimer and allow the events to flow freely in the thread? Since you want it to run as fast as possible you can even set the timeout to 0 to run freely when there are no events.
You can then look at thread->requestInterruption () and the thread will comply! Just make sure if you are doing something in a loop in the timer callback you check thread ()->isInterruptionRequested (). And best of all... NO CHECKING THE EVENT QUEUE!
@diverger As @micland already explained this does not have anything to do with Qt. It is a general problem with multi-threading: if you call a method from an object which leaves in another thread then you have to make sure this does not cause any problems.
Thanks for your input - there seem to be some misunderstanding.
I can not and do not want to wait for the acknowledge of the server as a trigger to sent the next log message - this is against the idea.
Log messages need always to be sent, regardless wether the server acknowledges or not - imagine the server even does not acknowledge.
Every message sent has an ID# that is incremented by one for every new log message sent.
The server acknowledges every message with returning the ID#.
Looking at the network of the server with Wireshark and having incoming log messages with time stamps of the same msec - obviously the server has no time to send the acknowledge between incoming protocols. I.e. Sending #1 and # 2 in such a short sequence, obviously when sending #2 the counter for a missed message goes up to one.
This is inherit by this system and is by design.
Therefore, I'm going to implement a gap of at least a few msec between sending messages.
Because the messages are all handled and forwarded in the application by signals / QtEvent queues, I dont have a solid idea so far how to do this.
I may have to create a time gated sending queue before handing the messages over to the signal and the QtEvent queue.
Those 3D displays are kind of handy for visualizing the radio output but they are right now pretty CPU intensive.
If I may insert yet another suggestion here. While I don't believe you'd gain much by using OpenGL painting for the "waterfall" data, I think switching to it for the 3D displays would work better. I nice side effect would be that you can also render OpenGL from different threads, provided the appropriate locking mechanisms are in place. You could, as the most simple test, try using QOpenGLWidget for those FFT displays.
There's no multi-threading involved here whatsoever. All code here runs in a single thread (unless the timer object and "this" actually live in different threads).
There's an event loop running in your app and timer events are just the same as any other. They get put in a queue and processed one after another.
The above will basically mean that your slot is run every time Qt processes messages. It can have very bad influence on your app responsiveness if what you do in the slot is heavy.
The most obvious question is: if you want a thread why not use an actual QThread instead of emulating it like that?
Your first assumption is incorrect:
/* Thread not started, Mutex is not necessary */
What if someone calls startThread() after the thread is started (it is not correct, but can and possibly will happen)... So fist check m_run before going on to start the thread.
Make the intention clear: Either make m_run atomic using either Qt atomics or C++11 atomics or protect it with mutexes wherever it is used. Then you do not need to worry about the way that it is implemented on the specific compiler. If it is really timing critical code then you can start to worry about the additional overhead. From a maintainability and readability point of view it is then easy to know that the variable in question can be accessed from other threads. From my understanding reading is mostly atomic, thus you do not need the locking for the read.
Mark the variable as volatile.
To answer the second question:
Is it even necessary to use a mutex when a variable will only we written by one thread while other threads only read this variable?
If you can guarantee that this will always be the way that it will be used then it should be ok. So if you are the only one developing on the code, and that will use the code perhaps you can. But if you share the code or need to re-use some parts down the line (in a few years perhaps) you might not remember that there is such a limitation. Rather safe than sorry.
I hope this helps a bit, someone else might have better insights.
@koahnig actually the project is using lots of locally compiled libs so a "quick" recompiling is not a possible solution to try out (qt uses different compiler with version newer than v5.2).
However, once getting back to my problem I tested some debug config checkboxes and it turned out that the debug helpers were the "problem". Turning off showing thread names did not cause the debugger to stop deep in qt code several times anymore.
In the end it is a pity not understanding what is going on when ticking that config option, though I am glad getting back to debugging now!
nections, the parameters must be of types that are known to Qt's meta-object system, because Qt needs to copy the arguments to store them in an event behind the scenes.
Call qRegisterMetaType() to register the data type before you establish the connectio
I had a quick look at your code. It's too big for me to go through properly, and I didn't spot anything obvious that maxes out your CPU.
However, I noticed a few things which might be related:
Your ModelExportHelper constructor is run in the main thread, so it opens the DB connection in the main thread. Are you sure you can use that connection in the worker thread after this?
In line 56 of modelexportform.cpp: the lambda runs in the signalling (GUI) thread, not the worker thread. Note that, while the QThread manages the worker thread, the QThread object itself lives in the GUI thread.
Your ModelExportHelper uses some GUI-related classes: QGraphicsView, QPixmap. These classes must only be used in the GUI thread.
Your ModelExportHelper includes "modelwidget.h". Why? Widgets must only be used in the GUI thread.
I have shown only a simplified version of my code.
Actually I have lots of networking happening serially and parallel.
I transferred all of this to a new thread so as to keep my GUI thread free.
Thanks for your advice!