[Insight-developers] thread safety (or lack) of transforms
Rupert Brooks
rupe.brooks at gmail.com
Thu Aug 14 07:50:59 EDT 2008
Whoops, maybe I jumped the gun posting this as a bug.
Just to be clear - as far as i know, at this time the transform point
methods for all the transforms are threadsafe. Its new features that
I personally am interested in that would break this.
Right now the optimized image metrics treat the transforms as
non-threadsafe, and the resample image filter does not. I can rewrite
the Kernel Transforms more efficiently if i make the TransformPoint
method non-threadsafe. This is mainly for my own purposes, although I
am sharing what I am doing in the Insight Journal. But this would
break the current implementation of ResampleImageFilter. I wondered
what the design intention was - whatever it is, i will go along with
it.
So I think the design issue is: Is the whole transform object not
threadsafe, or is thread safety managed on a method by method basis.
I think the GetJacobian method is the biggest problem - it passes back
a reference to an internal object. This applied to all transforms,
not just Kernel transforms. But - this is only used in the image
metrics, not the resamplers.
Rupert
On Wed, Aug 13, 2008 at 10:43 PM, Karthik Krishnan
<karthik.krishnan at kitware.com> wrote:
> 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
>>
>
> _______________________________________________
> 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
More information about the Insight-developers
mailing list