[IPOL discuss] possible bug in NL-means (ipol)

[Mauricio Delbracio]

hi

On Sun, Oct 14, 2012 at 3:41 PM, Nicolas Limare
<nicolas.limare at cmla.ens-cachan.fr> wrote:
> Hi mauricio,
>
>> In NL-means this happens in the filtered image (fpO) which is shared
>> and updated by all the threads. The image is decomposed in overlapped
>> patches that are denoised each of them separately, and then they are
>> aggregated in the final image (fpO). The problem is that when the
>> update of fpO  takes place, may happen that two overlapped patches
>> running in different threads try to update the same memory address.
>
> If I understand correctly that overlapping parts of the image are read
> and modified simultaneously, and if the new values depend of the
> original ones, then there is more than this race condition. OpenMP
> provides no guarantee (by design) on the order of the threads. So if
> two overlapping areas A and B are handled by two different threads,
> there is no way to know in advance if A is processed before B or B
> before A. This may differ across machines, compilers, and even between
> runs with the same binary on the same machine.
>
> Are the results of this code (without your "critical" patch) identical
> when run on different machines and/or compilers?
>
Indeed, the results are different. For example in my portable (two
processors) I couldn't "see" the problem. Also, if you run the code
several times the pixels where the collision take place are different,
therefore leading to different results. The image I sent was generated
in the sel machine.

m-

> --
> Nicolas LIMARE - CMLA - ENS Cachan         http://limare.perso.math.cnrs.fr/
> IPOL - image processing on line                          http://www.ipol.im/
>
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> https://tools.ipol.im/mailman/listinfo/discuss