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