apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: atomics on solaris producing non-portable binaries
Date Fri, 26 Apr 2002 04:43:11 GMT
Jeff Trawick wrote:

>Aaron Bannert <aaron@clove.org> 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




Mime
View raw message