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<nikko...@hates.ms> 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
22.locale.numpunct.mt.
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 free).
Caching seems out of the window for now, more so in the presence of unguarded
reads of facet's data.
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.
Liviu
