Well, one option would presumably be to try to find somewhere to stash
the mutex which would not cause an ABI compatibility problem. For
example, perhaps we could add a new field to locale::_Impl in such a
way that no ABI problem was introduced. If we could ensure that the
new field was at the end of the structure in memory, then presumably
we would be OK as long as nothing depends on the size of the
structure. Unfortunately, I see that src/globals_locale.cc does
depend on the size of locale::_Impl, so that won't work.
Or another option would be to borrow an existing mutex, which would
not introduce any new dependencies. Unfortunately, all the mutexes I
see are file static and can not be referenced.
Or another option would be to eliminate the possible memory leak in
some other way. The possibility of the memory leak arises because two
threads may call operator() on a __use_cache simultaneously. When
this happens, it is possible for both threads to test that
__caches[__i] is not set, and for both to set it to a new cache
object. In a preemptive threading model, the threads could switch
right at the assignment in _M_install_cache, so it seems theoretically
possible for the value stored in _M_caches[__index] to be confused by
a simultaneous assignment from two threads. I don't see this can be
safely avoided without using a mutex.