[Gdal-dev] Multi-threading Support

Marek Brudka mbrudka at aster.pl
Mon May 30 13:18:14 EDT 2005


Frank Warmerdam wrote:

> Folks,
>
> I have committed a variety of changes to GDAL in support of thread
> safety.

Nice! Thanks!

In our company we use gdal modified to be reentrant
(unix,windows) when any PROJ.4 related methods are called
(OGRSpatialReference and OGRCoordinateTransformation).
In general we introduced global [ :-( ]  PROJ.4 mutex locked
every time PROJ.4 functions are called. This is not a very
efficient, but probably the only option.. PROJ.4 is
a computational library and should rather not be polluted
by a portable thread specific storage code related with
errno. On the other side any interface changes in PROJ.4,
specifically changes in error reporting,  are almost impossible
now (I read this on proj.4 related discussion list). Hence one has
to synchronize PROJ.4 calls externally.

I have also created CPL-based mutex guards to make the code
more safe. If anyone in gdal-users is interested in these
changes I can make them public.

BTW. Gdal does not have to be a thread safe library. The most
important feature of  GDAL in multithread applications is
the reentrancy. Moreoever, the statefull interfaces like OGRLayer
or OGRRasterband are not very well suited to be internally thread
safe, though they should be serialized when accessing low
level datasources. At least, it would be nice to have a mutexes
(avalaible via guard only!) for GDAL/OGR datasources. I can discuss
these ideas (and the other) related with reentrency or thread safety
in more details if anyone on gdal-dev is interested.

Marek Brudka




More information about the Gdal-dev mailing list