[GRASS-dev] Re: locking on a raster

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >> BTW, is there a way to ``lock'' on a raster (or its data at least),
 >> so that it could be opened (or rewound) multiple times and, e. g.,
 >> `G_get_raster_row' would return the same data, even if the raster
 >> was, e. g., renamed meanwhile?

 > That's already the case.

 > When a raster is opened for write, the data is written to a temporary
 > file in the <mapset>/.tmp/<hostname> directory. When the raster is
 > closed, the temporary file is moved into place with rename().

 > 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.

 > Note that this typically won't work on Windows. If a module tries to
 > replace a raster while it's open, the renaming step will fail.

 > A more signficant issue for concurrent access is the potential for
 > race conditions between opening the various files which make up a
 > raster (cellhd, cell/fcell, categories, colour table, history, etc).

 > To minimise the risk of race conditions, modules should ideally read
 > all support files at the start, rather than waiting until they have
 > finished reading the raster data.

	Quite so.  Although I have a few ideas on how to avoid it.

 > 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.