Mika,
Le 12/09/2024 à 09:22, Heiskanen Mika (FMI) via gdal-dev a écrit :
*
Ah, and one thing I realized is that OGRSpatialReference isn't
thread-safe, so I've also added an optional SetThreadSafe() on it,
to also use a per-instance mutex in multi-threaded scenarios (cf
commit
https://github.com/OSGeo/gdal/pull/10746/commits/c7e1862273dd018e58a01f25b21fdff6dbfdd1cd
<https://github.com/OSGeo/gdal/pull/10746/commits/c7e1862273dd018e58a01f25b21fdff6dbfdd1cd>).
Perhaps I am missing something, but why not use read locks for const
methods and write locks for non-const methods so that readers would
not block each other so much?
Read locks might not be sufficient for getters to run safely, because
there's often mutable state behind. For example if someone uses WKT node
manipulation functions like SetNode(), this modifies the
OGRSpatialRefernce internal WKT tree, and a flag is set to track that.
The next time a getter is called, and that getter needs to call a PROJ
method to get the information, it first reconstruct a WKT string from
the WKT tree, makes PROJ re-ingest it to update its PJ* internal model,
and then call the PROJ getter. Some PROJ getters also use internal
mutable state.
At this stage, using a full mutex is definitely a much safer option. I
don't also expect calls to OGRSpatialReference methods to be bottlenecks
in typical multi-threaded usages.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
