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

[Glynn Clements]

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.

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. Running:

	nm -D `which r.mapcalc` | fgrep pthread

will confirm that the actual r.mapcalc binary being used was built
with pthread support, in case you have multiple versions of r.mapcalc
and/or libgis on your system.

-- 
Glynn Clements <glynn at gclements.plus.com>