[PATCH] malloc: add locking to thread cache

[Carlos O'Donell]

On 01/27/2016 12:44 PM, Jörn Engel wrote:
> On Wed, Jan 27, 2016 at 10:05:33AM +0000, Szabolcs Nagy wrote:
>>
>> portable code does not need the fix, but all users
>> of the api are affected by the overhead of the fix.
> 
> Sorry, but you have no idea what you are talking about.  The overhead of
> the fix is _negative_.  Users _want_ to be affected.
> 
> The reason why free() is not signalsafe is that it spins on an
> arena-lock.  If the same thread already holds that lock, you have a
> classic deadlock.  By not spinning on the lock you make code run faster.
> You also fix the signal-induced deadlock.
> 
> Ok, for thread-cache there is some overhead.  Without signal-safety you
> wouldn't need a lock for the thread-cache at all.  But here I call
> bullshit again, because I had the same concerns.  Then I measured and
> could not demonstrate any performance impact.
> 
> "If you cannot measure it, it does not exist."
> 
> You might disagree philosophically, but if an engineers goes out of his
> way to measure a certain effect and finds nothing, that effect hardly
> matters in any practical way.

My mantra is slightly different:

"If others cannot measure it, your performance gains don't exist."

We are always looking for microbenchmark contributions that others
can run objectively to evaluate any such changes.

Cheers,
Carlos.