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.
OK. So, here's a possible implementation of __rw_get_numpunct() with minimal locking, which passes the MT tests and does not break ABI: s247136804.onlinehome.us/stdcxx-1056-20120911/punct.cpp And the same for include/loc/_numpunct.h: http://s247136804.onlinehome.us/stdcxx-1056-20120911/_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 varaiables. The bad: performance is no better than with locking the mutex inside each of the std::numpunct<T>::*() functions, and with lazy instantiation. 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 -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
