[gdal-dev] Motion: approve RFC 101 "Raster dataset read-only thread-safety"

[Even Rouault]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240912/e260ba40/attachment.htm>