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

[Markus Metz]

Glynn Clements wrote:
>
> Markus Metz wrote:
>
>> > 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?
>
> I can't reproduce this.

I can't reproduce this either with the sample datasets. Maybe this
happens only with larger raster maps? The mismatch occurs with raster
maps with 400 million cells.

>
> Can you confirm that you did "make clean" before or after running
> configure? Using a non-threaded r.mapcalc with a threaded libgis could
> cause this problem.

Compiling trunk takes about 2 minutes on my test system, I don't know
pthreads, so I decided to stay safe and did make distclean before
reconfiguring and recompiling with/without pthreads. And my local copy
has no modifications in r.mapcalc or libgis.

Markus M