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

[Frank Warmerdam]

Simon Perkins wrote:
> 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 A
 > attempts to get the geometry for that feature? Even if those calls are
 > serialized, it is likely that thread A will get very confused.
Simon,

First, note that two different threads may not safely use a single
OGRLayer since OLCThreadSafe is not an option.  But distinct OGRLayer
objects referring to the same layer-on-disk could be created (one using
the GetLayerClone().

But, more to the point, there is no guarantee that nothing changes
between two calls into the OGR API.  So for instance, if a method on
the OGRLayer was used to find the FID of a feature, and then the
DeleteFeature() method was called, there is no guarantee that the
feature would still be there.  In fact, with RDBMS backed layers
it is already the case that a feature could disappear between a
query and a further action due to another client being connected to,
and updating the same database (transaction semantics aside).

For your specific example, features read from a database are normally
read as a complete record, and so GetNextFeature() returns a complete
feature, including the geometry whether you have accessed the geometry
or not.  Even within the method the database API ensures we either get
a complete record or we get nothing.

For file formats (imagine operating on a shapefile) it will be up to
the driver to ensure that only one clone of a layer at a time is
actually updating a shapefile via a per-underlying-layer mutex.  At
least in this scenario that is possible.  In the existing situation
applications would normally open the file twice if multiple threads
need access, and each datasource would have no idea what the other
might be doing.

> 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? 

This is an interesting idea.

 > In any case, shouldn't the RFC mention something
> about reading vs writing?

Perhaps.  I will add something.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org