On Thu, Sep 6, 2012 at 9:16 AM, Liviu Nicoara <nikko...@hates.ms> wrote:
> I think Stefan is referring to adding a mutex member variable to the facet
> in question and breaking binary compatibility. If that is the case I have
> confused things when I suggested exactly that, earlier. A cursory read
> through the __rw_facet source shows that inherits from __rw_synchronized in
> MT builds, therefore each facet carries its own mutex member.
> On 09/05/12 23:51, Martin Sebor wrote:
>> We don't need to add a new mutex -- we can use the __rw_facet
>> member for the locking. Or did you mean something else?
A possible implementation using the __rw_facet mutex could look like this:
template <class _CharT>
inline string numpunct<_CharT>::grouping () const
{
if (!(_C_flags & _RW::__rw_gr)) {
numpunct* const __self = _RWSTD_CONST_CAST (numpunct*, this);
_RWSTD_MT_GUARD (__self->_C_mutex);
if (!(_C_flags & _RW::__rw_gr)) {
// [try to] get the grouping first (may throw)
// then set a flag to avoid future initializations
__self->_C_grouping = do_grouping ();
__self->_C_flags |= _RW::__rw_gr;
}
}
return _C_grouping;
}
Except that it will not work. Because the __rw_facet mutex member is
being locked in file ../src/facet.cpp in function
__rw_facet::_C_manage at line 366:
// acquire lock
_RWSTD_MT_STATIC_GUARD (_RW::__rw_facet);
This will deadlock because this is the mutex already locked by
std::numpunct<T>::grouping().
I've already tested this with 3 compilers, and, it does indeed deadlock.
So yes, I did indeed mean something different. I meant adding another
mutex data member to the numpunct class.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.tele...@gmail.com
