[GRASS-dev] r.mapcalc in trunk with pthreads broken

[Markus Metz]

Markus Metz wrote:
> Glynn Clements wrote:
>>
>> Markus Metz wrote:
>>
>>> I am observing corrupted output from r.mapcalc in trunk if compiled
>>> --with-pthread. The result is not identical to the one obtained
>>> --without-pthread. The mapcalc expression included the functions
>>> eval(), min(), and max(), in case that helps. Open a ticket?
>>
>> Yes.
>>
>> Also, can you describe whether (and how) the behaviour is affected by:
>>
>>        export WORKERS=1
>>
>> The WORKERS environment variable controls the maximum number of
>> threads used; the default value is 8.
>
> With WORKERS=1, the r.mapcalc result is identical to pthreads
> disabled, i.e. correct. Do you need more info?

More info:

I think the bug is not caused by the combination of pthreads with
eval(), min(), or max(), but rather when the same raster map appears
twice in a r.mapcalc expression. A simple example would be

r.mapcalc "result = if(isnull(map1), map2, map2 + map1)"

Maybe in r.mapcalc/map.c, get_map_row()

    pthread_mutex_lock(&m->mutex);

has no effect and the same file is accessed twice at the same time,
causing garbage?

Markus M