Thread safety issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Thread safety issues

Tamas Szekeres
Dear developers,

We have encountered thread safety issues when invoking the geos C api from multiple threads on a site with strong traffic.

Specifically CLocalizer is using std::setlocale which is not thread safe. (http://en.cppreference.com/w/cpp/locale/setlocale). Do we have a workaround to this?


Best regards,

Tamas



_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Thread safety issues

Even Rouault-2

On jeudi 29 juin 2017 23:19:30 CEST Tamas Szekeres wrote:

> Dear developers,

>

> We have encountered thread safety issues when invoking the geos C api from

> multiple threads on a site with strong traffic.

>

> Specifically CLocalizer is using std::setlocale which is not thread safe. (

> http://en.cppreference.com/w/cpp/locale/setlocale). Do we have a workaround

> to this?

 

This strongly reminds me of similar issues we have hit in GDAL and proj.4

 

In GDAL, we've now a CPLThreadLocaleC class that use Linux & Windows thread-locale specific API to force the C locale when available, and otherwise default to a setlocale() call protected by a mutex (which only protects 2 concurrent calls to setlocale(), but not a setlocale() with a printf())

 

See

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_conv.cpp#L2785

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_conv.cpp#L2843

 

But ultimately I ended up rewriting my CPLvsnprintf() to avoid messing up with the C locale, and just using vsnprintf() with a later replacing of the comma by decimal point (I guess this must be the use case in GEOS too ?) :

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_string.cpp#L1119

 

And similarly for CPLsscanf() :

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_string.cpp#L1430

 

 

Not sure if those are the best way of addressing the issue (I'd wish there would be API using always the C-locale), but they are now rather well proven.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Thread safety issues

Tamas Szekeres
Thank you, it is sometimes suggested to call the per-thread alternative uselocale instead of setlocale, for example:

locale_t loc = newlocale(LC_ALL_MASK, "C", NULL);
uselocale(loc);
freelocale(loc)
// Do your thing
Or setting the locale on a per stream basis, like:

std::istringstream text( s );
     text.imbue(std::locale::classic());
Not sure if those are applicable in this specific case, however.

Best regards,

Tamas





2017-06-29 23:35 GMT+02:00 Even Rouault <[hidden email]>:

On jeudi 29 juin 2017 23:19:30 CEST Tamas Szekeres wrote:

> Dear developers,

>

> We have encountered thread safety issues when invoking the geos C api from

> multiple threads on a site with strong traffic.

>

> Specifically CLocalizer is using std::setlocale which is not thread safe. (

> http://en.cppreference.com/w/cpp/locale/setlocale). Do we have a workaround

> to this?

 

This strongly reminds me of similar issues we have hit in GDAL and proj.4

 

In GDAL, we've now a CPLThreadLocaleC class that use Linux & Windows thread-locale specific API to force the C locale when available, and otherwise default to a setlocale() call protected by a mutex (which only protects 2 concurrent calls to setlocale(), but not a setlocale() with a printf())

 

See

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_conv.cpp#L2785

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_conv.cpp#L2843

 

But ultimately I ended up rewriting my CPLvsnprintf() to avoid messing up with the C locale, and just using vsnprintf() with a later replacing of the comma by decimal point (I guess this must be the use case in GEOS too ?) :

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_string.cpp#L1119

 

And similarly for CPLsscanf() :

https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_string.cpp#L1430

 

 

Not sure if those are the best way of addressing the issue (I'd wish there would be API using always the C-locale), but they are now rather well proven.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel