[gdal-dev] RFC 47 and Threading

[Robert Coup]

On Thu, Aug 21, 2014 at 8:26 AM, Even Rouault <even.rouault at spatialys.com>
 wrote:

>
> I guess the silence in thread is due to people being impressed by the
> austerity of the topic...
>

Something like that :)


>
> On the other side, I would be very pleased with having "just" the
> preliminary
> step of Blake's work, i.e. the possibility to choose a per-band block cache
> strategy instead of the global block cache. That should already address
> most
> scaling issues.
>

I agree - from reading it seems like the major improvement is shifting away
from a global, locking cache to a per-dataset cache. (ah. has been edited
since you read it?)

Which personally I think is worthwhile for any code/application which reads
a variety of gdal datasources.

Quick question - presumably for VRT datasets any source images currently
share the global cache and are treated from this proposals' POV as their
own "datasets"? As well as the VRT being a separate dataset? If so, seems
like this could be quite a major win for users with VRTs for tiled images?

While it's a lot of code change, it's mostly simple/repeated changes.

> Solution 2 (RW Mutex in GDALRasterBlock)
> Cons:
> It means that writing a driver is not as trivial as before and care must
be taken in how locking is done within the driver in order to prevent
deadlocks and maintain thread safety.

I'm wary about making drivers more complex, there's a lot of them. And many
are unlikely to be tested in multi-threaded anger during initial
development (and MT issues can be hard to unit test). Can you explain a bit
further what would be the impact for typical driver styles? Can we make the
typical case (no/locked multithreaded access) really easy? What sort of
driver code would be needed for drivers that can do MT reads? MT reads and
writes?

Rob :)

OT: can we change gdal-dev to be reply-all by default? :)
-- 

*Koordinates*PO Box 1604, Shortland St, Auckland 1140, New Zealand
Phone +64-9-966 0433 koordinates.com <https://koordinates.com/about>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140822/9e4892f3/attachment.html>