Farid Zaripov wrote: > The __rw_get_moneypunct () function in punct.cpp is not thread safe > for the same > facets. If this function is invoked with the same pfacet parameter in > dirrerent threads > simultaneously, then some one thread successfully create __rw_setlocale > object > but other threads will blocked by global mutex in __rw_setlocale ctor. > Then when > the mutex will be released after the updating pfacet->_C_data(), the > next thread will > do the same initialization as the first thread. I see what you're saying: the other thread will end up overwriting the data written by the first thread. The newly data should be the same, so I wonder if this just a benign race condition or if it's more sinister than that? Either way, I agree that it should be fixed. I took the liberty to add more detail to your comment in the patch below to make it even more clear what's going on (I had some difficulty following the logic at first so I think it might be helpful to others). > > > ChangeLog: Can you reference the Jira bug here please? > * punct.cpp (__rw_get_moneypunct): After creating __rw_setlocale > object check > if the locale data is initialized by another thread to prevent > multiple initialization\ > of the locale data in facet. > > ---------- > Index: punct.cpp > =================================================================== > --- punct.cpp (revision 580097) > +++ punct.cpp (working copy) > @@ -308,6 +308,10 @@ > // set all categories -- need LC_NUMERIC and LC_CTYPE > const __rw_setlocale clocale (locname, _RWSTD_LC_ALL); > > + if (pfacet->_C_data ()) > + // call self recursively on already initialized in another > thread `impdata' > + return __rw_get_moneypunct (pfacet, flags); > + I suggest: + if (pfacet->_C_data ()) { + // check to see if another thread may have set _C_data() + // while we were waiting for the lock in __rw_setlocale + // ctor above and, if so, call self recursively on the + // already initialized `impdata' + return __rw_get_moneypunct (pfacet, flags); + } Thanks Martin