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