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 Thu, 06 Sep 2012 15:58:28 GMT
On Thu, Sep 6, 2012 at 9:16 AM, Liviu Nicoara <> 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

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 Teleman
KDE e.V.

View raw message