apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: Atomic Operations Assembly
Date Tue, 12 Sep 2006 13:48:00 GMT
On 9/8/06, Colin <share-apache@think42.com> wrote:
> Hallo List,
>
> for one of my projects I was recently looking for implementations of some atomic primitives
for Sparc and PowerPC, and also stumbled over the code in apr_atomic.c.
>
> A few weeks later I am returning here with a bug report and an implementation for SPARC.
>
> 1) PowerPC Bug
>
> The Bug is actually in the Chip, not in the APR code; as stated in erratum number 12
in
>
> http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/79B6E24422AA101287256E93006C957E/$file/PowerPC_970FX_errata_DD3.X_V1.7.pdf
>
> one must not spin in a three-instruction lwarx/ldarx loop because there is obviously
at least one PowerPC chip that can enter a livelock...
>
> (Unfortunately I don't have a solution for this one; I am on Mac OS X where the OS supplies
the spinlock primitive that I actually need; the Mac OS X version is documented as using exponential
back-off.)
>
>
> 2) Sparc/GCC Code
>
> The following code was written by me and has survived both some testing and some real-world
usage; if there is interest in it, I would contribute it to apr under two conditions:
>
> - Somebody reviews it.
> - My name appears somewhere as contributor.

Contributors are acknowledged in the CHANGES file.

> (Yes, I'm doing this a) for vanity and b) because I don't know anybody who can give me
a real review of the code.)
>
> Obviously the typedef and the fact that C++ references are used would need to be changed
to use the APR data types and C pointers.

If you could send this as an actual patch that'll apply to the current
code, it's FAR more likely to actually be committed.

-garrett

Mime
View raw message