incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <mse...@gmail.com>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Thu, 06 Sep 2012 20:02:53 GMT
On 09/06/2012 12:46 PM, Stefan Teleman wrote:
> On Thu, Sep 6, 2012 at 12:16 PM, Martin Sebor<msebor@gmail.com>  wrote:
>
>> This locks a different mutex, one unrelated to __rw_facet::_C_mutex.
>
> Let's debug this the good-ol' fashioned way: with fprintf(3C).  Let's
> print the addresses of the mutex being locked in various places, and
> see what we get:
>
...
> grouping: _RWSTD_MT_GUARD (__self->_C_mutex): 0xf774913c
> _C_get_data: _RWSTD_MT_GUARD (&_C_mutex): 0xf774913c
>
> [ ... deadlock ... ]
>
> Looks like the same mutex to me ...

These two are the same. The one you pointed to before
(__rw_facet::_C_manage at line 366) is a different one.

Now that we know what's causing the deadlock (and that
we can't use the same mutex in the inline function),
let's see if we can fix it in __rw_get_numpunct()
(and __rw_get_moneypunct()).

Here's a thought: it's not pretty but how about having
the function initialize the facet? It already has a pointer
to the base class, so it could downcast it to std::numpunct
(or moneypunct, respectively), and assign the initial values
to the members. Would that work?

Martin

Mime
View raw message