[GRASS-dev] [GRASS GIS] #2074: r3.mapcalc neighborhood modifier hash table and tile errors

[GRASS GIS]

#2074: r3.mapcalc neighborhood modifier hash table and tile errors
--------------------------------------------------------------------+-------
 Reporter:  wenzeslaus                                              |       Owner:  grass-dev@…              
     Type:  defect                                                  |      Status:  new                      
 Priority:  normal                                                  |   Milestone:  7.0.0                    
Component:  Raster3D                                                |     Version:  svn-trunk                
 Keywords:  r3.mapcalc, parallelization, pthreads, workers, nprocs  |    Platform:  All                      
      Cpu:  Unspecified                                             |  
--------------------------------------------------------------------+-------

Comment(by glynn):

 Replying to [comment:15 wenzeslaus]:

 > The problem is that in [source:grass/trunk/lib/gis/worker.c
 lib/gis/worker.c], the number of ''new/additional workers/threads
 created'' is `WORKERS`. But this means that there is always also the main
 thread too.

 Sort of; if the "force" argument of G_begin_execute() is non-zero, it
 won't use the main thread (so WORKERS=0 will cause it to block forever).
 Currently, nothing does that (r.mapcalc is the only user of that code).

 > However, I was not able to understand more about how the code is
 executed/distributed between main thread and additional threads

 G_begin_execute() attempts to obtain a worker thread. If "force" is non-
 zero, it will keep trying until it gets one. Once this is done, it will
 either instruct the worker (if it got one) to execute the function, or (if
 it didn't get a worker) execute it directly.

 The way this is used by r.mapcalc is that when evaluating a function call,
 if the function only has one argument or is the eval() function, it will
 evaluate the argument(s) sequentially in the main thread, otherwise it
 will attempt to evaluate the arguments concurrently.

 > and if it would be better to have `WORKERS=1` for only one (main)
 thread, `WORKERS=2` for one additional thread etc. (and `WORKERS=0` would
 be invalid or considered the same as `WORKERS=1`). From user point of view
 probably yes but it depends on what is actually happening in the
 implementation.

 I don't have a strong opinion; it would be simple enough to modify the
 code to subtract 1 from the value of WORKERS in determining the number of
 additional threads to create. Regardless, the case of WORKERS=0 and
 force=1 should be fixed (i.e. the force argument should be ignored if
 there is only the main thread).

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2074#comment:16>
GRASS GIS <http://grass.osgeo.org>