stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject Re: STDCXX-1056 : numpunct fix
Date Tue, 25 Sep 2012 11:28:15 GMT
On 09/24/12 22:28, Martin Sebor wrote:
> On 09/20/2012 06:46 PM, Stefan Teleman wrote:
>> On Thu, Sep 20, 2012 at 8:39 PM, Liviu Nicoara<>  wrote:
>>> I have not created this requirement out of thin air. STDCXX development has functioned
in this manner for as long as I remember. If it does not suit you, that's fine.
>> That would explain why these bugs are present in the first place.
>> If the "official" method of determining thread-safety here is
>> fprintf(3C), then we have a much bigger problem than
> Tests that end in .mt.cpp use the RW_ASSERT() macro to verify
> correctness in multithreaded programs. There is no way at the
> moment to run a thread analyzer as part of the test suite,
> although it would be a nice addition. As I said in my other
> reply, though, not all data races necessarily indicate bugs,
> so we'd need a way to distinguish between know/benign races
> and the rest. (Unless we decide to eliminate all races and
> accept the performance penalty.)

Preserving the lazy initialization is possible: we perfectly forward to the implementation
with either:

1. no additional synchronization (preserves fast reads of the data), while fully knowing that
there are data races in __rw_get_numpunct/_C_get_data there, or
2.we put a big lock on top of all and every facet operations (the version that would be race

Caching seems out of the window for now, more so in the presence of unguarded reads of facet's

The only argument for (1) is that at the moment we don't have a failing test yet, and not
for lack of arduous trying.

However, if atomic/membar APIs would be recognized by the compiler, lazy initialization of
the facet and caching of data would be attainable in a quite simple fashion.


View raw message