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.
