Re: PI mutex support for pthread_cond_* now in nptl

[Steven Munroe <munroesj@linux.vnet.ibm.com>]

On Tue, 2013-02-19 at 21:06 +0100, Torvald Riegel wrote:
> On Tue, 2013-02-19 at 17:18 +0000, Joseph S. Myers wrote:
> > On Tue, 19 Feb 2013, Richard Henderson wrote:
> > 
> > > Any chance we can move these macros into a generic linux header?
> > > Given that we're using INTERNAL_SYSCALL macros, the definitions ought to be
> > > the same for all targets.
> > 
> > Generally most of lowlevellock.h should probably be shared between 
> > architectures.  (If some architectures don't implement a particular 
> > feature as of a particular kernel version, that's a matter for 
> > kernel-features.h and __ASSUME_* conditionals.)
> 
> On a related note: What are the reasons to have arch-specific assembler
> versions of many of the synchronization operations?  I would be
> surprised if they'd provide a significant performance advantage; has
> anyone recent measurements for this?
> 
The introduction of GCC compiler builtins like __sync is fairly recent
and the new __atomic builtins start with GCC-4.7. So until recently we
had no choice. 

For platforms (like PowerPC) that implement acquire/release the GCC
__sync builtins are not sufficient and GCC-4.7 __atomic builtins are not
pervasive enough to make that the default. 

> It seems to me that it would be useful to consolidate the different
> versions that exist for the synchronization operations into shared C
> code as long as this doesn't make a significant performance difference.
> They are all based on atomic operations and futex operations, both of
> which we have in C code (especially if we have compilers that support
> the C11 memory model).  Or are there other reasons for keeping different
> versions that I'm not aware of?
> 
I disagree. The performance of lowlevellocks and associated platform
specific optimizations are too import to move forward with the
consolidation you suggest.