[Gdal-dev] Motion to Adopt RFC 16: OGR Thread Safety

[Simon Perkins]

For some reason I missed or ignored the original posting of this RFC. I 
have a late comment / question...

What about methods that modify a layer? i.e. we have two threads, A and 
B accessing the same layer via layer clones, so they each have their own 
read state. What if thread A checks to see if a feature with FID 42 
exists, then B invokes a method to delete feature 42, before thread B 
attempts to get the geometry for that feature? Even if those calls are 
serialized, it is likely that thread A will get very confused.

I think in general, guaranteeing thread safety when you have threads 
modifying data is in general extremely hard at the library level, and 
really requires some kind of thread coordination at the application 
program level. Maybe the datasource mutex could be exposed with a couple 
of handy Lock/Unlock methods to make this kind of high level 
coordination easier? In any case, shouldn't the RFC mention something 
about reading vs writing?

Cheers,

Simon


Frank Warmerdam wrote:
> Motion: To adopt RFC 16: OGR Thread Safety
>
> http://trac.osgeo.org/gdal/wiki/rfc16_ogr_reentrancy
>
> ---
>
> There wasn't to much discussion on this as far as I recall, which I take
> to mean no one has a problem with it.  So moving to formal vote so I can
> implement this coming week.
>
> +1 from me.
>
> Best regards,