Re: [RFC] 12658_thread.cc randomly fails (on MP machines)

[Paolo Carlini <pcarlini at suse dot de>]

Paolo Carlini wrote:

> Please let me know in case it's better not xfail-ing the old test and 
> instead
> doing something different with it...

Ok, I'm committing the patch, as agreed off line.

Anyway, in the meanwhile the issue is becoming more clear to me. I try 
to tell you how I see it now, since will not be able to help much more 
'til the end of the month. Our trouble basically stems from the nasty 
association of two things:
   1- Two static members, e.g., _S_global and _S_classic.
   2- The reference counted nature of locales.
Point 1- by itself is troublesome in a multithreaded environment, this 
is completely expected, and can be counteracted effectively as we 
(Benjamin) did for locale::global() and locale::locale().
Point 2- is much more nasty, because implies that *any* locale can be in 
fact a ref-copy of _S_global or _S_classic! In principle, *every* 
operation on locales (e.g., also the copy constructor, the assignment 
operator) can be dangerous and must be protected.
Therefore, it looks like we have to make a decision: either we add 
locking bits in a few other places (much better if we can do that with 
zero overhead in the non-multithreaded case), or we can stay with 
something simpler.

A final observation: in fact the most problematic member is obviously 
_S_global, since _S_classic is unchanging and most probably could be 
dealt with in a special way (avoiding the locks!) similarly to the 
static empty string object in basic_string (maybe Nathan had this mind a 
few days ago?)

Paolo.