Race condition in gdalrasterband.cpp causing IReadBlock() and IWriteBlock() methods of drivers to be called from different threads

[Even Rouault]

This is largely related to the issue exposed in #3225, but this symptom is potentially more likely to happen.

The attached program run against an unmodified GDAL shows that FlushBlock() can call IWriteBlock() while GetLockedBlockRef() calls IReadBlock(). This would require GDAL drivers to be thread-safe. All this shows that we probably need more severe locking than what we do currently.

[Even Rouault]

The output of a run is :

$ ./hit_bug_3226
create a dirty block 0
end of dirty block 0 creation
begin thread -> flush the dirty block
begin of IWriteBlock(x=0, y=0) (thread=5108)
read block 1 from main thread
begin of IReadBlock(x=0, y=1) (thread=2616)
ERROR 7: Assertion `!bLock' failed
in file `hit_bug_3226.cpp', line 49

[Even Rouault]

hit_bug_3226_2.cpp is a variation of hit_bug_3226.cpp that doesn't require explicit call to GDALFlushBlock().

[Even Rouault]

Variation of the first program that doesn't require explicit call to GDALFlushCacheBlock()

[Even Rouault]

Actually this is a duplicate of #5983

[Even Rouault]

Milestone renamed