[gdal-dev] Multithreading with OGR

[Ari Jolma]

Martin,

Just a comment. In Geoinformatica, which uses GTK+, I've begun to 
address the same kind of problem using the functions provided by GTK+. 
So far I've not used this on rendering and I've not thought about all 
the consequencies. In some expectedly lengthly GDAL operations it 
provides a mechanism in the function API to report progress. I've begun 
experimenting with this and added

Gtk2->main_iteration while Gtk2->events_pending;

into the progress function in addition to updating the progressbar 
(Geoinformatica uses GTK+ Perl, that is a line of Perl code). I assume 
Qt provides something similar. This makes sure the application stays 
responsive during the operation and allows the user to do other things. 
I assume I could do the same for rendering, i.e., let GTK+ process 
pending events occasionally. As I said, I'm not sure about all possible 
consequencies. Reentrancy would surely be required, but not necessarily 
thread-safeness, which is more demanding.

Best regards,

Ari

Martin Dobias kirjoitti:
> Hi all,
>
> in my GSoC project [1] I'm trying to employ multithreading to make
> rendering in QGIS both faster (on multi-core machines) and more
> pleasant to use (not blocking GUI thread while rendering). I've been
> successful with making that work in "ideal" conditions (no concurrent
> reads/writes) and now the hard part comes: to make the implementation
> thread-safe. OGR is an important data provider, so I'd like to ask you
> for some hints how to do the things correctly.
>
> I've seen there have been some efforts to make OGR thread-safe - in
> RFC 16 [2]. In the RFC it is not clear in what parts have been
> implemented, but from the code I guess it ended up with only making
> driver registrar and data source classes thread-safe. In QGIS
> everything basically runs in the main thread, worker threads are
> spawned only when rendering the map. A worker thread for rendering
> only reads the features from data source and I can make sure that main
> thread doesn't do any write operations while the threaded rendering is
> in place. So my only problem is to avoid concurrent reads from both
> main thread and worker thread. How can be this best accomplished
> without serializing the access?
>
> Currently I think of creating a temporary clone of the OGRLayer for
> purposes of reading features in worker thread.
> Is that feasible - are the drivers reentrant - at least within their
> reading routines?
> Is it generally costly to create another instance of the same layer?
> When a write operation happens in main thread, will be the change
> visible in the cloned layer for worker thread or is it necessary (for
> some drivers) to recreate the cloned layer?
>
> [1] http://blog.qgis.org/node/144
> [2] http://trac.osgeo.org/gdal/wiki/rfc16_ogr_reentrancy
>
> Thanks in advance for any hints.
>
> Regards
> Martin
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>