[gdal-dev] Thread safe?

[Billy Newman]

Is the DataSource.delete() method (from java binding) thread safe?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120206/1e04fc30/attachment.html