Both NumberOfThreads and NumberOfWorkUnits are useful concepts, and it will be fantastic to have them separated in ITK 5.
As explained by @benoit and @warfield in this thread: Multi-threader refactoring, the separation of these two is critical for load balancing, which is critical for performance.
It will be a huge long term benefit to the toolkit if we:
- Have algorithms specify their jobs in terms of work units instead of threads.
- Have a maximum number of threads specified on the
itk::MultiThreaderBaseobject. Since the number of threads can fluctuate throughout execution, and it in general the threading backends sometimes do not want to spawn too many threads, a user-specified maximum is better than a specific value.