Multithreaded writing skips random blocks

[javiercalzado]

In a multithreading scenario involving simultaneous writing, eventhough different output datasets, random blocks appear to be empty in the resulting rasters. This is apparently happening when the block cache gets full during writing process.

It seems that 2 or more threads writing simultaneously, mess up the block cache to each other when trying to flush dirty blocks.

I have reproduced the issue with a custom-made driver based on GDALPam inheritance, but it also happens with ENVI driver, and presumably with other drivers.

Find in the following link a test case and a sample raster to reproduce the issue: ​https://drive.google.com/open?id=0B-OCl1FjBi0YUkN4WWZmRjRfM1k

[Even Rouault]

In 35548:

Make multi-threaded reading/writing when using GetLockedBlock()/MarkDirty()/DropLock() lower level interfaces (fixes #6665)

[Even Rouault]

In 35549:

Make multi-threaded reading/writing when using GetLockedBlock()/MarkDirty()/DropLock() lower level interfaces (fixes #6665)

[Even Rouault]

In 35550:

Make multi-threaded reading/writing when using GetLockedBlock()/MarkDirty()/DropLock() lower level interfaces (fixes #6665)

[Even Rouault]

In 35551:

Test multi-threaded reading/writing when using GetLockedBlock()/MarkDirty()/DropLock() lower level interfaces (refs #6665)

[Even Rouault]

In 35552:

Fix previous commit that causes kea_4 to fail (refs #6665)

[Even Rouault]

In 35553:

Fix previous commit that causes kea_4 to fail (refs #6665)

[Even Rouault]

In 35554:

Fix previous commit that causes kea_4 to fail (refs #6665)