[Gdal-dev] OGR, CPLSPrintf and thread safety

Tamas Szekeres szekerest at gmail.com
Thu Nov 8 11:19:12 EST 2007


Daniel,

__declspec(thread) is a Microsoft VC specific so it cannot used as an
universal solution. Moreover it works in DLLs only when those DLLs are
bound to the executable, and will not work for those loaded with
LoadLibrary().

In this particular case it would be reasonable to allocate the buffer
in the stack at the beginning of every function using these variables.

Alternatively there's a fairly platform neutral TLS implementation in
gdal that can also be used.

You might want to submit a ticket with this issue.


Best regards,

Tamas



2007/11/8, Daniel <daniel112b at gmail.com>:
> Hello,
>
> I have run into some threading issues accessing a .tab file from multiple
> threads. Each thread has it's own OGRDataSource so the OGRDataSource objects
> won't get accessed from more than one thread at a time. The GDAL faq says:
>
> "In particular for the situation where many threads are reading from GDAL
> datasets at once should work as long as no two threads access the same
> GDALDataset object at the same time"
>
> Is the same thing true for OGR? ( or at least in the sense that it is
> supposed to be). I think i have tracked down the problem in this particular
> case to CPLSPrintf. The static buffers it is using is declared as:
>
>
>
> static CPL_THREADLOCAL char
> gszCPLSPrintfBuffer[CPLSPrintf_BUF_Count][CPLSPrintf_BUF_SIZE];
>
> static CPL_THREADLOCAL int gnCPLSPrintfBuffer = 0;
>
> but CPL_THREADLOCAL is by default defined to nothing, a long time ago (23/5
> 2005) CPL_THREADLOCAL was defined to declspec(thread) in cpl_config.h.vc
> which should have made them thread local. But that was changed a month later
> or so. Was there a particular reason for that? I havn't used thread local
> storage much myself so i don't know how good it works or if it differs alot
> between different compilers. I havn't tried to define CPL_THREADLOCAL myself
> yet to see if it works but i'll hope i'll get time to do that.
>
> My problems occur while i'm trying to extract the styling info and i end up
> with an empty style string when running multiple threads.
>
>
>
> Regards,
>
> Daniel Bäck
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>




More information about the gdal-dev mailing list