This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
On Fri, Feb 22, 2013 at 03:02:40PM +0100, OndÅej BÃlka wrote:
> > > > > At present, this feature is only interesting to less than 1% of glibc
> > > > > users. I doubt that will increase significantly even if the hardware
> > > > > becomes widespread, simply because locking already costs virtually
> > > > > nothing for most normal usage cases.
> > > >
> This is not quite true.
> For libraries often even for single thread apps significant time is spend
> on locking when workload consist of many small updates.
> Take malloc for example.
malloc is a very special case because the virtual memory space of the
process is one of the few *legitimate* singletons. When applications
introduce their own singletons of this sort, it's almost always a
design flaw, and as you've noted, one that yields abysmal parallel
performance.
For what it's worth, I think internal elision in malloc can be judged
differently from POSIX mutexes with respect to whether it's a pet
feature.
Rich