[GRASS-dev] locking on a raster

[Glynn Clements]

Ivan Shmakov wrote:

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

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.

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

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