[RFC] Lock elision implementation guidelines

[Rich Felker]

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