RE: analysis of memory explosion; point of introduction outed

[Pétur Runólfsson <peturr02 at ru dot is>]

Loren James Rittle wrote:
> Each and every constructor
> call gets a new stack variable called lock.  Thus, concurrent
> constructor calls (i.e. in different threads) will have a race on
> _S_global (...if they ever indeed had a race on that variable...).
>
> This is also the root cause of the memory explosion I reported last
> week.  The gthr abstraction layer doesn't support (at least, very
> well) non-bounded, dynamic allocation of mutex since there is no
> support for ever calling pthread_mutex_destroy().

I agree with this analysis.

> IMHO, there is absolutely no way to bind/hide the allocation of memory
> for a __gthread_mutex_t inside any one function unless the protected
> memory is also bound by that scope.

Agreed. Also __GTHREAD_MUTEX_INIT_FUNCTION must be called at most
once for each __gthread_mutex_t. __gthread_once is already called
during locale initialization, so this shouldn't be a problem.

> It appears to me that _S_global
> is the protected memory in locale::locale() and locale::global() thus
> allocation of the protecting mutex will have to be hoisted.

Yes.

> Anyways, this is too tedious to continue thinking about without a
> concrete failure in a test case.

I'll try to come up with a test case.

Regards,
Petur