[Insight-developers] Re: Unsafe code in ObjectMorphologyImageFilter

[Julien Jomier]

Hi Jim,

Thanks for looking at this.

> Since the Evaluate() methods touches pixels in the=20
> neighborhood of the output pixel,=20
> it may be setting the value for a pixel that it does not own.=20
> If a pixel in the=20
> neighborhood is the responsibility of another thread, you=20
> could have multiple threads writing to the same pixel.

Each thread will write the same value for this pixel, so this is not a
problem, isn't it?

> The Evaluate() methods need to be fixed such that they limit=20
> pixel writes to the outputRegionForThread.

Then we can be wrong when doing a dilation. For instance, if we have two
threads and the object is right on the boundary of the =
outputRegionForThread
of the first thread. If we do the dilation without updating the second
outputRegionForThread, i.e. setting pixels (which will not be updated by =
the
second thread) then the dilation is wrong.

Julien

> -----Original Message-----
> From: insight-developers-admin at itk . org=20
> [mailto:insight-developers-admin at itk . org] On Behalf Of=20
> Miller, James V (Research)
> Sent: Tuesday, August 19, 2003 9:55 AM
> To: 'Stephen R. Aylward'; Lorensen, William E (Research);=20
> 'Julien Jomier'
> Cc: insight-developers at public . kitware . com
> Subject: RE: [Insight-developers] Re: Unsafe code in=20
> ObjectMorphologyImageFilter
>=20
>=20
> It looks like Julien submitted code to address this problem. =20
> I looked at the solution and I am not convinced this will fix=20
> the problem. (It may move it be less
> likely.)
>=20
> I think the problem with the filter is in the Evaluate()=20
> methods.  The filter=20
> determines whether a given pixel in the input satisfies the=20
> appropriate conditions and=20
> then calls Evaluate().  The Evaluate() method sets (or=20
> unsets) all the appropriate pixels=20
> in the neighborhood of the output pixel.=20
>=20
> Since the Evaluate() methods touches pixels in the=20
> neighborhood of the output pixel,=20
> it may be setting the value for a pixel that it does not own.=20
>  If a pixel in the=20
> neighborhood is the responsibility of another thread, you=20
> could have multiple threads writing to the same pixel.
>=20
> The Evaluate() methods need to be fixed such that they limit=20
> pixel writes to the outputRegionForThread.
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Stephen R. Aylward [mailto:aylward at unc . edu]
> > Sent: Sunday, August 17, 2003 7:09 PM
> > To: Lorensen, William E (Research)
> > Cc: insight-developers at public . kitware . com
> > Subject: [Insight-developers] Re: Unsafe code in=20
> > ObjectMorphologyImageFilter
> >=20
> >=20
> >=20
> > Hi,
> >=20
> > Julien has been working on this as well, and I took a look at
> > it too - I=20
> > am not sure what's up since it even fails on single thread.  =20
> > I'll bump=20
> > it up on my to-do list.
> >=20
> > Thanks!
> >=20
> > Stephen
> >=20
> > Lorensen, William E (Research) wrote:
> > > Steven
> > > I noticed intermittent test failures for the subject
> > filter. I tracked the
> > > problem down to the ThreadedGenerateData method. There is a
> > loop that copies
> > > data from the input to the output region. Unfortunately,
> > since the region
> > > extends beyond the pixels that should be updated in a
> > thread, some of this
> > > pixels overlay pixels in other threads. As a temporary fix,
> > I put a mutex
> > > around the loop. The real fix would be to just copy the
> > pixels that will be
> > > affected in a given thread. Then the mutex can be removed.
> > >=20
> > > Forget half of what I just said...
> > > After putting in the mutex, I get different failures. I
> > think the filter
> > > needs to be reviewed further for thread safety. I suspect the=20
> > > IsObjectPixelOnBoundary is messing up. For now, I've set
> > the number of
> > > threads to 1 for this filter.
> > >=20
> > > Bill
> >=20
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers at itk . org=20
> > http://www . itk . org/mailman/listinfo/insight-developers
> >=20
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk . org=20
> http://www . itk . org/mailman/listinfo/insight-> developers
>=20