Selon "N. Farah" <nfa...@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. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
