[GRASS-dev] Re: locking on a raster

[Hamish]

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