atomic64: Generic apr_atomic_read64() to always use a lock.

Don't play games with sizeof(void*) to determine whether a raw load
intruction is atomic or not. Systems that fall back to the generic
implementation are not eligible for the compiler builtins or CPU
native atomic intructions already, and we don't want to reimplement
that here (e.g. alignment, ordering guarantees, ...).

* atomic/unix/mutex64.c(apr_atomic_read64):
  No #ifdefery, always take the lock.



git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@1907678 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 0 insertions, 12 deletions

diff --git a/atomic/unix/mutex64.c b/atomic/unix/mutex64.c
index 9f1f1df6d..a6a7ceb0b 100644
--- a/atomic/unix/mutex64.c
+++ b/atomic/unix/mutex64.c
@@ -96,17 +96,6 @@ apr_status_t apr__atomic_generic64_init(apr_pool_t *p)
 
 APR_DECLARE(apr_uint64_t) apr_atomic_read64(volatile apr_uint64_t *mem)
 {
-    /* On 32bit CPUs this loads with two instructions (tearing),
-     * so a lock is needed to ensure atomicity.
-     *
-     * APR_SIZEOF_VOIDP is probably not the right check for 32 vs 64 bits CPUs
-     * but it spares an (hardly-)exhaustive list of supported CPUs (and using
-     * assembly). If APR_SIZEOF_VOIDP==4 means that the compiler generates
-     * 32bit instructions (-m32 or whatever) then it's the right check though.
-     */
-#if APR_SIZEOF_VOIDP >= 8
-    return *mem;
-#else
     apr_uint64_t cur_value;
     DECLARE_MUTEX_LOCKED(mutex, mem);
 
@@ -115,7 +104,6 @@ APR_DECLARE(apr_uint64_t) apr_atomic_read64(volatile apr_uint64_t *mem)
     MUTEX_UNLOCK(mutex);
 
     return cur_value;
-#endif
 }
 
 APR_DECLARE(void) apr_atomic_set64(volatile apr_uint64_t *mem, apr_uint64_t val)