Threads in Qt

Greetings. I'm just about to code my project using multhithreading. But before jumping into that, I ran into this article http://doc.trolltech.com/4.2/threads.html which made me think twice about the parallel structure that I initially planned.

The original plan was to create 2 threads: one producer and one consumer thread. The producer thread will acquire data and place it in a buffer then start acquiring the next data. The consumer thread then gets data from the buffer and does the processing. Both of these threads run infinitely and are only controlled using the GUI buttons - start and stop.

I'm using 2 CPUs in my desktop. Now, the fact that I would have to keep my GUI responsive (due to the threads continuously processing data) I will have to have a main thread for my button controls. So all in all, I should be using 3 threads right? Or am I wrong?

Just in case three, will this slow my processes down with the overhead of virtually maintaining an additional thread with only 2 physical cores?

You can do it all in one thread as well :) But indeed going for three threads is the simplest solution. If you have two threads or three threads it doesn't really matter in terms of speed. It is so because there are other processes running on your system too and they occupy the cores as well so context switching is present if you have one thread, two threads or three - your process simply has to share the cores with all other processes.

Once I made some school project with Qt and there was option to specify numer of threads to perform huge amount of simple operations. Benchmarks showed that you get the best performance when using number of threads equal your number of cores (checked on dual and quad core processors). But there wasn't much difference when you used one more thread then number of cores.

I'd like the performance to be well optimized and I'm thinking for another work around. I'd probably think how I could compress the process into two threads. Anyway, is there any other process that the Main thread could do - aside from waiting for a push button?

I would not worry at all about the overhead of the GUI thread. That one is sleeping until it recieves a (window)message. And then you want it to get active. Every other scenario probably includes periodically checking for messages yourself. And that is going to be much more expensive and redundant with the OS implementation of thread scheduling/message posting..

Furthermore thread switching is less overhead than process switching! And even that happens all the time and is really optimized on OS and hardware layer.

Just forget about it and put your energy in optimizing the working threads.

If you are still not certain: Ask yourself about scaling. Does the GUI thread overhead scale with the amount of work? Definitely not! So if you are serious about performance: Forget it.

Cheers!

Johannes