[Insight-developers] Re: itkIsoContourDistanceImageFilter, Win32, Fixed, but additional th reading issues

[Raul San Jose Estepar]

Hi Jim,

Thanks you for catching this bug. The memory was initialized only for the
narrowband pixels. I guess the problem was only caused at the boundary
pixels when accessing outer band pixels.
I'm going to remove the narrowband initialization (it's already done in
BeforeThreadedGenerateData).


Regarding the thread-safety problem, we are looking on that. Your
analysis is totally accurate.


/Raul

On Wed, 20 Aug 2003, Miller, James V (Research) wrote:

> I modified the itkIsoContourDistanceImageFilter so the test will pass on
> Windows.  The test for this class checks to make sure the pixels outside the
> levelset and inside the level before and after the reinitialization have the
> same sign.  In the narrow band case, not all the output pixels were visited
> so there the comparisons were using uninitialized memory.  This caused the
> test to fail.  I put code in the BeforeThreadedGenerateData() method to set
> each pixel in the output levelset as either +FarValue, -FarValue or 0.

> There is another problem with this algorithm that could appear when running
> on multiple threads in the narrow band case.  The filter divides the narrow
> band (list of indices) into a set of groups, specifying one group for each
> thread.  This is nice.  However, the algorithm may set pixels in a 3x3x...
> neighborhood of a narrow band pixel.  When running multiple threads this may
> be a problem.  If threads of examining adjacent pixels (or pixels with a
> radius of 2), the two threads may end up trying to set the same output pixel
> at the same time.  This can cause a problem with memory integrity.  The
> situation here could actually be more subtle because before each write
> access to an output pixel, a comparison is done with a current calculated
> value.
>
>             if(fabs(val1_new) < fabs(outNeigIt.GetNext(n,1)))
>               outNeigIt.SetNext(n,1,static_cast<PixelType>(val1_new) );
>
> Consider a thread that is interrupted between the call to GetNext() and
> SetNext().  If the conditional is evaluated as true,
> then the code wants to overwrite the pixel.  But if the thread is
> interrupted after the conditional is satisfied but before the call to
> SetNext(), another thread may come in and evaluate the same output pixel,
> pass its conditional with a value of val1_new that is less than the first
> thread, write the pixel out.  Then when the first thread awakes, it has
> already satisfied its conditional so it writes it version of val1_new.  The
> the first thread had a value of val1_new that is greater than the second
> thread's, the output will be incorrect.
>
>
>
>
>
> Jim Miller
> _____________________________________
> Visualization & Computer Vision
> GE Research
> Bldg. KW, Room C218B
> P.O. Box 8, Schenectady NY 12301
>
> millerjv at research . ge . com <mailto:millerjv at research . ge . com>
>
> james . miller at research . ge . com
> (518) 387-4005, Dial Comm: 8*833-4005,
> Cell: (518) 505-7065, Fax: (518) 387-6981
>
>
>