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

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Jul 05, 2004 at 05:19:24PM +0200, Paolo Carlini wrote:
> I'm trying to understand more about this issue: as you may have
> noticed already, on multiprocessor machines the testcase randomly
> fails. This happens both for mainline and 3_4-branch.
> 
> Backtraces on a 4-way x86_64 machine show that the problem seems
> *not* due to locale::locale() and locale::global(const locale&),
> which appear indeed fixed: the testcase stresses the MT-safety of
> the locale implementation *well* beyond what originally reported
> in libstdc++/12658.

I just looked at the PR for the first time.  What a load of nonsense!
There's no need for mutexes anywhere.  

It would suffice to add calls to add_reference and remove_reference 
to keep anything from disappearing too early.

> Honestly, it's not completely clear to me what we really want to
> achieve: if it's complete MT-safety in locale then the two issues
> discussed in 12658 seem only the "tip of the iceberg", sadly...
> 
> If, less ambitiously (at least for now!) we want only MT-safety
> in dealing with the global locale, then probably we are already
> quite close but we badly need a different, much simpler, testcase
> than 12658_thread.
> 
> Opinions? Ideas? Patches? ;)

We do have to be careful about caches.  Locales are logically 
read-only, but caches in a locale may be shared among threads, so 
any changes must be made carefully.  Ideally this means that 
changes are made in memory that is only visible to one thread, and 
then "patched in" via an atomic assignment.  Then, only writers 
need a lock.   (It's not necessarily so simple: when do you get to 
dispose of the old pointer?  Complications like this are why I prefer 
to cache in the iostream.)  Locking overhead could easily swamp any
benefits of caching.

Nathan Myers
ncm-nospam@cantrip.org