[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                                             |  
--------------------------------------------------------------------+-------
Changes (by wenzeslaus):

  * keywords:  r3.mapcalc => r3.mapcalc, parallelization, pthreads,
               workers, nprocs


Comment:

 Replying to [comment:14 neteler]:
 > Replying to [comment:13 wenzeslaus]:
 > > Replying to [comment:12 glynn]:
 > > > Replying to [comment:11 wenzeslaus]:
 > > >
 > > > > I though that `putenv("WORKERS=1")` solved it and I don't have to
 set anything, is that right?
 > > >
 > > > Actually it probably needs to be `putenv("WORKERS=0")`. WORKERS=1
 will create 1 additional thread, but will also execute code in the main
 thread.
 > >
 > > This makes sense although it is not consistent with other usages of
 `WORKERS`:
 >
 > ...
 >
 > Just a (user) comment:
 >
 > In general the notion of WORKERS=0 is a bit strange from a user's point
 of view.
 > I know that it is C notion but not quite human readable. Most users will
 put WORKERS=1 and then, suprise, find two parallel threads (?)...

 If this is true, this wouldn't be even C. In C 1 still means one and 2
 two. For ordinal numbers, 0 means first, 1 means second. So, 0 for one
 item and 2 for two items would be still wrong.

 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. So, you have at the and `WORKERS` plus one threads (main
 thread and additional thread according to `WORKERS`). And this is the
 inconsistency with the other usages of "workers" or "nprocs".

 However, I was not able to understand more about how the code is
 executed/distributed between main thread and additional threads 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.

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