[GRASS-dev] Re: locking on a raster

[Glynn Clements]

Ivan Shmakov wrote:

>  > Any process which has the raster open for reading will be unaffected
>  > by all of this, so long as it keeps the raster open (if it closes and
>  > re-opens it, that's a different issue).
> 
> 	It seems that you've missed my point.  I wish to process the
> 	whole raster with G_get_raster_row () once, and then another
> 	time from the start.  The only way to do it that I know is to
> 	close and re-open it, which is ``a different issue'', indeed.

No, there's no need to re-open it (or otherwise "rewind" it). 

G_get_raster_row() takes the row number as an argument; nothing
requires that you read the rows sequentially, or that you read each
row only once.

>  > To have concurrent access working properly, we would need to add
>  > explicit locking to all modules. Actually, we might be able to do it
>  > in g.parser, at least for modules whose options contain complete
>  > information (i.e. not modules which derive the names of output maps
>  > from the names of the input maps).
> 
> 	So that, e. g., renaming would be impossible without all the
> 	processing of the raster finished?  It doesn't seem to be a
> 	particulary bright solution.  At least, it may bring deadlocks
> 	to GRASS, and it seems to complicate parallel execution in
> 	general as well.

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.

The module wouldn't have to keep the map locked while processing the
data; it could unlock it once it no longer needs to open any more
files. Provided that modules were written to read all of the support
files at the beginning, the lock could be released before it starts
reading the actual map data.

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.

Deadlock is only possible if a module attempts to obtain a lock while
it already holds another lock. I can't conceive of any situation where
that would be necessary.

-- 
Glynn Clements <glynn at gclements.plus.com>