I think the correct method is to call start() not run(). The start() create a thread and call run() method, the default run() method call exec() otherwise use your inherit run() function.

• Do not [developer.qt.nokia.com] subclass QThread
• If you subclass QThread, run() should be protected, not public
• The first snippet executes run() in the secondary thread, the latter snippet executes run() in the main thread

kb1234 wrote:

When we use QThread::start to run a function in a separate thread the output of the application changes. Can anyone suggest reasons why the behavior would vary?

What changes, and how it did look like before and after?

stuk,
Thanks for the reply. I know the correct call for executing the run function in another thread is start. What I am wondering is why when I call my inherited run function I get a different result than running the start function. Intuitively the only difference is that the start function runs the code in a separate thread, but this should not matter because in my example I am blocking the main thread anyway.

Lukas,
Thanks for the reply.

1) My code looks exactly like the threading example in th link you provided. Inherit from QThread and overright the run function. Why do you say to not subclass it as they do in the example.

2) Why does run have to be protected not public? And how would this affect the given example.

3) I know the first snippet executes run() in a secondary thread and the second executes run() in the main thread. They question is it affecting what the run function does? It seems to me that it shouldn’t matter, the run function should do the exact same thing.

1) What Lukas was referring to was this [labs.qt.nokia.com]. It is no longer recommended to subclass QThread. You can still do it and it will work if you avoid the pitfalls, but using the recommended approach alot of the pitfalls are eliminated.

2) If you implement a public run() method the inherited protected run() method is not changed and I guess that was not what you wanted.

3) I got no clue ^^
I guess this has to do with the actions performed by the ITK function your calling. If you want to find out whats happening you can debug into the ITK code.

KA510,
Thanks for the reply.
1) Thanks for providing the link and completing the answer. I am familiar with this. This shouldn’t matter for this example. moveToThread() is not being used and no other complicated thread handling is being done.

2) I’m not sure about this statement. start() still calls the overwritten run method whether it is public or protected. In the actually code we will want to have run protected and use start. However we need to resolve the deviation in behavior first.

3) That makes two of us. I’m hoping someone will have some potential causes that I could go looking for. As of now I don’t know where to start looking. I can’t directly debug as I only get binaries from the third party ( I have the ITK source code, but not the source code of the library that uses it ).

It would help a lot if we actually would know “what” changes and “how it” changes.

Lukas,
I know that would be helpful, but I didn’t know how to succinctly state it. The library performs image registration and segmentation. Basically the reported alignment is slightly varied. About a 10% difference in voxel classification occurs. The benefit of OOP is in play where a very complex procedure is wrapped inside of a single function call into a 3rd party library. Thats why I’m asking for general things to investigate.

Hm… there should be no difference between having code run in one or another thread (the main thread is just an ordinary thread after all).

Does classifying the same image in the same thread twice result in the same output?
Does classifying the same image twice (different instances of the application) result in the same output?

Have you tried asking at the ITK mailing list or the creator of the library?

Lukas,
Thanks for suggestions.

Lukas Geyer wrote:

Does classifying the same image in the same thread twice result in the same output?

Lukas Geyer wrote:

Does classifying the same image twice (different instances of the application) result in the same output?

Lukas Geyer wrote:

Have you tried asking at the ITK mailing list or the creator of the library?

Lukas Geyer wrote:

Does classifying the same image in the same thread twice result in the same output?