This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: PI mutex support for pthread_cond_* now in nptl
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.