From dev-return-6364-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Apr 26 04:35:15 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 9559 invoked by uid 500); 26 Apr 2002 04:35:14 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 9544 invoked from network); 26 Apr 2002 04:35:14 -0000 Date: Thu, 25 Apr 2002 21:43:11 -0700 From: Brian Pane Subject: Re: atomics on solaris producing non-portable binaries To: dev@apr.apache.org Message-id: <3CC8DADF.1000206@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310 References: <20020425171916.E14899@clove.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jeff Trawick wrote: >Aaron Bannert writes: > >>For example, I have a build of APR from an Ultra5 running Solaris 5.6 >>that produces sparcv8plus binaries. These binaries do not work on an >>older SparcStation5 machine that is running Solaris 5.7. >> > >I'm glad somebody else noticed this :) I had the fear that somebody >would put the atomic stuff all over Apache and then our build machine >for Solaris binaries caught on fire and had to be replaced with >something new and then we had screaming customers as soon as they >picked up a new build. > I was thinking about this recently (while trying to figure out how to convert the CAS on Solaris/Sparc to a #defined asm directive so that we could inline it)... If we can rely on libapr.so being a shared lib, then the solution may be to just provide different builds of libapr for different CPU iterations-- e.g., on Sparcs, we'd basically need "UltraSparc" and "pre-Ultra" versions. However, that would rob us of the ability to inline the CAS. To me, that's somewhat of a problem, because one common use of CAS is for spin locks. Adding the overhead of a function call increases the time spent in the code path where the spin lock is vulnerable to a race condition, and thus the probability that the spin lock will have to retry. --Brian