From 85e9cd32af0ed5ccd34c914cf5a3f8f7c72708da Mon Sep 17 00:00:00 2001 From: Yann Ylavic Date: Wed, 15 Feb 2023 13:07:41 +0000 Subject: 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 --- atomic/unix/mutex64.c | 12 ------------ 1 file changed, 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) -- cgit v1.2.1