[gdal-dev] Sharing GDAL Dataset objects between threads (JNI)

[Markus Schneider]

Thanks again.

I found the comments in gdaldataset.cpp, and understand now that there's
no gain in using GDALOpenShared over GDALOpen in a multi-threaded
environment, as GDALOpenShared will create multiple GDALDataset objects
anyway in such a scenario.

Best regards,
Markus

Am 17.10.2013 13:27, schrieb Even Rouault:
> Selon Markus Schneider <schneider at occamlabs.de>:
> 
>> Hi Even,
>>
>> thanks for you help so far.
>>
>> I now observed that handing around a (ECW) Dataset between threads works
>> fine, as long as I open it using:
>>
>> - gdal.Open(String name)
>>
>> However, when I open it using:
>>
>> - gdal.OpenShared(String name)
>>
>> I see strange effects and VM crashes.
>>
>> Does this make sense?
> 
> Yes, GDALOpenShared() ( see the doc of the C function ) must be used with great
> caution in a multi-threaded scenario. As long as the thread that has called
> GDALOpenShared() continues to use it until it closes it, it is OK. But if that
> thread handles the dataset to another one, then chaos might happen.
> 
> For example in the following scenario :
> 
>          Thread 1                                  Thread 2
> ds1 = OpenShared("foo")
>                            -- handle it to -->
> ds2 = OpenShared("foo") ( == ds1)
>   do_things(ds2)                                do_things(ds1)
> ds2.Close()
>                                                 ds1.Close()
> 
> At a point, you can call methods on the same dataset object from different
> threads...
> 
> By the way, the issue you've observed with ECW would also be true with other
> drivers. It is just by chance that you didn't notice it.
> 
>> What do you believe is preferrable with regard to
>> performance and memory consumption:
>>
>> 1. Using a ThreadPool and obtain a Dataset using gdal.OpenShared for
>> each thread
>> 2. Using gdal.Open and simply pool the obtained Dataset objects (and
>> hand them around between threads)
> 
> I'm not sure to completely understand what you've in mind, but I would rather
> recommand option 2.
> 
> Best regards,
> 
> Even
> 


-- 
Markus Schneider
CEO

Occam Labs UG (haftungsbeschränkt)
Godesberger Allee 139
53175 Bonn, Germany

+49 228 93798874

http://www.occamlabs.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20131018/89f96766/attachment.pgp>