<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<ul data-editing-info="{"orderedStyleType":1,"unorderedStyleType":4}" style="margin-top: 0px; margin-bottom: 0px;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "➢ ";">
<div class="elementToProof">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
<a href="https://github.com/OSGeo/gdal/pull/10746/commits/c7e1862273dd018e58a01f25b21fdff6dbfdd1cd" id="LPlnk912365" class="OWAAutoLink">
https://github.com/OSGeo/gdal/pull/10746/commits/c7e1862273dd018e58a01f25b21fdff6dbfdd1cd</a>).</div>
</li></ul>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-Mika Heiskanen-</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> gdal-dev <gdal-dev-bounces@lists.osgeo.org> on behalf of Rahkonen Jukka via gdal-dev <gdal-dev@lists.osgeo.org><br>
<b>Sent:</b> Thursday, September 12, 2024 09:27<br>
<b>To:</b> Even Rouault <even.rouault@spatialys.com>; gdal-dev@lists.osgeo.org <gdal-dev@lists.osgeo.org><br>
<b>Subject:</b> Re: [gdal-dev] Motion: approve RFC 101 "Raster dataset read-only thread-safety"</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">+1<br>
<br>
-Jukka Rahkonen-<br>
<br>
-----Alkuperäinen viesti-----<br>
Lähettäjä: gdal-dev <gdal-dev-bounces@lists.osgeo.org> Puolesta Even Rouault via gdal-dev<br>
Lähetetty: keskiviikko 11. syyskuuta 2024 22.27<br>
Vastaanottaja: gdal-dev@lists.osgeo.org<br>
Aihe: [gdal-dev] Motion: approve RFC 101 "Raster dataset read-only thread-safety"<br>
<br>
Hi,<br>
<br>
I move to approve RFC 101 "Raster dataset read-only thread-safety":<br>
<a href="https://github.com/OSGeo/gdal/pull/10676">https://github.com/OSGeo/gdal/pull/10676</a><br>
<br>
Starting with my +1,<br>
<br>
The candidate implementation is available in <a href="https://github.com/OSGeo/gdal/pull/10746">
https://github.com/OSGeo/gdal/pull/10746</a>. While fine tuning it, I realized there were subtleties, related to the fact we use thread-local datasets under the hood, for methods returning a non-"primitive" type, such as a "const char*" whose lifetime is tied
to a dataset/band. If we'd get it from a thread-local dataset, and that one would be later evicted from the cache (not very common, but could happen if one would open tons of thread-safe datasets at the same time), then you could have use-after-free issues.
For such methods (GetMetadata(), GetMetadataItem(), GetProjectionRef(), etc. as well as GetColorTable() which returns a GDALColorTable pointer, or GetSpatialRef() which returns a OGRSpatialReference*), I've preferred to protect their access with a mutex around
the "prototype" dataset passed when constructing GDALMultiThreadedDataset, whose lifetime is at least as long as GDALMultiThreadedDataset (cf commit<br>
<a href="https://github.com/OSGeo/gdal/pull/10746/commits/849e9cea711efd30c47fd90a7a6b71a75611c1a5#diff-687008dd6e3d5ac8ad05568272746ed75b84de50bde508f78f2d79a6842825c7L428)">https://github.com/OSGeo/gdal/pull/10746/commits/849e9cea711efd30c47fd90a7a6b71a75611c1a5#diff-687008dd6e3d5ac8ad05568272746ed75b84de50bde508f78f2d79a6842825c7L428)</a><br>
. Normally such methods aren't called in user code repeatedly, so there should be any noticeable lock contention in practice. The main objective of the RFC which is to be able to issue RasterIO() requests in parallel isn't affected by that. Ah, and one thing
I realized is that OGRSpatialReference isn't thread-safe, so I've also added an optional<br>
SetThreadSafe() on it, to also use a per-instance mutex in multi-threaded scenarios (cf commit
<a href="https://github.com/OSGeo/gdal/pull/10746/commits/c7e1862273dd018e58a01f25b21fdff6dbfdd1cd)">
https://github.com/OSGeo/gdal/pull/10746/commits/c7e1862273dd018e58a01f25b21fdff6dbfdd1cd)</a>.<br>
Multi-threading is hard...<br>
<br>
Even<br>
<br>
--<br>
<a href="http://www.spatialys.com/">http://www.spatialys.com/</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
gdal-dev@lists.osgeo.org<br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
gdal-dev@lists.osgeo.org<br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div>
</span></font></div>
</body>
</html>