[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