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

[Tamas Szekeres]

2007/10/8, Simon Perkins <sy at perkins.net>:
>
> The point I was trying to make is that if all the threads are just
> reading data from the Layers, then it's reasonable to implement
> synchronization at the library level as you suggest. However, as soon as
> you have a situation where one or more threads might modify those layers
> (or even delete them), then locking per library call is no longer
> sufficient. I just think the RFC should make this distinction clear.
>
> As you point out, it's really not even sufficient to lock at the
> application level either since multiple applications might be accessing
> the same shared data source. For RDBMSes is it possible to have the
> DataSource mutex actually lock something at the database level? If this
> mutex is exposed by the DataSource API for application level locking,
> then this would provide considerable protection against overlapping updates.
>

Simon,

I think in this RFC we are thinking mainly about the problems inside
the OGR core not at the database. For example like a shared variable
(inside ogr) should be protected against the simultaneous access by
multiple threads.

I don't think we should do much with the adatabase level issues from
the application just rely on the transaction isolation mechanism
related to the database server and use it's built in locking mecanism
implicitly.
For the file based datasources IMO this issue should also be handled
at file level by controlling the access and the share mode on the file
properly. The simultaneous read only accesses should not be locked at
application or library level at all.

In addition when editing spatial data some more sophisticated editing
strategies like long transactions and versioning are often considered
to be implemented, however that falls pretty far from the original
concept and objectives.

Best regards,

Tamas