Date: Sun, 19 May 2013 16:51:20 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: cpuset/affinity interfaces and TSX lock elision in musl On Sat, May 18, 2013 at 11:40:32PM -0500, Rob Landley wrote: > 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. Yes, that "something" is C++ (and by extension, glib, which might as well be C++ but worse). But we're not in a position to fix it. Rich
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.