# Threading refactoring renames

**URL:** <https://discourse.itk.org/t/threading-refactoring-renames/967>\
**Category:** Uncategorized\
**Created:** [May 31, 2018, 7:53pm UTC](https://discourse.itk.org/t/threading-refactoring-renames/967 "2018-05-31T19:53:36Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [June 6, 2018, 6:11pm UTC](https://discourse.itk.org/t/threading-refactoring-renames/967/3 "2018-06-06T18:11:53Z")

</div>

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](https://discourse.itk.org/t/multi-threader-refactoring/840/17), 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::MultiThreaderBase` object. 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.

---

_[View the full topic](https://discourse.itk.org/t/threading-refactoring-renames/967)._