[Insight-developers] thread safety (or lack) of transforms

[Rupert Brooks]

In that case, I think its a bug that the ResampleImageFilter treats it
as threadsafe.  I've reported it here.

http://www.itk.org/Bug/view.php?id=7488

I might adopt that one eventually, given that its gotten in my way before.

Cheers,
Rupert

On Wed, Aug 13, 2008 at 6:23 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Stephen,
>
>
>               You are right.
>
>    The Transforms are not thread-safe.
>
>
> Rupert:
>
>  The way to use the Transforms in a multi-threaded
>  environment is to clone them before spawning the
>  threads.
>
>
>  You may want to take a look at the file:
>
>          Insight/Code/Review/
>             itkOptImageToImageMetric.txx
>
>   lines 250-264, in the MultiThreadingInitialize()
>   method.
>
>   It shows how to clone N transforms that are then
>   passed to N threads.
>
>   This is the method we are using now for the
>   multi-threaded metrics.
>
>
>
>  Please let us know if you run into any problems
>  while using this method.
>
>
>     Thanks
>
>
>
>        Luis
>
>
>
> -------------------------
> Stephen Aylward wrote:
>>
>> I believe that transforms (including calls to transform point) cannot
>> be assumed to be thread safe.
>>
>> The reason is the kernel transforms as you suggested.  I believe the
>> thin-plate spline and elastic body spline transforms were the main
>> problems.
>>
>> I could be mistaken.
>> s
>>
>> On Wed, Aug 13, 2008 at 5:43 PM, Rupert Brooks <rupe.brooks at gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> A quick question about thread-safety of transforms.  Are transforms
>>> supposed to be thread safe?  Are specific functions threadsafe and
>>> others not?
>>>
>>> The optimized image metrics are specifically designed to duplicate the
>>> transform for each thread.  However, the ResampleImageFilter does not
>>> and neither does the OptResampleImageFilter in the Review directory as
>>> far as I can tell.  So it appears that the ResampleImageFilter assumes
>>> threadsafety and the metrics dont.
>>>
>>> I suspect that this is because the GetJacobian function is inherently
>>> not threadsafe, but is not used by the ResampleImageFilter and is used
>>> by the metrics.
>>>
>>> Anyway, my question is - does the TransformPoint method of the
>>> transforms have to be threadsafe, or should ResampleImageFilter be
>>> changed?   I ask because I can optimize my modified Kernel transforms
>>> significantly if i do not keep the TransformPoint threadsafe.  This
>>> worked in the image metrics, but blew up in the ResampleFilter when i
>>> tried it.  I was just wondering what the intention was when designing
>>> the multithreaded registration framework.  Briefly - theres
>>> calculations done for the TransformPoint that are also done for the
>>> GetJacobian.  These can be cached, and since the registration
>>> framework tends to call TransformPoint followed by GetJacobian a lot
>>> there is a speed gain.  This could potentially apply to other
>>> transforms, but i cant think of a significant example right off.
>>>
>>> Thanks
>>> Rupert
>>>
>>> --
>>> --------------------------------------------------------------
>>> Rupert Brooks
>>> McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
>>> Ph.D Student, Electrical and Computer Engineering
>>> http://www.cyberus.ca/~rbrooks
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>
>>
>>
>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>



-- 
--------------------------------------------------------------
Rupert Brooks
McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
Ph.D Student, Electrical and Computer Engineering
http://www.cyberus.ca/~rbrooks