QtConcurrent::blocking* thread count

[ibex]

You can't "reuse" a thread while it is blocked

I appreciate that. Rather than blocking the calling thread you could use it to perform some of the computation.

If you have 4 cores then the default thread pool can simoultaneously perform 4 jobs. It has nothing to do with the number of threads in your application.

The point being in my example there was one (global) thread pool which had spawned the caller of QtConcurrent::map. I don't think there is any mechanism for map and the pool to determine that one of the pool spawned threads is blocked and therefore all cpu resources won't be used. On a unicore machine the situation is worse. maxThreadCount would be 1, but 1 thread would also be in use so the map's thread request would be queued indefinitely.

I think a solution for me would be to increment the pool's maxThreadCount immediately before calling map and decrement it immediately after, since I know the origin of the calling thread. Hopefully this will be ok since "All functions in this class are thread-safe".

[wysota]

Rather than blocking the calling thread you could use it to perform some of the computation.

That's what you should do - you schedule a bunch of jobs and continue with your normal operations. Then at some point when the results are ready you query for them and use them.

The point being in my example there was one (global) thread pool which had spawned the caller of QtConcurrent::map. I don't think there is any mechanism for map and the pool to determine that one of the pool spawned threads is blocked and therefore all cpu resources won't be used.

I think you still fail to get the picture. The pool contains 4 threads. You schedule some job so a thread is spawned reducing the available number of threads to 3. Then you schedule another job and since three threads from the pool are available at the moment, 3 will be used. When the first thread finishes execution, QtConcurrent will use it for the other operation if some work still needs to be done. This all has nothing to do with all other possible threads in your application.

On a unicore machine the situation is worse. maxThreadCount would be 1, but 1 thread would also be in use so the map's thread request would be queued indefinitely.

This is only the case if you schedule a blocking job from within a job already performed on the thread pool. Like so:

void func() {
  QList<QImage> imgs = makeList();
  QtConcurrent::blockingMapped(imgs, someFunc);
}
// ...
QtConcurrent::run(func);

void func() {
  QList<QImage> imgs = makeList();
  QtConcurrent::blockingMapped(imgs, someFunc);
}
// ...
QtConcurrent::run(func);

To copy to clipboard, switch view to plain text mode 

This is why you have QThreadPool::releaseThread():

void func() {
  QList<QImage> imgs = makeList();
  QThreadPool::globalInstance()->releaseThread();
  QtConcurrent::blockingMapped(imgs, someFunc);
  QThreadPool::globalInstance()->reserveThread();
}
// ...
QtConcurrent::run(func);

void func() {
  QList<QImage> imgs = makeList();
  QThreadPool::globalInstance()->releaseThread();
  QtConcurrent::blockingMapped(imgs, someFunc);
  QThreadPool::globalInstance()->reserveThread();
}
// ...
QtConcurrent::run(func);

To copy to clipboard, switch view to plain text mode 

[ibex]

I think you still fail to get the picture. The pool contains 4 threads. You schedule some job so a thread is spawned reducing the available number of threads to 3. Then you schedule another job and since three threads from the pool are available at the moment, 3 will be used. When the first thread finishes execution, QtConcurrent will use it for the other operation if some work still needs to be done. This all has nothing to do with all other possible threads in your application.

Yes, we seem to be thinking along different lines. My current design is like this:
a) 1 master thread to handle the event loop and drawing
b) Possibly multiple computation jobs that can be launched concurrently in separate threads, but most commonly only 1.
c) The possibility of improving the performance of the jobs by parallelising critical sections (ie. QtConcurrent::blockingMap instead of OpenMP)
All threads except for the main one would be managed by a single thread pool and these would be the only intensively used ones.

This is why you have QThreadPool::releaseThread()

Thanks, this is a better alternative than my last suggestion and solves my problem I think
I should have read the documentation more carefully...