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. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
