CODEWITHSUNDEEP
c++localevalgrind
Ben Hollier
Ben Hollier

Reputation: 605

std::locale causing errors with Helgrind

While profiling my program with Helgrind, I noticed that I was getting a lot of errors similar to:

==8347== Possible data race during read of size 4 at 0x53C47A0 by thread #2
==8347== Locks held: none
==8347==    at 0x50E4E68: std::locale::locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==8347==    by 0x515B1DE: std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream(std::_Ios_Openmode) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)

and

==8347== This conflicts with a previous write of size 4 by thread #1
==8347== Locks held: 1, at address 0xFFEFFF638
==8347==    at 0x50E3115: std::locale::~locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)

So I was wondering, is this going to be a problem, and if so can I fix it? I know how to suppress errors with Valgrind, but I'm not sure if I should be worried.

Upvotes: 1

Views: 129

Answers (1)

HMD
HMD

Reputation: 2226

As std::locale docs says :

Internally, a locale object is implemented as-if it is a reference-counted pointer to an array (indexed by std::locale::id) of reference-counted pointers to facets: copying a locale only copies one pointer and increments several reference counts. To maintain the standard C++ library thread safety guarantees (operations on different objects are always thread-safe), both the locale reference count and each facet reference count are updated in thread-safe manner, similar to std::shared_ptr.

So I would say you probably don't have much to worry about but in the other hand if you allocating (not just reading) pointer with reference count (like shared_ptr) in thread you'd better use lock to prevent wrong reallocation.

Here is a good explanation on it : std::shared_ptr thread safety

Upvotes: 1

Related Questions