[gdal-dev] RFC 47 and Threading

[Blake Thompson]

Even,

The naming is perhaps not well choosen, but the documentation of the
> contract
> of this API should make it clear on what an implementation should do and
> what
> it should not do.
>

Perhaps it should be reversed? IReadBlock and IReadBlock_not_thread_safe?
(would obviously require lots of changes that way).


>
> You didn't answer my question on how many drivers can have a non-blocking
> IReadBlock() implementation in practice. My intutition (reinforced by
> skimming
> through https://github.com/OSGeo/gdal/pull/39/files) is just/mostly
> MEMDataset.
> So people looking at drivers would just see the classical IReadBlock()
> implementation and wouldn't have to think a lot about thread safety (that
> would be brought by the generic GDALRasterBand::IReadBlock_thread_safe()).
>
>
I honestly have no idea how many drivers can have a non-blocking IReadBlock
with this setup. I really do not understand all the drivers well enough to
give an estimate (so I would assume yours is probably most correct). I have
been mostly concerned with first just making the cache threadsafe, then was
thinking we could start targeting drivers individually.


> > I somewhat like that idea that drivers
> > should consider their thread safety.
>
> I somewhat like the idea they shouldn't have to bother about that ;-)
> especially if we can have improvements in core only that improve
> thread-safe
> usage and performance. The people wanting to gain one more extra % of
> performance might take the risk of doing a custom thread-safe
> implementation
> in the driver.
>

My thought here was more along the lines of "the driver is going to write
to the block cache so it should have the responsibility to lock when it
needs to be locked". To me this was better in some manners then "in most
case implement this method, which if I use improperly might cause deadlocks
or corruptions, otherwise implement this method".

Thanks,

Blake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140822/cc7732aa/attachment.html>