This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: "Interesting" behavior in std::locale


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]