[Insight-developers] thread safety (or lack) of transforms
Karthik Krishnan
karthik.krishnan at kitware.com
Wed Aug 13 22:43:30 EDT 2008
I can't see any thread-unsafe methods in the TransfromPoint either, and
I've used the Kernel transforms quite a bit and haven't noticed any
oddities.
I can see that the ComputeWMatrix and all the methods it calls aren't
thread safe, but that is called just once, when defining the transform
from landmark pairs, prior to Resampling. The "TransformPoint" method
itself, I don't see thread safety issues in the Kernel Transforms.
Am I mistaken ?
Thanks
--
karthik
Jim Miller wrote:
> I don't have the code in front of me but why do we need to worry about
> thread safety in the ResampleImageFilter? Does TransformPoint() cause
> some transforms to be modified? I would expect TransformPoint to not
> make any changes to the transformation. In other words, from the
> ResampleImageFilter point of view, it's use of transforms should be
> thread safe. If that is not the case, we should either fix the
> transforms or the filter.
>
>
> On Wed, Aug 13, 2008 at 6:54 PM, Rupert Brooks <rupe.brooks at gmail.com
> <mailto:rupe.brooks at gmail.com>> wrote:
>
> 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 <mailto: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 <mailto: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
> <http://www.cim.mcgill.ca>)
> >>> Ph.D Student, Electrical and Computer Engineering
> >>> http://www.cyberus.ca/~rbrooks <http://www.cyberus.ca/%7Erbrooks>
> >>> _______________________________________________
> >>> Insight-developers mailing list
> >>> Insight-developers at itk.org <mailto:Insight-developers at itk.org>
> >>> http://www.itk.org/mailman/listinfo/insight-developers
> >>>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers at itk.org <mailto:Insight-developers at itk.org>
> > http://www.itk.org/mailman/listinfo/insight-developers
> >
>
>
>
> --
> --------------------------------------------------------------
> Rupert Brooks
> McGill Centre for Intelligent Machines (www.cim.mcgill.ca
> <http://www.cim.mcgill.ca>)
> Ph.D Student, Electrical and Computer Engineering
> http://www.cyberus.ca/~rbrooks <http://www.cyberus.ca/%7Erbrooks>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org <mailto: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
>
More information about the Insight-developers
mailing list