[Insight-developers] Transforms and thread-safety
Luis Ibanez
luis.ibanez at kitware.com
Wed Feb 23 16:02:04 EST 2011
Hi Michael,
On Wed, Feb 23, 2011 at 12:52 PM, M Stauffer (V) <mstauff at verizon.net> wrote:
> Hi,
>
> I'm working with Brian Avants on the new registration framework, and the
> thread-safety of transforms is one of the issues we're facing. From what
> we've heard and seen, transforms are not thread-safe, or at least
> assumed not to be.
That's correct,
Transforms are not thread-safe.
...and can't be made thread safe without a hit in performance.
( e.g. a heavy use of Mutex Locks)
> I haven't yet looked closely yet at why, but obvious
> candidates are the SetParameters function which shouldn't be accessed by
> simultaneous threads, and the TransformPoint routines could pose
> problems of course.
>
The GetJacobian() is another one,
since the Jacobian is a state-ful member variable
> Does anyone have specific information about the issues with
> thread-safety of transforms?
>
I'm happy to tell you more...
> It's looking important to find a way to make them thread-safe if
> possible, at least for certain uses such as in ResampleImageFilter, e.g.
> just for calling TransformPoint. I'm willing to help.
>
There is not real need of making them thread safe.
Instead, you can clone them in the BeforeThreadedGenerateData()
method, and use a cloned-Transform per thread.
The cloning can be done with the "CreateAnother()" method.
> Currently when ResampleImageFilter is used with multi-threading enabled,
> a copy of the assigned transform is made for each thread in
> BeforeThreadedGenerateData. This sidesteps any thread-safety issues, of
> course.
Right...
> Some preliminary testing suggests the overhead from this copying
> is not insignificant, but more importantly, we'll soon be using
> DeformationFieldTransforms and BSpline txf's that use large images as
> their transformation parameters, and we expect the overhead of copying
> them for each thread to be a problem.
>
Good point,...
The cloning approach doesn't scale here...
Do these parameters change depending on the point that
is being transformed, or for which the Jacobian is being computed ?
> Perhaps we could have an IsThreadSafe method that defaults to returning
> false in TransformBase, and derived classes that are known to be
> thread-safe could override with true. Then routines like
> ResampleImageFilter would only have to make copies of a transform if it
> says it isn't thread-safe. This might end being more like a
> TransformPointIsThreadSafe method, since full thread-safety might not be
> possible. This method would say whether a transform's TransformPoint
> method is thread-safe, which would be useful for ResampleImageFilter
> since that's all it does with the transforms.
>
That sounds like an option...
In particular, it may make more sense to mark
what methods from the Transform class are
thread-safe, and which ones are not.
> As a fallback, we could implement a read-only transform cloning method
> where the parameter buffers are shared between copies, if the
> thread-safety issues lie more at the heart of Transform.
>
I would think that for the "ResampleFilter" you only need to
call the "TransformPoint()" method, isn't it ?
> Thoughts? Thanks.
>
> Cheers,
> Michael
>
It may be more effective to have a Skype chat about
these details. We could schedule one for Thrusday
or Friday if you are available.
Thanks
Luis
More information about the Insight-developers
mailing list