Hi Cyril,
As @jhlegarreta mentioned, we are testing and documenting ways to address the migration beyond threadId
in the ITK Software Guide and ITK 5 Migration Guide. threadId
is no longer available for performance reasons. See the discussion here:
Currently, a workaround is to call this>DynamicMultiThreadingOff()
in the filter constructor. This will use the old, non-Dynamic
method, with a threadId
but it is also limited to the previous threading backend.
However, there are only a few common patterns where threadId
appears to have been applied. We are working on testing and documenting alternative approaches for these patterns that work with the new dynamic backends. For example,
- Intermediate values are accumulated in each work unit
- Counting is accumulated
What is the use case in your filter for threadId
?
Thanks,
Matt