Before trying QThreadPool, I believed that multi-threads program may have uncertain result depending on how the OS schedule it.
However, my opinion was a little changed today.
Here is the code from main.cpp:
runnableInst *hInst = new runnableInst("StarWar");
runnableInst *thread = new runnableInst("BlackSmith");
QThreadPool::globalInstance()->start(hInst);
QThreadPool::globalInstance()->start(thread);
Here is the run function.
void runnableInst::run()
{
// while(1) {
for(int i = 0; i < 50; ++i) {
qDebug()<<"CurrentThread="<< QThread::currentThread();
qDebug()<<threadName + " is outputing. Count="<<i;
Sleep(100);
}
}
Here is part of the result.

It seems that the two threads are running by the order of adding to the thread pool. Does it means that we won’t have a random thread executing result with class QThreadPool?
No, it does not.. and yes, it does:
Thread scheduling is never random – it is precisely determined by the scheduling algorithem used and the state of all the threads at the time the scheduler/dispatcher runs. In many designs/systems/scenarios, it can appear pseudo-random, but your example is not one of them
In you example, your runnables do so little actual work that the two pool threads are just drawing and executing them alternately. 99.99% of the time, both threads are blocked on the sleep(100) call. At the end of that time, both threads will get another runnable, one slightly in front of the other.
The scheduling behaviour you see is an artifact of your example code. You cannot extrapolate it to other designs and/or behaviour in general.