# threadId in ParallelizeImageRegion
**URL:** https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008
**Category:** Engineering
**Created:** [June 15, 2018, 11:52am UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008 "2018-06-15T11:52:34Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@cyril.mory](https://discourse.itk.org/u/cyril.mory)
#### Post date: [June 15, 2018, 11:52am UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/1 "2018-06-15T11:52:35Z")
Hi,
I’m trying to use itk::MultiThreaderBase and ParallelizeImageRegion for the first time. I managed to get it working for one task, so I’m on the right track. But for another task, I need the threads to be able to access their threadId. This thread [Multi-threader refactoring](https://discourse.itk.org/t/multi-threader-refactoring/840) suggests that ParallelizeImageRegion used to have a threadId argument, but it was removed. I’m guessing there still is a way to access the threadId, but I can’t find it.
Regards,
Cyril
---
### Author:  [@jhlegarreta](https://discourse.itk.org/u/jhlegarreta)
#### Post date: [June 15, 2018, 12:03pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/2 "2018-06-15T12:03:58Z")
Hi @cyril.mory,
although @dzenanz will be able to provide a far better explanation than me on the question, if you need the thread number, the backwards-compatibility can be achieved by calling
`this->DynamicMultiThreadingOff();`.
You can find additional explanations on the issue in the [ITK SW Guide](https://itk.org/ItkSoftwareGuide.pdf), **section 3.2.7**
HTH,
JON HAITZ
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [June 15, 2018, 12:21pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/3 "2018-06-15T12:21:52Z")
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](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Documentation/ITK5MigrationGuide.md). `threadId` is no longer available for performance reasons. See the discussion here:
[Multi-threader refactoring](https://discourse.itk.org/t/multi-threader-refactoring/840/26)
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,
1. Intermediate values are accumulated in each work unit
2. Counting is accumulated
What is the use case in your filter for `threadId`?
Thanks,
Matt
---
### Author:  [@cyril.mory](https://discourse.itk.org/u/cyril.mory)
#### Post date: [June 15, 2018, 12:36pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/4 "2018-06-15T12:36:07Z")
I am refactoring the ConjugateGradientImageFilter in RTK ([www.openrtk.org](http://www.openrtk.org)), and at several points in the conjugate gradient algorithm, one needs to compute accumulations.
Since one also needs to apply a linear operator that can be quite complex, which I implemented as a filter, I cannot write the ConjugateGradientImageFilter as a full-blown multi-threaded filter. Which is why I got interested in ParallelizeImageRegion() and the ability it provides to run some multi-threaded code in an otherwise single-threaded GenerateData() method.
Do you think the alternative approaches you mention for multi-threaded accumulation could be available soon ?
Best,
Cyril
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 15, 2018, 12:41pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/5 "2018-06-15T12:41:56Z")
A simple approach that could work in the mean time, is just to add a lock to the accumulator at the end of the threaded method to control access to the final accumulation variable.
---
### Author:  [@cyril.mory](https://discourse.itk.org/u/cyril.mory)
#### Post date: [June 15, 2018, 12:48pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/6 "2018-06-15T12:48:52Z")
Yes, that would work indeed. I have never used ITK’s locks, though. Is there a simple example I could start from ?
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 15, 2018, 12:57pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/7 "2018-06-15T12:57:34Z")
There are two components to be aware of:
- [SimpleFastMutexLock](https://itk.org/Doxygen/html/classitk_1_1SimpleFastMutexLock.html)
- [MutexLockHolder](https://itk.org/Doxygen/html/classitk_1_1MutexLockHolder.html)
The mutex is variable scoped to provide serialized access. For your case, the need is to control access to threads in an instance of the class. So you are looking at a lock with object scope, a member variable.
The holder provides exception safe lock/unlock handling of the mutex via [RAII](https://en.cppreference.com/w/cpp/language/raii).
Here is an example which controls initialization and access to a global variable:
[https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkMersenneTwisterRandomVariateGenerator.cxx#L62-L72](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkMersenneTwisterRandomVariateGenerator.cxx#L62-L72) line 62 to really the only line that does it.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [June 15, 2018, 1:00pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/8 "2018-06-15T13:00:33Z")
> [@cyril.mory](#):
>
> Do you think the alternative approaches you mention for multi-threaded accumulation could be available soon ?
Folks are traveling for the summer, so it may be about a month or two.
---
### Author:  [@cyril.mory](https://discourse.itk.org/u/cyril.mory)
#### Post date: [June 15, 2018, 1:13pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/9 "2018-06-15T13:13:51Z")
Thanks for your help: I managed to get it to work using SimpleFastMutexLock and MutexLockHolder.
Regards,
Cyril
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [June 15, 2018, 3:13pm UTC](https://discourse.itk.org/t/threadid-in-parallelizeimageregion/1008/10 "2018-06-15T15:13:26Z")
If the accumulated variable is of simple type, wrapping it in `std::atomic` would probably be both shorter code-wise and have better performance than using locks.