On Tue, Sep 25, 2012 at 10:58 PM, Martin Sebor <mse...@gmail.com> wrote:

> As for Stefan's patches, the biggest problem I see there
> (besides the above) is that they introduce changes that
> appear to be unrelated to the problem without providing
> a satisfactory rationale. The established stdcxx bug
> fixing process is to create as small a patch as possible
> that does nothing but address the problem. This is
> particularly important when we don't have ready access
> to test the patch with all the targeted compilers and
> on all the targeted operating systems (to minimize the
> risk of incidental breakage and to make it as easy as
> possible to root cause possible regressions.

There is a very simple rationale for the complexity of the second
version of the thread safety patch: you objected to the first version
of the patch, the one I had originally submitted for 1056, because it
was too coarse. I am talking about the patch which applied the mutex
lock to every public interface in std::numpunct<> and
std::moneypunct(). This patch is also the absolute simplest one in
terms of code changes, and it does not affect binary compatibility at

The complexity of the second version of the patch is a consequence of
your request to try finding a version which is not as coarse, which
performs a more granular and shorter-lasting mutex locking, and which
preserves binary compatibility. That's what the second patch version
does. However, it comes with code complexity side-effects. It is also
slightly better than the first one in terms of performance.

One of the ways by which this  somewhat better performance with more
granular locking was achieved was by increasing the size of the locale
cache, and by eliminating automatic and unnecessary cache resizing
operations, which involve copying and deletions. This change simply
eliminates code. A second way by which this was achieved was by
unwinding recursion. The usefulness and/or necessity of using
recursion in __rw_get_numpunct() and __rw_get_moneypunct() was dubious

Because of the existing design and implementation of the locale
caching, there isn't much wiggle room, if preserving binary
compatibility is a hard requirement.

Stefan Teleman
KDE e.V.

Reply via email to