From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5369 invoked by alias); 19 Feb 2013 20:06:36 -0000 Received: (qmail 5340 invoked by uid 22791); 19 Feb 2013 20:06:34 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Feb 2013 20:06:26 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1JK6OT1019020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Feb 2013 15:06:24 -0500 Received: from [10.36.7.219] (vpn1-7-219.ams2.redhat.com [10.36.7.219]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1JK6Mbw017609; Tue, 19 Feb 2013 15:06:22 -0500 Subject: Re: PI mutex support for pthread_cond_* now in nptl From: Torvald Riegel To: "Joseph S. Myers" Cc: Richard Henderson , Siddhesh Poyarekar , libc-ports@sourceware.org, libc-alpha@sourceware.org In-Reply-To: References: <20130218105637.GJ32163@spoyarek.pnq.redhat.com> <5123AB55.2070100@twiddle.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Feb 2013 20:06:00 -0000 Message-ID: <1361304381.581.80.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00047.txt.bz2 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? 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? Torvald