Important: Please read the Qt Code of Conduct -

Single core Virtual Machine and QtConcurrent::run()

  • I've got some code that gets triggered by a QtConcurrent::run( std::bind( myFunc, blah, blah ) ) call.

    On non VM systems it works perfectly (since I'm unable to test/find a single core CPU in 2018), and on VMs that are set to 2 or more cores - it works perfectly.

    If I set my VM (I've tried on Parallels, VMWare, and Virtual Box - all with the same result) to use a single core, my application works fine until the QtConcurrent::run call - the function that makes the call continues just fine - but the function that is supposed to start running concurrently never starts.

    Anybody ever experience this? I'll look into creating a trivial sample - but I've already removed all the code from the triggered function to simply be a call to exit(0) - The code doesn't seem to run.

    Thanks :)

  • Lifetime Qt Champion

    I wondering
    if only one thread possible it might fail as then it would have to use
    GUI thread and that would lag app.
    No errors are returned or any indication of something wrong?

  • It's not "1 thread", it's a single core. A single core can schedule as many threads as a multi-core system. Otherwise the operating system wouldn't boot ;).
    No errors are indicated.

  • Lifetime Qt Champion

    yes of cause. Sorry. wrong line of thoughts.
    Lets see if others have seen same behavior.
    Or have inputs.

  • Hi @VRHans ,

    I have never had a QtConcurrent::run just NOT run. I have had it take like 15 seconds to start a couple times. This is typically because of all the threads are busy.

    A while back, I was doing some simulation work and the API (not Qt) only allocated one thread per core as the default for the thread pool. I could specify more or I could just create a worker thread without using the pool. I asked my mentor why so few threads in the pool. He told me that this was a good rule of thumb for threads vs. cores for an application for real-time programming.

    Two questions for you:

    1. Have you tried setting QThreadPool::maxThreadCount to increase the number of threads?
    2. Have you checked idealThreadCount ()?

    Another idea you could try, is to queue up the operations you want to do in threads and then start a single thread to process the operations. I do this with SQL database access for logs, alerts, and terrain.

  • It turns out the problem is that on a single core VM (Parallels, VirtualBox, VMWare) QThreadPool initializes with a max thread count of 1 (when I would presume it should be 2.)

    @Buckwheat - I've let it run overnight without the runnable executing.

    I presume it's using QThread::idealThreadCount() and it's either not able to discern that it's a single core or it returns an ideal thread count that I would expect for an embedded system - not a desktop.

    On desktop systems, every since the advent of hyperthreading, and cores with 2 or more hardware threads, the usual algorithm is # of cores * 2 - meaning the threadpool should have an initial max size of 2.

    QThreadPool::globalInstance()->setMaxThreadCount(2) resolves the issue.

  • @VRHans

    I am glad that setting the maxThreadCount solved your problem. I was hoping to lead you in that direction without physically telling you. And, yes, I am aware of the hyperthreading count :D

Log in to reply