From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19052 invoked by alias); 15 Apr 2003 19:32:56 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 19026 invoked from network); 15 Apr 2003 19:32:56 -0000 Received: from unknown (HELO e6.ny.us.ibm.com) (32.97.182.106) by sources.redhat.com with SMTP; 15 Apr 2003 19:32:56 -0000 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3FJWs9d135684; Tue, 15 Apr 2003 15:32:54 -0400 Received: from us.ibm.com (spokane0.rchland.ibm.com [9.10.79.64]) by northrelay01.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3FJWq1A013166; Tue, 15 Apr 2003 15:32:52 -0400 Message-ID: <3E9C5E50.1020302@us.ibm.com> Date: Tue, 15 Apr 2003 19:32:00 -0000 From: Steven Munroe Reply-To: sjmunroe@vnet.ibm.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: libc-hacker@sources.redhat.com, Paul Mackerras Subject: PPC atomic.h and compare_exchange_val forms Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00046.txt.bz2 I sent the patch to libc-alpha to fix the current problem for PPC64 but I think there is a larger issue that needs to be discussed. For the macros defined by include/atomic.h, which forms are included for the convenience of specific architecture and which forms are part of the common API (i.e. can they be freely used in arch independent parts of glibc)? For example atomic_compare_and_exchange_val_acq. Are all forms (8-, 16-, 32-, and 64-bit) of this operation expected to be available for general use? A quick review of arch specific atomic.h's shows that only i386 and m68k support the 8- and 16-bit forms. Most arch's define these to abort(). The 64-bit form is also problematic on most 32-bit arches. For PPC32/PPC64 implementing the 8- and 16-bit forms would be problematic. The resulting code would be slow and prone to live lock conditions. I assume that this is true for most architectures. I recommend dropping any mention of the 8- and 16-bit forms from include/atomic.h.