Glynn: > To make concurrent access work, updating a map would need to be an > atomic operation, so that any module which reads the map sees either > the "before" version or the "after" version, and never sees an > "in-progress" version. > > This means that while any module is in the process of opening the > various elements that make up a map, the map cannot be replaced.
[somewhat OT, somewhat not] In my mind, due to the upcoming prevalence of multi-core processors working to convert the raster modules take advantage of multi-processor systems is much more important that allowing concurrent use of a single mapset. (not that they are mutually exclusive goals, but it may be good to think of one in light of the other) Whether it is best to start with modules that use the segment memory (I assume this is typically for RAM limitations not CPU) or splitting serial G_{get|put}_raster_row() operations into n chunks of rows, I am not sure. And how (or is it possible) to abstract that to the library level to avoid a massive rewrite. (massive raster module rewrite is not off the table for GRASS 7 but seems like a less bang-for-buck approach) It would be interesting to rewrite r.example to split the operation into n threads. (GRASS_NPROC=n or GRASS_THREADS=n enviro var?) > For output maps, the writer would write the data to a temporary file, > and would only need to lock the map at the point that it is closed, > for the time taken to rename the cell/fcell file and to write the > support files. (meta-data support files are in general written after the map data array is already closed) Hamish ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev