stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Tue, 11 Sep 2012 22:15:55 GMT
On Mon, Sep 10, 2012 at 4:24 PM, Stefan Teleman
> I think I have something which doesn't break BC - stay tuned because
> I'm testing it now.


So, here's a possible implementation of __rw_get_numpunct() with
minimal locking, which passes the MT tests and does not break ABI:

And the same for include/loc/_numpunct.h:

In _numpunct.h, all the functions perform no checks and no lazy
initialization. They function simply as a pass-through to
__rw_get_numpunct(). std::numpunct<T>'s data members are now dead

The bad: performance is no better than with locking the mutex inside
each of the std::numpunct<T>::*() functions, and with lazy

1. SunPro:

real 2628.78
user 3020.97
sys 178.65

2. Intel:

real 2439.77
user 2712.62
sys 166.92
Tue Sep 11 16:32:28 EDT 2012

These numbers are for the full test with no arguments (i.e. 8 threads,
32 locales, 200000 iterations each). The SunPro build is not optimized
(-g -xO0 -xkeepframe=%all). The Intel build is optimized (-O2).

Other things into consideration:

Implementing the private data member access hack for std::numpunct<T>
and std::moneypunct<T> in src/access.h will not reduce the mutex
locking in __rw_get_numpunct(). Whether the data is being copied from
the __rw_punct_t struct directly into a private data member accessed
via hack, or the private data member is initialized with the data
returned from __rw_get_numpunct() is cost-irrelevant: the mutex still
has to be locked while the copying takes place.

This leaves us with considering the option of breaking the ABI for the
sake of optimization, and introducing a mutex in each of the
std::numpunct<T> and std::moneypunct<T> classes. I am personally not
in favor of breaking the ABI.


Stefan Teleman
KDE e.V.

View raw message