[gdal-dev] does gdal support multiple simultaneous writers to raster
Even Rouault
even.rouault at mines-paris.org
Mon Jan 14 06:26:12 PST 2013
Selon "N. Farah" <nfarah at hotmail.com>:
> Thanks Even for your response. That clarifies more the current capabilities
> of GDAL on parallel processing.I think that as parallel processing gain more
> momentum, GDAL and multiple GDAL based applications would benefit for
> adopting it.In Windows world, parallel processing was added in Visual Studio
> 2010 (PPL for C++ and TPL for .net) and re-enforced a bit morein Visual
> Studio 2012 by C++ AMP: GPU based processing.
> I do not know enough the low level GDAL caching but it seems to me that
> option B) could work (dataset based caching).I agree that exposing capability
> level per driver about concurrent safety is a good one. As some drivers
> dependson 3rd party libraries that might not be concurrent safe. Tagging
> those drivers as not concurrent safe would be a first step,before trying to
> address their underlying concurrency safe issues
Yes, 3rd party libraries might be a problem. A first step would be do add a
per-driver mutex to avoid running into their concurrency problems, if confirmed.
Fixing concurrency problems is them is another story.
> As far as reading datasets, I tested HDF4 or 5 dataset to read its
> subdatasets in a parallel way and encountered an error.So some drivers may
> have the parallel reading issue as well. May be reading sub-datasets is
> simply not concurrent safe evenif each sub-dataset is opened as its own
> dataset ?
This is not linked to the sub-dataset mechanism in itself. You can certainly
read NITF or GTiff subdatasets in a thread-safe way.
Reviewing quickly the GDAL side of the HDF4 and HDF5 drivers, I don't see any
global variable used, so the problems might come from the libhdf4 and libhdf5
themselves.
More information about the gdal-dev
mailing list