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

Jim Miller millerjv at gmail.com
Wed Aug 13 21:37:59 EDT 2008


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>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>
> 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 <http://www.cyberus.ca/%7Erbrooks>
> >>> _______________________________________________
> >>> 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 <http://www.cyberus.ca/%7Erbrooks>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080813/4444bd70/attachment.htm>


More information about the Insight-developers mailing list