about summary refs log tree commit diff
path: root/src/thread/pthread_getconcurrency.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2012-04-24 16:32:23 -0400
committerRich Felker <dalias@aerifal.cx>2012-04-24 16:32:23 -0400
commit4750cf4202c29a895639b89099a7bdbe9ae422b6 (patch)
treeb682c69140ada09d2c498a80e7d84865d4c51e60 /src/thread/pthread_getconcurrency.c
parente7655ed37bc9c2d79d921af4f287ee5cf2788661 (diff)
downloadmusl-4750cf4202c29a895639b89099a7bdbe9ae422b6.tar.gz
musl-4750cf4202c29a895639b89099a7bdbe9ae422b6.tar.xz
musl-4750cf4202c29a895639b89099a7bdbe9ae422b6.zip
ditch the priority inheritance locks; use malloc's version of lock
i did some testing trying to switch malloc to use the new internal
lock with priority inheritance, and my malloc contention test got
20-100 times slower. if priority inheritance futexes are this slow,
it's simply too high a price to pay for avoiding priority inversion.
maybe we can consider them somewhere down the road once the kernel
folks get their act together on this (and perferably don't link it to
glibc's inefficient lock API)...

as such, i've switch __lock to use malloc's implementation of
lightweight locks, and updated all the users of the code to use an
array with a waiter count for their locks. this should give optimal
performance in the vast majority of cases, and it's simple.

malloc is still using its own internal copy of the lock code because
it seems to yield measurably better performance with -O3 when it's
inlined (20% or more difference in the contention stress test).
Diffstat (limited to 'src/thread/pthread_getconcurrency.c')
0 files changed, 0 insertions, 0 deletions