[gdal-dev] Thread safe?

[Even Rouault]

Le mardi 07 février 2012 00:23:20, Billy Newman a écrit :
> Is the DataSource.delete() method (from java binding) thread safe?

Yes, it should

> 
> Thanks
> 
> On Wed, Jan 11, 2012 at 3:09 PM, Even Rouault
> 
> <even.rouault at mines-paris.org>wrote:
> > **
> > 
> > Le mercredi 11 janvier 2012 22:32:45, Billy Newman a écrit :
> > > I am using a third party lib (imageio-ext) to leverage gdal in java
> > > code.
> > > 
> > > I have noticed that the imageio-ext folks have wrapped the
> > > gdal.Open(..)
> > > 
> > > call in a synchronized method. I am assuming this is to prevent
> > > 
> > > imageio-ext users from hanging themselves with regard to thread safety.
> > > 
> > > 
> > > 
> > > I have looked at the gdal FAQ with regards to thread safety and the
> > > last
> > > 
> > > release that it mentions additions is 1.3.0.
> > > 
> > > 
> > > 
> > > What is the current status of the 1.9.* build with regards to thread
> > > 
> > > safety.
> > 
> > The following is still true : "In particular for the situation where many
> > threads are reading from GDAL datasets at once should work as long as no
> > two threads access the same 
> > GDALDataset<http://www.gdal.org/classGDALDataset.html>object at the same
> > time. However, in this scenario, no threads can be writing to GDAL while
> > others are reading or chaos may ensue. "
> > 
> > I believe most common GDAL drivers should be safe. That includes drivers
> > that don't depend on third party librairies (the driver is self contained
> > in GDAL source tree), and drivers that depend on "classic" third-party
> > libraries (such as PNG, JPEG, GIF). For other third party libraries
> > (netCDF, HDF4, HDF5, ...), this depends on whether they are thread-safe
> > themselves. There's at least one driver that is known to be non
> > thread-safe
> > 
> > : GRIB.
> > : 
> > > Thanks,
> > > 
> > > Billy