[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   |    Platform:  All                      
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by glynn):

 Replying to [comment:5 wenzeslaus]:
 > I would like to understand. Does the
 {{{
 putenv("WORKERS=1")
 }}}
 > mean that there will be no parallel computation in `r3.mapcalc`?
 Yes. When I added pthread support to r.mapcalc, I largely overlooked the
 fact that it shares most of its code with !r3.mapcalc, and the raster3d
 library doesn't appear to be thread-safe.

 I had to make a few changes to libgis and libraster to allow for multiple
 threads (e.g. r34444), but (as with so many other invasive, project-wide
 changes) libraster3d was deemed too much trouble and was left alone.

 One alternative would be to use a single mutex for all of the functions in
 map3.c. This would allow calculations to be parallelised, but not I/O
 (unfortunately, I/O accounts for most of the execution time).

 The more complex option is to make libraster3d thread-safe, at least for
 accessing different maps from different threads, and have a mutex for each
 map to prevent concurrent access from multiple threads (this is what
 r.mapcalc does). That would require eliminating some or all of its static
 data, or protecting it with mutexes (the functions in lib/gis/counter.c
 can be used to safely perform one-shot initialisation).

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