"Interesting" behavior in std::locale
James Benze
benzejaa@gmail.com
Fri Oct 31 20:08:00 GMT 2014
> The first time _S_global is set is in _S_initialize_once() which is
serialized with pthread_once.
Ah, I see. I missed that. Still not sure about the weird
implementation of locale::classic() but that at least makes the code
make sense to me now from a thread-safety context.
> N.B. you need to rebuild the library with some helgrind annotations to
> remove some false positives in the locale::_Impl code,
That...is not something I knew. Cool! I added the error to my
suppression file, but this will be nice to help prevent me from
wasting time on other known false positives.
Thanks for your time today :-)
On Fri, Oct 31, 2014 at 3:53 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 31/10/14 12:07 -0400, James Benze wrote:
>>
>> I found this code because helgrind (valgrind's data-race finder) lit
>> up like a lightbulb with all these placement-new calls to the same
>> array. It's obviously safe...the locale returned by
>> std::locale::classic is guaranteed never to change so it's essentially
>> just writing the same chunk of memory over and over.
>
>
> N.B. you need to rebuild the library with some helgrind annotations to
> remove some false positives in the locale::_Impl code, see
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.races
>
> There may be other real races that helgind finds though.
More information about the Libstdc++
mailing list