[gdal-dev] Multithreading issue on pixel-based intensive access (GDAL 2.1.0)
francisco.javier.calzado at ericsson.com
Wed Jul 27 05:01:59 PDT 2016
Hi guys, I'm experiencing an issue when running some simple tests
involving multithreading. I would like to know if it is something I am
not doing correctly with GDAL or it is a GDAL business dealing with
threads and block cache.
To make long story short, just imagine two threads accessing different
raster dataset (different files) and looping through all of its pixels
to read its value. So, for each pixel I do something like:
GDALRasterBlock* poBlock = m_poRB->GetLockedBlockRef(blockXIndex,
void* pData = poBlock->GetDataRef();
// Access value.
T value = ((T*)pData)[blockOffset];
I know this is a very aggressive way to access the pixel value as I'm
locking/unlocking in a pixel basis instead of a block basis (I mean
here, locking the block just once and reading all of its pixels, and
then unlocking), and also it may decrease performance. But I'm limited
by some requirements in my application legacy code and there is not much
I can do.
The problem with this implementation is that I get an assertion failed
in gdalrasterblock.cpp line 800, which is in summary, the moment where a
'touched' block is moved on top of the LRU block cache list. It seems
that a race condition may be happening between threads.
So my question is: this way of accessing pixels with so many block
locks/unlocks is fully supported by GDAL as thread-safe? Or is it a bug
in GDAL's block cache management?
Thank you so much for your time and help.
More information about the gdal-dev