Why do I get different results from QThread Run and Start methods?



  • I have an existing applicaton that I am trying to have better utilize system resources and in doing so am making the application multi-threaded. When we use QThread::start to run a function in a separate thread the output of the application changes. To evaluate this I wrote a simple test.

    For comparison if I do the following:
    @
    InheritsQThread* t = new InheritsQThread();
    t->start();
    t->wait();
    @

    I get different results than:
    @
    InheritsQThread* t = new InheritsQThread();
    t->run();
    t->wait();
    @
    The InheritsQThread inherits from QThread and provides nothing but a run function. The run function calls a function in a third-party library based on itk. I have no visibility into this function.

    Here I would expect the main thread to do nothing while the child thread runs, and so the two should produce identical results. Can anyone suggest reasons why the behavior would vary? The only thing I can think of is that the function might use a random number generator and maybe Qt reseeds it during creation of the thread?

    Thanks

    [Edit] Please "wrap your code in tags ":http://developer.qt.nokia.com/wiki/ForumHelp



  • 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.



  • [quote author="kb1234" date="1328714071"]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?[/quote]

    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":http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/. 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.

    [quote author="Lukas Geyer" date="1328775254"]
    Does classifying the same image in the same thread twice result in the same output?[/quote]
    I'm not sure, never tried it. I will test it this morning.

    [quote author="Lukas Geyer" date="1328775254"]
    Does classifying the same image twice (different instances of the application) result in the same output?[/quote]
    Yes.

    [quote author="Lukas Geyer" date="1328775254"]Have you tried asking at the ITK mailing list or the creator of the library?[/quote]
    ITK - no, I'm trying to get more details so that I know what classes/functions in ITK are being used
    creator - yes, they have no idea



  • [quote author="Lukas Geyer" date="1328775254"]
    Does classifying the same image in the same thread twice result in the same output?[/quote]
    Yes. Executing run twice sequentially creates identical results and executing start twice sequentially creates identical results.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.