[Insight-developers] BSplineInterpolateImageFunction

[Joshua Cates]

> Another approach is to provide an API where the matrices 
> can be passed into the routine.  This is equivalent to the 
> netlib routines where you have to pass in the "scratch" space...

I used this approach in the itkFiniteDifferenceFunction classes.  Before
the "inner loop" of the routine, each thread in the calling program asks a
function object to allocate a struct and return a pointer to that struct.  
The contents of this "scratch memory" struct are entirely up to the
function object.  The scratch memory pointer is passed as an argument on
each call to the function object's const "Calculate" method.  Each thread
passes a different block of memory.  The function object uses this scratch
memory to cache values, read thread numbers, or whatever else is
appropriate.  When the calling program finishes its routine, it asks the
function object to destroy the struct.

This approach allows you to keep the Calculate method as a const method, 
but maintain a separate state for each thread and avoid allocating new 
memory at each call.

For example, the LevelSetFunction object uses it's scratch memory to
precompute and store various derivatives that are used multiple times in
virtual methods (i.e.  curvature computations).  It also maintains global
max change values for use in computing the time step at each iteration.

Josh.

______________________________
 Josh Cates			
 Scientific Computing and Imaging Institute
 University of Utah
 Email: cates at sci . utah . edu
 Phone: (801) 587-7697
 URL:   http://www . sci . utah . edu/~cates


On Thu, 18 Dec 2003, Miller, James V (Research) wrote:

> I think is Lydia is right.  If these local variables are made 
> ivars then the methods would not be thread safe. 
> 
> I favor erring on the side of being too thread safe. It is just too
> hard to find threading errors when they occur to promote being 
> non-thread safe.
> 
> Another approach is to provide an API where the matrices 
> can be passed into the routine.  This is equivalent to the 
> netlib routines where you have to pass in the "scratch" space.
> This approach would allow each thread in an algorithm to pass 
> its own scratch space down to the method on each call.  The 
> scratch space would then only have to be allocated once 
> per thread instead of once per call.
> 
> 
> -----Original Message-----
> From: Lydia Ng [mailto:lng at insightful . com]
> Sent: Thursday, December 18, 2003 7:09 PM
> To: Brad King; Insight Developers
> Subject: RE: [Insight-developers] BSplineInterpolateImageFunction
> 
> 
> Question: if I make these member data and mutable does that mean one can't
> use the same interpolator in different threads of a filter?
> 
> In the past we had several discussions of const-ness and thread safety
> regarding the interpolators. To make everyone happy - the function is both
> const and thread safe - the lowest common denominator even though it is at
> the expense of dynamic memory allocation.
> 
> Perhaps we need to make some of sort of community decision of what objects
> and what methods need const and/or thread safe.
> 
> - Lydia
> 
> > -----Original Message-----
> > From: Brad King [mailto:brad . king at kitware . com]
> > Sent: Thursday, December 18, 2003 1:40 PM
> > To: Insight Developers
> > Subject: [Insight-developers] BSplineInterpolateImageFunction
> > 
> > Hello,
> > 
> > While tracking down a recent test failure, I noticed that
> > BSplineInterpolateImageFunction has vnl_matrix local variables in its
> > EvaluateAtContinuousIndex and EvaluateDerivativeAtContinuousIndex methods.
> > When used in a registration method, this effectively does a dynamic memory
> > allocation and free per pixel!
> > 
> > I think these variables should be changed to member data for the class.
> > Since EvaluateAtContinuousIndex and EvaluateDerivativeAtContinuousIndex
> > are const methods, the matrices will have to be mutable (whether these
> > methods should be const is a separate discussion).  I expect a substantial
> > speed improvement will be achieved by this relatively simple change.
> > 
> > Will the author of this class please look at making the change?
> > 
> > Thanks,
> > -Brad
> > 
> > _______________________________________________
> > 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk . org
> http://www . itk . org/mailman/listinfo/insight-developers
>