pater design for qthread manager

[Talei]

Hello,
I have a question regarding pattern design for thread management class.
Basically I have application that can run n threads, I don't know n because it can be set by the user.

The question is:
is it good idea to put qthreads in i.e. qlist and then manage them (add, remove etc.) in that meaner, or are there better ways (maybe performance wise?) to do this?

Thanks for info.

[Zlatomir]

A better then "QList" idea is to use QThreadPool (http://doc.qt.nokia.com/latest/qthreadpool.html)

To get more valuable advices i think you must share more info about what problem you are trying to solve with threads and why do you think is better for the user to set the number of threads used?

[Talei]

It's educational question and not a problem per se.
Currently with i7 Core we have 8 thread's and some people would like to do, lets say 2 things at the same time, so I want to implement in my app. how man thread's can be used so one can utilize 100% of cpu or do "background" operation with only 1 thread / core. (I already did implemented that, with option that detects current CPU threads count)

I read about QThreadPool that's why I ask here question regarding opinion. (maybe for another ideas to)

Why using QThreadPool is beter then QList<QThread > approach? With QList I run test with many threads and everything works fine.
IMHO this is similar although I don't know how this compare performance wise.

EDIT:
Situation in with I will use this is:
I have i.e. 2k jobs, those jobs use 100% core each and can be performed in different amount of time. So with Core i7 we have 8 threads, with C2D 2 thread's etc. So I need to create n threads to run n jobs at the same time. But I want have an option to use only 1 core so I can, i.e. browse www. I don't want to delete qthread and class that I move into it because it will be reused for the next operation to maximise performance.

[wysota]

A side note: 'a job' and 'a job' are not equivalent. Resource usage highly depends on the task you are running, even more on the scheduler your system is using and also on what your system is currently doing besides running your tasks. Spawnings threads like crazy, running the same task on them and measuring what number of threads causes the average time per task to be minimal will give useless results. In theory always having "n" threads do the job on an "n" thread system is the optimal solution.

As for QList vs QThreadPool -- it depends how you intend to manage your threads. If you just start them and then want to have a pointer to each of them, QList<QThread*> is ok. If you don't care about threads themselves and are more interested in tasks you run, go for QThreadPool.

[Talei]

No, threads are not spawned like crazy, I just need a manager to manage them, because at design point I don't know if user has CPU with 1/2/4/8 cores/threads (default value is QThread::idealThreadCount() ), also I need to know with thread finished job so I can restart another one (no thread deletion each time).

QList is only a container for threads and there will be like 8 threads max. I also need this value to be changeable by the user so that way app can use 2 from 8 threads for example.

From RTM I see that QThreadPool is similar to the implementation that I did, assuming autodelete is set to false for QRunnable.

I just asked because I wanted to know opinion in that meter.
Thanks again for reply.