Date: Sat, 18 May 2013 23:40:32 -0500 From: Rob Landley <rob@...dley.net> To: musl@...ts.openwall.com Cc: musl@...ts.openwall.com Subject: Re: cpuset/affinity interfaces and TSX lock elision in musl On 05/17/2013 12:29:03 PM, Rich Felker wrote: > > locks should not be the bottleneck in applications > > unless there is too much shared state on hot paths, > > which is probably a design bug or a special use-case > > for which non-standard synchronization methods may > > be better anyway > > One place where there is unfortunately a huge amount of shared state > is memory management; this is inevitable. Even if we don't use lock > elision for pthread locks, it might be worth considering using it > _internally_ in malloc when it's available. It's hard to say without > any measurements, but this might result in a malloc that beats > ptmalloc, etc. without any thread-locale management. I thought the point of futexes was that in the non-contention case you don't enter the kernel at all? I really don't see how lock elision is supposed to improve upon that. If you're optimizing the contended case, something is wrong. Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.