Signals are delayed on X11?

[Cruz]

Ok I understand thread affinity and thread event loops now.

The two Qthreads are both created in the main thread. The internal objects the threads use are created in the thread where appropriate. So there is nothing I would need to move to a thread.

The internal objects of the threads don't need any signal handling, so the threads don't need any event loops. The signals of the threads themselves should be queued by the main thread, so everything is ok about this.

The only thing left is to take care of thread safety, when one thread passes a QHash to the other. I started a new topic about this, because this one was actually about delayed signals in X11.

[wysota]

The two Qthreads are both created in the main thread. The internal objects the threads use are created in the thread where appropriate. So there is nothing I would need to move to a thread.

Do you emit signals on behalf of the "internal objects" or the thread object? If "RobotInterface" and "KeyframePlayer" inherit QThread then you are exactly in the situation I'm talking about.

The internal objects of the threads don't need any signal handling, so the threads don't need any event loops. The signals of the threads themselves should be queued by the main thread, so everything is ok about this.

I'm not sure you are right. It would be easier to talk about it if you provided header files for both your classes.

The only thing left is to take care of thread safety, when one thread passes a QHash to the other.

The only clash that may occur in current situation is when emitting the signal carrying the hash but only if you access the same instance of QHash at some other place in code. As long as you use local objects only and make sure they are detached from other instances before emitting them, you should be safe. Just know it's a bad design which can turn into obstacle later on.

[Cruz]

I attached the header files.

All the signals coming from those threads are targeted at the main thread. Except for one, which is the signal that carries the joint angles from the KeyframePlayer thread to the RobotInterface thread. So the point you are trying to make is that I should actually queue this one signal and handle it in the RobotInterface's event loop? I still don't understand why it's a bad thing if the main thread handles the signal. What exactly goes wrong?

[wysota]

All the signals coming from those threads are targeted at the main thread.

That doesn't matter. The thing that matters is where they originate from and that seems to be the thread object which lives in the main thread.

Except for one, which is the signal that carries the joint angles from the KeyframePlayer thread to the RobotInterface thread.

Which is currently handled by the main thread as well.

So the point you are trying to make is that I should actually queue this one signal and handle it in the RobotInterface's event loop?

I mean you should have an event loop there in the first place. And when you do, push the thread object to its thread so that it can handle its signals and slots properly.

I still don't understand why it's a bad thing if the main thread handles the signal. What exactly goes wrong?

It's the slot I'm more worried about. The thing is you access the "txJointAngles" variable from both the main thread and the worker thread. It may happen that you iterate over the container in the "poseDistance" method and at the same time "overwrite" it with a new object using the slot ran by the main thread. This is a classical example of accessing a single variable from multiple threads and requires synchronization. If you not synchronize the threads, the least that can happen is a wrong result of poseDistance() or wrong execution of transmit() (as they both access the variable) and at worst your application will eventually crash (well... that's not the worst at all that can happen but it's still bad).


By the way, if you keep a pointer to the robot interface in the player, there is no point in using signals and slots. Either get rid of that dependency or call appropriate methods directly (probably guarding access to a shared variable with a mutex or such).

[Cruz]

I mean you should have an event loop there in the first place. And when you do, push the thread object to its thread so that it can handle its signals and slots properly.

Aaaah that was enlightening! Or maybe because my brain is fresh now in the morning. You mean I should push the QThread objects into themselves to handle their own signals! In consequence, doesn't it mean that you should ALWAYS do that, whenever you are using threads?

So if I understand right, signals between threads are always queued by default, no matter if it's between a worker thread and the main thread or between two worker threads. The difference it makes is that if a thread handles its own events, you eliminate the possibility of the main thread calling a slot of a worker thread at the wrong time. Is this correct?

t's the slot I'm more worried about. The thing is you access the "txJointAngles" variable from both the main thread and the worker thread.

Yes this is true. As I already said, I haven't addressed the thread safety problem at that time. The application does crash. A lot. As performance is somewhat crucial, I wanted to try to find a way without mutexes. I would prefer a thread not to block and wait for a mutex to open, but to go ahead and calculate the next joint angles in the meantime.

Another thing about mutexes that bothers me is that they need to be global variables known to both threads. At least that's what I saw in the examples and the documentation. The most elegant solution would be something completely contained in one thread, without the other knowing about it.

By the way, if you keep a pointer to the robot interface in the player, there is no point in using signals and slots.

Yes this is also true. The reference is still there because of my poor signal handling that caused the problems in the original post in this topic. If I can rely on my signals being "snappy", then I would prefer to get rid of the reference and hace completely indepedent objects.

[wysota]

In consequence, doesn't it mean that you should ALWAYS do that, whenever you are using threads?

No, that's not always desired. For instance if the thread object has a parent, you can't push it to another thread. Furthermore the thread object is only a controller of the thread so it doesn't have to always be tied up closely to the thread itself.

So if I understand right, signals between threads are always queued by default, no matter if it's between a worker thread and the main thread or between two worker threads.

Yes, that's right. Read about "auto connections" of signals.

The difference it makes is that if a thread handles its own events, you eliminate the possibility of the main thread calling a slot of a worker thread at the wrong time. Is this correct?

Yes.

As performance is somewhat crucial, I wanted to try to find a way without mutexes. I would prefer a thread not to block and wait for a mutex to open, but to go ahead and calculate the next joint angles in the meantime.

So use tryLock() instead of lock() on the producer side.

Another thing about mutexes that bothers me is that they need to be global variables known to both threads.

That doesn't have to be true. You can have a mutex within a singleton class.

The most elegant solution would be something completely contained in one thread, without the other knowing about it.

If that was the case, you wouldn't be accessing the variable you want to protect from another thread. If you want an elegant solution, consider using shared memory (QSharedMemory) to transfer data between threads or processes. You can then split your application into two separate applications - one for performing calculations and the other for driving the robot.