incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Thu, 06 Sep 2012 04:17:18 GMT
Incidentally, a benchmark that I would expect to be more
representative of real programs than the test we've been
using is one that creates a small number of named locales
up front and then uses each in a loop in each thread (as
opposed to creating and destroying it in each iteration
and thread). With this setup, the per-object mutex
implementation should be much faster than the one with
the per-class mutex because of the absence of contention.

The test has an option that exercises this setup:


On 09/05/2012 09:51 PM, Martin Sebor wrote:
> On 09/05/2012 09:03 PM, Stefan Teleman wrote:
>> On Wed, Sep 5, 2012 at 10:55 PM, Martin Sebor <> wrote:
>>> I suspect the difference is due to the overhead of the repeated
>>> initialization and destruction of the per-object mutex in the
>>> test. The test repeatedly creates (and discards) named locale
>>> objects.
>>> The per-class mutex is initialized just once in the process, no
>>> matter how many facet objects (how many distinct named locales)
>>> the test creates. But the per-object mutex must be created (and
>>> destroyed) for each named locale.
>> Agreed.
>> But: if the choice is between an implementation which [1] breaks ABI
>> and [2] performs 20% worse -- even in contrived test cases -- than
>> another implementation [2] which doesn't break ABI, and performs
>> better than the first one,  why would we even consider the first one?
> Breaking the ABI is not an option (unless we rev the version).
> But I'm not sure I understand what you think breaks the ABI.
> 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?
> Martin
>> --Stefan

View raw message