Std::future::get/wait equivalent in juce::Thread

General JUCE discussion
21

To be honest if you’re doing this in a processBlock I would strongly suggest trying to make it all work single threaded without any threading if you can. ThreadPool uses locks internally so at an absolute bare minimum at least make sure no methods are called on the ThreadPool from anywhere other than processBlock, but strictly speaking neither a ThreadPool or std::async should ever be used for audio processing. If you continue to use ThreadPool you may also want to construct it using realtime thread priority to hopefully avoid priority inversion by making your audio thread wait for the ThreadPool thread which by default has a lower priority!

2 Likes
22

Thanks for the recommendation, but I need to parallelize. ThreadPool works great.

23

But I did not understand why need the ability to specify the number of jobs when initializing the ThreadPool? Without this, everything works just fine. Does it make sense to make this setting?

24

It’s not the number of Jobs it’s the number of threads, or another way to put it, the maximum number of jobs that can be executed in parallel.

We recently added a new constructor to the ThreadPool on the develop branch which will make it possible to only specify the thread priority without having to change the defaults of the other arguments by using a ThreadPoolOptions struct.

25

I understand, thanks. I read in the description that by default creates a thread pool with one thread per CPU core.