apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin <share-apa...@think42.com>
Subject various atomic operations
Date Thu, 19 Oct 2006 20:51:32 GMT
Hi Again,

I have finally found a few minutes to write down all issues that I
found in apr_atomic.c ... I would now like to know whether, and
for which of the points, there is interest in further discussion
and/or finally a patch.

Regards, Colin


1) The PowerPC assembler versions of apr_atomic_cas32 and
   apr_atomic_add32 can deadlock some machines.

http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/79B6E24422AA101287256E93006C957E/$file/PowerPC_970FX_errata_DD3.X_V1.7.pdf

2) I have Sparc assembler versions of all atomic operations that work
   from Sparc v9 upward; for Solaris < 10; requires Makefile change.

3) Various places are missing memory barriers for non-x86
   architectures; volatile is not sufficient.

4) On Mac OS X (Darwin) there are atomic operations available to
   userspace as per /usr/include/libkern/OSAtomic.h .

5) The volatile declarations on all function prototypes in
   apr_atomic.c could be replaced by appropriate use of volatile
   accesses in the functions' bodies.

6) Might a value of 3 be better for the shift in the ATOMIC_HASH
   macro on 64 bit platforms?

7) For some (all?) architectures it should be ensured that the mutexes
   pointed to by hash_mutex are in different cache lines to prevent
   performance degradation.

8) I believe that some of the arguments to the x86 inline assembler
   parts can be simplified by use of "+", and generally cleaned up a
   little.

Mime
View raw message