[gdal-dev] Multithreading issue on pixel-based intensive access (GDAL 2.1.0)

[Javier Calzado]

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:

// Lock.
GDALRasterBlock* poBlock = m_poRB->GetLockedBlockRef(blockXIndex, 
blockYIndex);
void* pData = poBlock->GetDataRef();

// Access value.
T value = ((T*)pData)[blockOffset];

// Unlock.
poBlock->DropLock();


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.