[gdal-dev] RFC 47 and Threading

[Blake Thompson]

Even,


> This might be a problem in practice since the amount of cache might grow
> quickly. By default a VRT will open simultaneously up to
> GDAL_MAX_DATASET_POOL_SIZE (whose default is 100, but can be changed at
> runtime with the config option) source datasets.
> If you do a gdal_translate of the VRT (and that it has more than 100
> sources)
> then you will need 100 * GDAL_CACHEMAX bytes for the cache.
> Of course once you are aware of that you can play with both configuration
> options to find the best settings.
>

This is one of the reasons I would perfer to use my solution #1 or #2
rather then just adding the per dataset cache as we originally spoke about
during the original development. I think we should try to preserve the
global cache in some situations but still have good performance.


> Just throwing an idea : how about a IReadBlock_thread_safe and IReadBlock
> virtual methods ? The first one would have a default implementation in
> GDALRasterBand that would basically call the second one with a global
> mutex.
> That way drivers that wan't a more fine grained locking could implement
> their
> own IReadBlock_thread_safe, whereas the ones that don't care would just
> implement IReadBlock. The few current call sites of IReadBlock would just
> need
> to be updated to call IReadBlock_thread_safe instead.


I originally thought about such a solution, but I decided instead on the
using of the default IReadBlock paramter  'void ** phMutex = NULL'. If the
pointer pointer of the mutex is NULL, then no mutex is created and locking
does not occur. Honestly as well when I was originally doing this, I was
not sure which drivers would have even needed such a IReadBlock_thread_safe
implementation. Therefore, I decide the best way in Solution #2 was to
simply just walk through each of the implementations of and find where
exactly I need to protect the data pointer.

I have a mixed feelings on both methods. I feel like the
IReadBlock_thread_safe implementation might make people writing new drivers
feel like they do not have to work about thread safety when they are
comparing the code to other drivers? I somewhat like that idea that drivers
should consider their thread safety. Lots of drivers seem to call RasterIO
as well, which would that need a RasterIO_thread_safe method? That might
make that code more complex? Not quite sure, will have to think it all out.

Thanks,

Blake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140822/a9d93b24/attachment.html>