[gdal-dev] GDAL ReadRaster thread-safe?

[Tamas Szekeres]

Eric,

The most performant option I'm aware of is reading the dataset directly into
a bitmap buffer something like:

try
{
        int stride = bitmapData.Stride;
        IntPtr buf = bitmapData.Scan0;

        ds.ReadRaster(xOff, yOff, width, height, buf, imageWidth,
imageHeight, dataType,
        channelCount, bandMap, pixelSpace, stride, 1);
}
finally
{
        bitmap.UnlockBits(bitmapData);
}

In this case there's no internal buffers in the marshalling code used by the
C# wrappers. The only challenge here is to ensure that the bitmap buffer
should have the same structure as the gdal dataset represents. You could
refer to the complete example in the C# wrapper for the details:
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALDatasetRasterIO.cs
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALReadDirect.cs

I don't think if triggering multiple reads for different sections in
multiple threads is currently supported by gdal, it might also be driver
dependent how the reads are actually implemented by the drivers, however you
might anyway try defining separate Dataset objects for the different when
performing the read operations, but there might be locks in different places
causing the operations to be serialized in effect.

Best regards,

Tamas



2009/1/8 Eric Domazlicky <edomazlicky at gmail.com>

> I am developing a tiling application and I was hoping to up the speed a bit
> by doing some multithreading. What I want to do is start each of 3
> ReadRaster calls in seperate threads (using BeginInvoke delegates), then
> wait for them to complete and build my RGB image (using EndInvoke). I am
> using the C# wrapper to the GDAL library. This multithreaded approach is
> showing clear signs of race conditions, with some of the channels not
> appearing, random crashes etc. If I ensure each thread completes before I go
> on to read the next Raster Band it works fine.
>
> Is there anyway to make ReadRaster thread-safe? Maybe by disabling caching
> which I suspect is the problem.
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090108/118b6122/attachment.html