[gdal-dev] Thread safety of GDAL projection machinery?

Even Rouault even.rouault at mines-paris.org
Wed May 27 18:05:05 EDT 2009


Le Wednesday 27 May 2009 23:17:39 Karney, Charles, vous avez écrit :
> Thanks for the reply.
>
> > At first sight, you're likely doing things the right way and probably
> > discovered a bug related to multi-threading in GDAL. The use of
> > GDALCreateGenImgProjTransformer() should be thread-safe (provided that
> > you don't use the same dataset in the different threads)
>
> Yes, each thread is dealing with a separate set of files.
>
> > By reviewing the code of 2 files that are used in the retrieving and
> > parsing of the csv files, there are a few variables that are supposed to
> > be thread-local (CPL_THREADLOCAL), but this is currently a no-op.
> >
> > But as it's just a guess and maybe not the real cause for your problems,
> > ideally, you could file a bug in the GDAL Trac with a small program that
> > reproduces your issue, so that it can be investigated further.
>
> It's probably going to be tough for me to carve out a test case.
> However, can I turn the question around?  If CPL_THREADLOCAL is a noop,
> how can the code in cpl_csv.cpp possibly be thread safe?

You're right. That part of the code isn't currently thread-safe, and should 
likely be fixed. So this is a bug, as GDAL core is intended to be thread-safe 
(with somes restrictions, like operating on different dataset handles, 
etc...). But it's hard to tell without a way of reproducing if it is 
significant in the issue you're running into. It might be somewhere else in 
GDAL.

>
> In the meantime, I've put a lock around by GDAL calls which avoids the
> errors (but probably with penalty in performance).
>
> --
> Charles Karney <ckarney at sarnoff.com>
> Sarnoff Corporation, Princeton, NJ 08543-5300
>
> Tel: +1 609 734 2312
> Fax: +1 609 734 2662




More information about the gdal-dev mailing list